DID from provider breaks incoming routes (DID matching)

[RealSquirrel]

Ok, so I’m almost done with my setup. Unfortunately my VoIP provider causes a problem which breaks our concept. What we are trying to achieve is quite easy, here’s a brief overview:

10 endpoints (phones), 10 numbers registered with our VoIP provider (unitymedia, german comp).
Each phone number is supposed to be statically mapped to each phone, i.e. each phone has its own fixed number that it dials out with and can also be called from external via that same number.

Outbound routes are working just fine. The problem are the inbound routes.

Our provider does not send us the number which was called as DID, but the username that number is registered with.
Unfortunately the username has this format: n123456789_X, where X is basically the index.

• I can’t enter the username directly because of the underscore
• I can’t seem to create a pattern that matches the username (escaping doesn’t work)
• I already tried setting context=from-pstn-toheader in PEER details - no diference. Still receiving username as DID

Here’s a log:

pbx.c: Executing [n123456789_4@from-pstn-toheader:1] NoOp("SIP/Unitymedia_XXX_XXXXX-00000e59", "Attempting to extract DID from SIP To header") in new stack
pbx.c: Executing [n123456789_4@from-pstn-toheader:2] GotoIf("SIP/Unitymedia_XXX_XXXXX-00000e59", "1?SIP") in new stack
pbx_builtins.c: Goto (from-pstn-toheader,n123456789_4,6)
pbx.c: Executing [n123456789_4@from-pstn-toheader:6] Goto("SIP/Unitymedia_XXX_XXXXX-00000e59", "from-pstn,n123456789_4,1") in new stack
pbx_builtins.c: Goto (from-pstn,n123456789_4,1)
pbx.c: Executing [n123456789_4@from-pstn:1] Set("SIP/Unitymedia_XXX_XXXXX-00000e59", "__FROM_DID=n123456789_4") in new stack
pbx.c: Executing [n123456789_4@from-pstn:2] NoOp("SIP/Unitymedia_XXX_XXXXX-00000e59", "Received an unknown call with DID set to n123456789_4") in new stack

Any ideas or suggestions how to realize this or work around the problem?

[PitzKey]

In CDR, do you also see n123456789_4 ?

Did you ask them if they can change it?

If they can’t, I believe you’ll need some custom code to get the DID extracted

[Stewart1]

Possibly, Unitymedia sends the dialed number in some other SIP header, in which case you could just create a modified version of from-pstn-toheader that would extract it. At the Asterisk command prompt, type
sip set debug on
which will cause SIP traffic to be included in the normal Asterisk log. Call into the system and look at the incoming INVITE. Does the called number appear anywhere?

If not, you’ll need some custom code to create it from the index. You may need to consider possible growth (2-digit index values) and handling of any ‘main’ or ‘department’ numbers you may have.

[RealSquirrel]

In CDR reports the DID field is empty.

Well, I did contact the provider regarding another issue and they made it very clear, that they only provide support for their proprietary hardware, so yeah, I doubt they’ll change anything on their end.

[RealSquirrel]

I turned on debug logging and searched for the real DID in the logs - nothing.

So I guess I’ll have to write some custom code to translate the usernames into numbers? Can you point me in the right direction to do so? Do I create a new context?

Isn’t it possible to modify the inbound route settings in a way that the matching works even for usernames?
FreePBX won’t let me enter anything with an underscore if it’s not already a pattern (leading _).
Maybe I could enter it in the conf files directly?

[lgaetz]

You need your own context to do this, it’s not overly difficult. Configure your trunk(s) with context of from-pstn-unity, then create that context in extensions_custom.conf:

[from-pstn-unity]
exten => n123456789_4,1,Goto(from-pstn,xxxxxxxxxx,1)
exten => n123456789_5,1,Goto(from-pstn,yyyyyyyyyy,1)
exten => n123456789_6,1,Goto(from-pstn,zzzzzzzzzz,1)
exten => _.,1,Goto(from-pstn,${EXTEN},1)   ; catchall in case they change format on you

Substitute your DIDs in place of the x,y,z.

[RealSquirrel]

Awesome! Works very well.

[system]

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.