Need help trouble shooting Outgoing Caller ID


Isn’t that what I have done here?

It is the extension 1023 and the CID says out phone number 5303420518


I’m suggesting that you put the extension number in the CallerIDNumber field at the top right of the extension settings. Worth a try - I think that might solve the problem. The DoD settings are looking for outbound calls from a certain set of extensions. Your extension isn’t sending its extension number with the outbound call, thus the DoD can’t substitute the number you’ve set there. That, combined with the fact that you haven’t checked the “Keep Original Caller ID” box on the trunk is what is causing your problem (I think.)


Thanks so much for the reply. Just so I understand you want me to try this?




Yes, that’s what I meant. Did it work?


Here are the trunk settings too


Rebooting just in case


:frowning: No Luck. Still shows as Unknown


Could this be part of this issue? Do I need to set it up in the P codes?


Under PBX Settings -> SIP Settings -> ToS there are two settings called “Trust Remote Party ID” and “Send Remote Party ID.” Try checking those two boxes and see what happens.

Also, does the UCM have a public IP? Does it have devices connected to it “downstream” such that it is providing DHCP for those devices? If not, then you should probably uncheck the NAT box on your trunk settings. (Probably unrelated to the Caller ID issue.)


Thanks so much for the assistance. So I tied all 3 combinations.
Checked Trusted Remote => Still Unknown
Checked Send Remote => Still Unknown
Unchecked Trusted Remote => Still Unknown

My gateway is responsible for DHCP for my phone system. Because I don’t have a static IP address, My gateway uses dynamicdns to connect to the outside world so the outside world always sees the correct address and can get to my PBX. My gateway has firewall rules to allow the VOIP traffic through. Calls are going in and out ok. Should I still uncheck the NAT?

I also have this set up

So could this be this issue?


I’m an “If it ain’t broke” kind of guy.

So if it’s working and you have audio in both directions, I’d let it be.

As to your Caller ID issues - I’m at a loss. I’m wondering if something is overriding your settings at the carrier level.

I’m self-taught in this arena, and have received great support from the true experts on this forum. I like to try to give back and help with what appear to be simple issues when I can . . . and when they don’t beat me to it. :slight_smile:


The only other thing I am going to try is using a different VOIP provider. It is works for them, then I’ll start looking at the carrier. Thanks for the ideas.


who is the current provider?


It is a company called skyetel. I have reached out to them and they have provided me what they are sending out when we call out and have included it in the first post. I noticed it when some clients told us that they were seeing unknown CID


Skyetel uses the From header to acquire the CID. The CID filed in the extension settings should be left blank. When set to be blank, the extension number is used by default.

I am curious as to where the “+” sign is being inserted in the From and To headers. Look in the PBX Settings, General and if something is there, remove it, I also note that the “1” is also in the field; yet the CID you had shown for the extension had neither the + or 1, which makes me think some other field in the UCM is populated with same.

The DR 4 is in quotes and should not be an issue as the is the SIP Display Info. The +15303420518 is the data of interest as this is the SIP User Part and the following IP address is the Host Part.


Thanks again. I tried using a different VOIP provider (flowroute) and they also has the same issue. Unknown caller presented to my phone. In the past I have heard from others who get our calls that they see the “dr4” on their CID. I’ll remove the CID field in teh extension settings.


Here is what I have now. Still saying unknown :frowning:


This is the only place that I can find that has a +

It is on the inbound route. Should I change this?


no, it has nothing to do with the issue