PBX Missing DIDs on many calls

PBX its not translating our DIDs and logging them. What I mean is few numbers are being received but on the PBX its not logging any of that data. What could be the possible solution?

Get the provider to send the DID to you.

Get the provider to tell you how they send your DID to you.

Given satisfactory answers to the above, use channel technology means to extract the DID from the call information, using a special context for the trunk, and have custom dialplan for that context do a GoTo to the from-pstn context, with the DID as the extension and a priority of 1.

In the special case that you are using chan_sip or chan_pjsip, and the provider puts the DID in user part of the the To URI, there is a special context for this, something like from-pstn-toheader.

Otherwise, if you are using chan_pjsip, use the cli command “pjsip set logger on”, and provide a copy of the complete INVITE from /var/log/asterisk/full, and tell us what part of that requests is the DID. You may also be able to use sngrep for this. You may be able to use the from-pstn-toheader context as a starting point for your custom context.

Here the issue I have is any number which is not in our inbound routes does not show. Apparently it should show even if it’s not setup since those are for special circumstances rules.

I believe, you solution is related to this … Just clarifying as I wasn’t clear before.

Thank you for replying

I did set up the following scriprt in my extensions.confg file under from-pstn-toheader.
exten => _.,1,Goto(from-pstn,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)
but didnt work.

That script should already be in extensions.conf, and you should never modify that file yourself.

Whilst I’d be surprised if it doesn’t work in practice, given that it must be reasonably well used, I’m also surprised that it does work, as I would have expected ${…} around the inner CUT, as well as the outer one.

It wasn’t there.

My from-pstn-toheader looks like this without adding above script;

do you have an “any/any” route?

Yes.

if that is not capturing it, then you may want to provide a call trace

provide call trace to who? sorry I’m unsure.

To the forum, typically by posting suitably (but minimally) redacted logs to pastebin.freepbx.org

Thank you!
here is the link for pastebin DevOps - FreePBX Pastebin

The context for the trunk is set to from-trunk-sip-comcast-sip, not to from-pstn-toheader.

https://pastebin.freepbx.org/view/94ce1894#L52

Would you mind telling me where can I go and change that setting? Is under-connectivity-inbound routes or trunks?

Or anywhere else?
I’m sorry… I’m new and leaning.

You’ll probably have to enter it into the free text field in the peer settings, and also into the user settings if you have them:

https://wiki.freepbx.org/display/FPG/Trunks+Module+-+User+Guide#TrunksModule-UserGuide-SIP(chan_sip)/IAX2SpecificSettings

However, you really should be moving to chan_pjsip, not least because the user settings concept in chan_sip is flawed, in which case you want:

https://wiki.freepbx.org/display/FPG/Trunks+Module+-+User+Guide#TrunksModule-UserGuide-Context

This is what I have for Peer Setting now

my user setting is empty

It looks like you have your default context set that way. I’m not sure if that is something that can be changed within the GUI, or whether it has been done using a customisation file. It certainly has been set somewhere, as there is no way that would be the default, unless, possibly, you have a version of FreePBX that Comcast customised.

If you do have the default context customised, you can still override it locally, and you should consider removing the customisation, as it is likely to cause more confusion.

I will check and see how can I do that but just one final question, In addition to that do I need to have the below script on my extensions.confg file under from-pstn-toheader??

exten => _.,1,Goto(from-pstn,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)

It looks like the existing customisation sets up a group for group counts, so you would need to merge that code, if it is really needed. You really need to find out why it was done, as it isn’t really possible to support customised code where the customisations, and their purposes, are unknown.

You should really use the supplied code for this, as it copes with both chan_sip and chan_pjsip, and you should be making the transition. Using the same name as the supplied code is a bad idea.

I don’t understand why the supplied code has so few $s. I would expect:

exten => _.,1,Goto(from-pstn,${CUT(${CUT(${SIP_HEADER(To)},@,1)},:,2)},1)

As such, I’m not going to give any guarantees for either your version of that line, or mine.

Assuming the existing customisation is important, I would suggest the GoTo target should be its context, if you don’t merge the code.

The existence of the existing customisation means you really need to understand how dialplan works if you are going to be able to maintain this system.

I don’t think the existing customisation, as revealed in the trace, is all of that customisation. unless it is code that has become redundant.

My default context under Asterisk SIP setting is as in the pic. Should I change this to from-pstn-toheader ? or is this correct?