[SOLVED] No DID provided from sip trunk to Inbound Routes

[gfgfnl]

As a total Freepbx newbie, I had been struggling with this before and had given up, but this was no longer an option so I tried again yesterday.

The situation: I have two trunks with different numbers from the same SIP-provider. Hence, the registrar/proxy host is the same. I need one number to go into an IVR and the other to a ring group (so without automatic answering as other devices are connected to this trunk as well and need to ring). So I created the trunks and two Inbound routes with the respective DID. This did however not work. It seems that no DID whatsoever was passed on to the Inbound Route.

After many hours of testing and searching around in the asterisk config files created by Freepbx, I found out that all calls from the SIP trunks are passed to the context from-pstn, regardless of the trunk name or the context directive in the SIP settings. From within the context from-pstn, various other contexts are included and the call is handled as follows:

• from-pstn
• ext-did (included in from-pstn)
• ext-did-0001 and ext-did-0002 (my inbound routes, included in ext-did)

Somehow the DID was not passed on, although the right number was present in the To: header of the SIP trunk when receiving a call in the format sip:[email protected]

I finally managed to grasp the DID from the SIP To: header by adding the following lines to the config file /etc/asterisk/extensions_custom.conf

[from-pstn-custom]
exten => s,1,Set(__DID=${SIP_HEADER(TO):5:10})
exten => s,n,Goto(ext-did,${DID},1)
exten => 7777,1,Goto(ext-did,0123456789,1)

where 0123456789 is to be replaced by the real DID

Now the 10-digit DID is passed to the context ext-did and everything is handled properly. For convenience I also added one of the DIDs to the 7777 facility code.

Don’t know if this is a bug or a feature or whether it only occurs with my SIP-provider (xs4all.nl).

Happy to learn a better solution for this issue (without manipulating config files) if available but I thought it might be helpful to post my findings.

Cheers! G

[lgaetz (Lorne Gaetz)]

@gfgfnl

Somehow the DID was not passed on, although the right number was present in the To: header

A small fraction of SIP providers put the DID in the to header instead of the INVITE, this is nothing you can control and is not a FreePBX bug. While I’m sure you’ve learned a lot in this process, you should know that there’s a pre-defined context for handling this situation:

lorne14-pro*CLI> dialplan show from-pstn-toheader
[ Context 'from-pstn-toheader' created by 'pbx_config' ]
  '_.' =>           1. NoOp(Attempting to extract DID from SIP To header) [pbx_config]
                    2. gotoif($["${CHANNEL(channeltype)}"="SIP"]?SIP) [pbx_config]
                    3. gotoif($["${CHANNEL(channeltype)}"="PJSIP"]?PJSIP) [pbx_config]
                    4. NoOp(Unable to determine SIP channel type) [pbx_config]
                    5. goto(from-pstn,${EXTEN},1))                [pbx_config]
     [SIP]          6. Goto(from-pstn,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1) [pbx_config]
     [PJSIP]        7. Goto(from-pstn,${CUT(CUT(PJSIP_HEADER(read,To),@,1),:,2)},1) [pbx_config]

-= 1 extension (7 priorities) in 1 context. =-

The from-pstn-toheader is considerably more versatile than the one you’re relying on, it allows for DIDs of varying lengths, and can also handle both chan_sip and PJSIP trunks.

[gfgfnl]

Many thanks for the feedback!

This nested CUT function was actually what I was looking for.