Hi, we’re running into a problem when 10-digit CallerID calls originating from the PSTN are subsequently sent from the followme module to PSTN showing up with +xx or +xxx on cell phones and as foreign countries on other phones.
Doing a search found a page which says to add the following to the followme section of the dialplan.
There is a context ‘[from-pstn-e164-us]’ that will likely work for you, but two or three digits on an external call suggest that you haven’t properly set your system to honor the outbound CallerID on your extensions , check your sendrpid and trustrpid settings aren’t getting in the way
This is a whole different thing and it’s been a week on IRC with this. Basically this is due to the upcoming STIR/SHAKEN and CallerID changes so certain mobile carriers (seen so far) are starting to prepend the ‘+’ on CallerID numbers.
The result is that a NXXNXXXXXX number, which is a correct NANP CallerID, is displaying as +NXXNXXXXXX. Which means +3135551212 would not come up as Detroit, MI it would look like a Netherlands call and when the user hits the call back/dial button from call history it sends it as +3135551212 so it looks like they are trying to make an International call.
About 2 hours ago (after a week of troubleshooting this) the OP showed that the call leaving to the PSTN was in fact 11-digits. What couldn’t be told was how the number actually presented to the destination because the OP forgot to ask.
So the OP has yet to validate if the upstream is touching this or what is actually showing up on the destination user side to confirm the fact they are getting 11 digits or not.
I will say that I had this reported to me last week by users and they weren’t using forwarding or followme. I fixed it two ways (and I told the OP this) 1) I updated all my CallerID to present 11-digits. 2) Tested my upstreams and removed the 1 that seemed to force 10-digits.
Not sure what you mean by 2 or 3 digits.
Just want to be clear, the issue ONLY happens with followme because some carriers still send out 10-digit CallerID. When FreePBX receives a call, goes to an IVR, caller dials extension number, no answer (if followme is enabled for the called extension) followme then dials the followme number and sends the CallerID orginally sent. And that is where the issue is.
The callerID from the caller needs to be altered prepending a ‘1’.
This problem is not specific to Follow Me. It would also affect blind transfer, call forwarding, ring groups or queues with external agents, etc. You should decide on a consistent format for numbers in your system. As needed, incoming calls should have a custom context to rewrite caller ID, and/or outgoing calls should have a hook to rewrite the caller ID before it is sent to the trunk. See
Dicko, what I meant by +xx and +xxx is this. Say the CallerID is 4165551212, the display on the PSTN cell phone will show up as +4165551212. And that means its country code 41.
How do you want a call from that number displayed on your IP phone (4165551212, 14165551212, something else)? How do you dial that number from your IP phone (4165551212, 14165551212, I sure hope it’s not 94165551212 or 914165551212)? What you see and what you dial should be the same, so returning calls from History works, saving calls in Contacts works, incoming and outgoing calls look the same in the CDRs, etc.
Once you decide on the format, set up the trunks so that incoming calls from all trunks use that format. Set up your Outbound Routes so you can make calls using that format. If needed, set up hooks so the caller ID is sent on each trunk in the format that the provider requires.
Seems we need to setup a hook so that followme calls use 11-digit format. But I have no idea on how to go about it.
It would be nice to have calls displayed as 10-digit format if the calls originate from North America.
Outbound route for North America is set when sip phones dial 10-digit number, outbound route will prepend 1.
Trunk for North America sip settings OUTGOING has context=from-trunk
on the INCOMING sip settings it’s empty.
Extension CallerID setting on every extention has “COMPANY NAME” <1NXXNXXXXXX>
For a half-assed fix, add this to your extensions_custom.conf:
[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(Entering user defined context macro-dialout-trunk-predial-hook in extensions_custom.conf)
exten => s,n,ExecIf($[ ${LEN(${CALLERID(number)})} = 10]?Set(CALLERID(number)=1${CALLERID(number)}))
exten => s,n,MacroExit
It will stick a 1 in front of any outgoing caller ID that is 10 digits long. You will have to do something better to handle calls from overseas properly. But what you have to do depends on details of your trunking provider(s) and a complete fix may not be possible.
For example, there are some clueless providers that on a call from +1 662 266 1234 (in Mississippi) will send caller ID of 6622661234. So far, that’s ok. But on a call from +66 2 266 1234 (in Bangkok), then they should send 0116622661234 or +6622661234 but they just send 6622661234, so you actually can’t tell the difference! In some cases, there may be a clue in P-Asserted-Identity or some other header.
@Stewart1@dicko Guys, I’m going to save you some headaches here. You’re not getting the full story. First, the OP has failed to point out they’ve been getting help with this in the IRC channel for over a week. The OP failed to mention that two hours before this post yesterday they showed that the call was leaving their network and going to the PSTN with an 11-digit CallerID number but failed to confirm with the user how it displayed to them on their cell phone. The OP also forgot to mention the mess of a setup they have which is:
Origination (PSTN) --> A2Billing Server —> Customer PBX --> A2Billing Server --> Termination (PSTN). So there is a second box that touches the call before the customer’s PBX and after it leaves the PBX. For termination the A2Billing selects from a list of termination carriers to send the call to. The OP also hasn’t looked at the difference between all the terminating carriers to see if they are manipulating the CallerID when it is sent out.
Please see my previous post as how my end users were reporting this exact same issue last week (same time I was helping the OP in IRC) and the two things I did to solve it. Those confused the OP in IRC when I shared them.
To wrap up, this is happening due to changes in carrier policies and how they are presenting originating calls to their end users. Some mobile carriers aren’t doing this yet. Not all destinations were seeing this issue when my users reported it, only certain carriers.
Basically welcome to 2020 the year that telecom had major changes to the industry and people like the OP need to actually know what is happening and what to do with it to not be hindered or impacted by these changes.
Hi Stewart1, I would like to see 10-digit TNs on call display on our sip phones. From what I am hearing rules are being put in place to make use of E.164, again that is what I am hearing and have no proof of it.
That being said, if the laws in US/Canada are going to be such that callerID has to be E.164 then there is no choice but to use it.
At this point, I can say that every extension in FreePBX is set to “COMPANY NAME” <1xxxxxxxxxx> to make sure the caller doesn’t show up as some foreign country code.
To answer your question on the CallerID of 4165551212, on the IP phone, the 10-digit CallerID is fine. I can tell you from past experience, using that 10-digit format has caused the far side of the call to see it as +4165551212. I am not talking about call forward/followme here, talking about dialing local TN’s and the far side seeing the calls as coming from Turkey (+90). That’s when all extensions CallerID had the 1 added in front to make the CallerID 11-digits.
As an example, call just came in and looking at CDR in FreePBX it shows as:
“Toronto, ON” <416877XXXX>
If that call would have been forwarded out (which it wasn’t) to a cell phone provider (and this call was from a cell phone provider here because I know the number and the person), it would have shown up as something like +416877XXXX ) Hopefully your code you pasted above does work. Still have not seen any results yet.
for the last 40 years , in NANP land CallerID was 10 digits, even 7 , but that’s another story
The concept is all about “Least Significant Digits” it is impossible in NANP land that either 10 or 11 digits can be misinterpreted, some locales use 10, some 11 and some use both.
“+” is a “meta” concept, in the US it is translated to 011 for an outbound call, but for an inbound call ‘1’, in most of the rest of the world, it is translated to “00” for outbound and also commonly ‘1’ for inbound, this is a conceptual result of BellCore enforcing 1 as a definitive “Most significant digit” for NANP. Few phones either land line or cell have an actual + key, if you ‘long press’ 0 on a cell phone GSM rules say to interpose the locales interpretation of an expected international call (+),.
In any locale the user is used to dialling and seeing “whatever”, it is you as the provider to “normalise” both, First, your client recognizes what it means and second, they can actually redial that number , that seems to be the gist of this thread, to which I say “support them all, inbound and outbound. It’s easy” .
In my experience most reputable VSP’s will accept NXXNXXXXX, 1NXXNXXXXX and mostly +1NXXNXXXXXX as valid destinations for an outbound call. Conversely, many will present inbound calls with either one of the above or “by your choice”.
That Cell phones are reasonably expected to become compliant to legally using these rules and being able to have a reverse look of their +NNNNNNNNNNN is what shake and bake is all about.
So , 10 digits is good , 11 digits is good , +X. and your presented callerid number is good and resolves to an e164 number X.
If the carrier cannot reverse 10 or 11 LSD digits to the originator, then at least in NANP land the call will be shaked and baked, and all that is completely on the Carrier, they get to pay for misfeasance, not you
Hi Dicko, what you wrote is very interesting. You say “10 digits is good” but we have the experience when Outbound CallerID is set with “NAME” the far side of the call sees it in their phones as (for example) +90XXXNXXXXXXX which really causes problems. The only fix I could think of was to add 1 <1NXXNXXXXXX>.
From what you are also saying, the problem lies with the carrier. But which carrier? The carrier we use on outbound or the carrier for the far end phone?
i would start with your carrier if you have just one, its the only one you have access to. Presumably they told you what they want. and you can add trunk specific rules to suit if needed.
But your users should always be allowed to dial the way that is ‘conventional’ in their locale. If you cover more than one locale, add rules so everyone is happy,
my preference is to present my users with e164 digits, stripping off any + from NANP calls and replacing it with 011 for international calls, for inbound calls,. For outbound calls I accept 10 or 11 or +11 dials as NANP , initial +[2-9]. or 011N. are always international (as are several Caribbean area codes. ) . That way soft and hard phones, redialing and phone books will all work
off course short codes should be supported too. e911 of course and tranlating other ones like 311 and 411 approriately.
Hi Dicko, our outbound routes have a prepend of 1 for all NXXNXXXXXX but our problem is not on our clients dialing out. The issue is ONLY present when an inbound call hits IVR -> extension # -> office phone rings, no answer => followme. The CallerID will be that of the origination caller. Many or most times it’s 10-digits. The part I don’t get is when the origination caller calls, none of the clients say it shows up as an e164 format (+90XXXXXXXX)
I have a service in Israel where my kids can call a local number there and then press 1 and it dials me. The call shows up exactly as I would dial it, that is without the leading +. Just the country code and cell phone number.
By the way, our carrier for our DIDs has told me they can put us on a newer platform but there are some limitations from what they wrote. Here is what they sent me:
Our other platform is the core of our infrastructure, Metaswitch.
You lose ALL self-serve options going through route.
We should be able to manipulate the CallerID to add a 1. We can definitely provide E164 as well.
You should be moving towards E164 to prepare for the growing restrictions on CLID to prevent fraud and spoofing.
inbound call manipulation is up to you, way earlier in the thread the asterisk e164 context was brought up if you look at it, normalized NANP calls are considered 10 digits, by historic reasoning, inbound international have any initial + replaced with 011. But there is a valid argument nowadays for NANP calls to be normalized to 11 digits , allthough NXXNXXXXXX assumes an initial 1 for e164 , by MSD routing reasoning all LD calls begin with 1, and increasingly the RBOCS and CLECS of the eorld are requiring 11 digits. All international or operator calls begin with 0 , 2-9 can only be local or short codes and 7 digit local calls within your area code are mostly a thing of the past but some folks like to maintain it.
the format of the inbound id is again carrier specific, so if you have more than one, be prepared to massage them individually perhaps with different contexts
