PJSIP - getting 10 digits delivered

I’ve always used chan_sip on an old system. I just upgraded to Asterisk 16 with freepbx 15 and pjsip for my trunks. I still have a few SIP extensions.

PJSIP - if it matters - is running on 5060 and chan_sip is on 5160.

I’m using flowroute for my incoming calls. Flowroute delivers numbers as +18885551212. I have always used the following:

in /etc/asterisk/extensions_custom.conf:

[from-flowroute-com]
exten => _X!,1,Set(CALLERID(num)=${CALLERID(num):2:12})
exten => _X!,n,Goto(from-trunk,${EXTEN},1)

and then in my trunks I use from-flowroute-com as the context.

With my PJSIP trunks, this causes all calls to go straight to voicemail. I tried using the context:
from-pstn-e164-us

and that just delivered 18885551212 (I believe).

So, I’m doing something wrong, but I can’t figure it out. Any thoughts, help or tips?

Andrew

Sounds like you did things correctly, but a call trace will show the issue:
https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs-PartII

Crosspost of https://pbxinaflash.com/community/threads/getting-10-digit-delivered-to-phone-old-way-doesnt-work.24075/

2 Likes

I’m not sure how this worked with Flowroute sending you E.164. This pattern match won’t catch them because it doesn’t match their pattern. You’re missing the + so if you want to do this it’s

[from-flowroute-com]
exten => _+X!,1,Set(CALLERID(num)=${CALLERID(num):2:12})
exten => _+X!,n,Goto(from-trunk,${EXTEN},1)

Though I’m not sure why you’re removing the first 2 characters and then returning 12, how does that make sense? If this was a NXXNXXXXXX you would have ended up with XNXXXXXX result. If it was 1NXXNXXXXXX you would have XXNXXXXXX and if this was a E.164 it would skip it. Based on your pattern matching/manipulation. If it was an International number it would be skipped too or with the + adjustment it would strip the + and 1 extra digit then only return 12. For International that will make the number invalid as it does the others as well.

Your patterns should be more targeted for what you are actually matching and not just random catchalls that can screw with things. What is below is all you need to take E.164 based US/Canada DIDs and make them 10 digits.

[from-flowroute-com]
exten => _+1NXXNXXXXXX,1,Set(CALLERID(num)=${CALLERID(num)})
exten => _+1NXXNXXXXXX,n,Goto(from-trunk,${EXTEN},1)

Also, pattern matching doesn’t care which driver you’re on (PJSIP, Chan_SIP DAHDI, IAX) it’s in the dialplan at that point and just matching digits.

I know you know this, but the morning’s coffee probably hasn’t kicked in yet. :slight_smile: He’s matching on the DID (which I guess does not come with a + ) but manipulating the caller ID (which does). However, your points are valid: this will only work for US domestic caller IDs that start with +1. Why the from-pstn-e164-us context doesn’t work for this, I don’t know, but suspect it’s because the calls aren’t going through the prescribed context at all. If you check the crosspost on pbxinaflash you will see he has a convoluted setup and hasn’t shared any logs yet, so who knows what’s really going on.

Do what’s needed with the Caller ID then

. . .Go-to(from-trunk,${EXTEN},-10)

Correct, he’s matching on the DID from Flowroute that uses E1.64 in all the headers. INVITE, To, From, Contact, PAI.

INVITE sip:+1313*******@x.x.x.x:5060 SIP/2.0
To: <sip:+1313*******@fl.gg>
From: <sip:+1519*******@fl.gg;isup-oli=00>;tag=gK0204ca71
Contact: <sip:+1519*******@23.29.25.54:5060>
P-Asserted-Identity: <sip:+1519*******@fl.gg>

So the OP doesn’t show anything looking at the PAI header for CallerID details so they’ll get what is presented in the From header. As you can see, all formatting is E.164 so you need to have pattern matches against the DID and/or CallerID that include a + at the start of them.

So this pattern that the OP has presented will ignore anything in the E.164 format because it’s missing the +. This will match against any DID in the INVITE header that starts with 0-9 and has any number of digits including a single digit since ! matches everything from the start not just after the X.

Yes, the OP is trying to manipulate the CallerID number but only if it matches the DID pattern they have which Flowroute DIDs will not so the CallerID is never touched.

He says it used to work. I don’t see how.

Here is the call log from /etc/asterisk/full

https://pastebin.com/2Ndzsxym

Thanks for everyone’s help

Andrew

You cut off the beginning of the log… please include the steps before 16095558888@from-pstn:9. Also, every line is duplicated for some reason.

post the issue of

grep "\[C-00000026\]" var/log/asterisk/full|uniq

The repeated log lines are typical for deployments that started before FreePBX added logging in the mainstream gui, the solution will likely be apparent with

grep full /etc/asterisk/log*

(look at the custom thingy)

Here is a new pastebin:

As surmised previously, you are not sending the trunk to [from-pstn-e164-us] , do so and it will likely work.

Now fix your “logging” duplicates.

1 Like

I have no idea how to fix my logging duplicates unless it doubles when I have the cli open and reporting?

As expected, using from-pstn-e164-us removes the “+”. It still leaves the “1”, so I get 11 digit delivery. I can, obviously live with that since redial works, but “before” I was getting 10 digit delivery and my phonebook entries are set to recognize 10 digits. Avantfax also would like 10 digits so that I can use DID routing.

I suppose I should leave well enough alone; however, is there an easy fix to drop the “1” without mangling the (very) rare international call I receive? I’ll even settle for mangling the international calls .

Andrew

remove the line that logs to /etc/asterisk/full in your custom file

Yes, it makes an 11 digit did, feel free to edit it, it won’t be overridden. if you want to try it a very simple

[your_custom_trunk]
exten => s,1,Goto(from-pstn,${EXTEN},-10)

It should work fine for any and all provider’s formats if you are only using NANP DID’s

the [your_custom_trunk] goes in /etc/asterisk/extensions_custom.conf?

I don’t understand what line your are referring to in my ‘custom’ file. My logs are in /var/log/asterisk/full

edit:

I created
[MyTrunk]
exten => s,1,Goto(from-pstn,${EXTEN},-10)

in /etc/asterisk/extensions_custom.conf

and changed the context in the trunk to MyTrunk. Calls get sent to voicemail

Andrew

Why are we not seeing the custom dialplan context you posted originally being hit in this debug? Everything shows to be hitting from-pstn.

This is the first match in the from-pstn-e164-us
exten => +1NXXNXXXXXX/+1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):2})
exten => _+1NXXNXXXXXX/_NXXNXXXXXX,2,Goto(from-pstn,${EXTEN:2},1)

This matches on an E.164 INVITE DID and From User. The way flowroute sends things. It strips the +1 of the CallerID number and the +1 from the INVITE DID.

So a call that would match +13132224444/+12124445555 would have the CALLERID(number) set to 2134445555 and the inbound route would have to match 3132224444

Show us that is or isn’t happening when using that context.

If you never paste your logs, you will continue to be encouraged to, is it hard to understand that otherwise “nobody knows” ?

Your logs are "twice " in /var/log/asterisk/full ,and that’s because you have two logfile definitions to /var/log/asterisk/full in two/etc/asterisk/*logger* files

dicko,
I have what was installed by default. I’m happy to edit a file, but I still don’t know what file to edit to remove the duplicate entry creation.

Oddly, from-pstn-e164-us delivers 10 digit #s to all of my SIP phones. My dahdi line - which is the handset I look at most and have been using - still shows 11 digits.

In other words, extension 2000 (a Yealink) shows Andrew - Cell and the 10 digit number when I call in
extension 1000 (a handset connected to my TDM800P) shows Andrew - Cell and 1-800-555-4444.

Looking through all the logs, the +1 has been completely dropped.

So the question is what setting in my dahdi config has the +1 being shown?

Thanks for everyone’s help. I’m not sure I can expect this one to be solved.

Andrew

Is the incoming DAHDI trunk/config set to use from-pstn-e164-us?