Outbound caller id adds plus in front of number

Hi,

I am using voip.ms trunk on freepbx.

Trunk
Dial rules
(1)|[NXXNXXXXXX]
(1519)|[NXXXXXX]

Peer Details
disallow=all
canreinvite=nonat
nat=yes
context=from-trunk
host=toronto8.voip.ms
secret=goodpassword
type=peer
username=123_voip
allow=ulaw
fromuser=123_voip
trustrpid=yes
sendrpid=yes
insecure=port,invite
qualify=yes

123_voip:[email protected]:5080

Outbound route
Dial Pattern
()|[18[04-8][04-8]NXXXXXX]
()|[NXXNXXXXXX]
()|[NXXXXXX]

I have outbound callerid specified: “GoodCompany” <1234567890>

So my problem is that freepbx adds a + in front of my number when sending it out so instead of 1234567890 showing up on people phones they get +1234567890 Some people we called said it looks like our number is from peru and we’re actually from canada.

Please help if you can.

This is almost the same problem as mine except this user has the plus issue on receiving calls mine is on outgoing calls.

Also i found this:

He appears to be having the same problem i am but i cannot quite follow how he fixed it.

This may help:

Removing the Plus Prefix

FreePBX includes a “context” which strips all but the final 10 digits from the CID string. There are several other threads out there, which say to create a custom context, but this is not necessary. On your inbound route, if you change this…

context=from-trunk

… to this …

context=from-pstn-e164-us

… incoming numbers will be the 10-digit format, which generally works fine in the US.

NOTE: In my version, that “context=” is in the Peer Details box for the Trunk.

Not sure if this is what you want, but I do think the dial patterns “prefix” field has your answer…

Hi,

Thank you for the response but i think you are misunderstanding my issue.
Its not for incoming calls. Its for outgoing calls that im having a problem with.

I’d like to see that from the /var/log/asterisk/full file. I’m not convinced the PBX is who is adding that, but I’m willing to review the tape just to make sure.

https://wiki.freepbx.org/display/SUP/Providing+Great+Debug?src=contextnavpagetreemode

Hi Dave,

I have attached a text file with the full log. Just rename to .txt extension and you should be able to open it.

full.tgz (616.7 KB)

@knowledgemonster and everyone else, this isn’t an issue you can solve. At all. The + being added is either being add by your provider before they push the call over the PSTN but most like this is the receiving carrier converting and presenting their calls to their end users in E.164.

Again, you have zero control over how the destination carriers present their calls to their own end users. Just like you have no control over if they accept your present CallerID or do a CallerID Lookup on their own.

EDIT: For the record +1 is the E.164 for North America (Canada/US) because +1 is the International Prefix for the US/Canada.

I found that on some “wiki” and as I implied it doesn’t match my version at all. If it was directly useful I would have put in a link to the “wiki”. I tried to get something you could copy-&-paste. The point is, that stripping & adding happens in the Trunk configuration. Or you could hack the dialplan…

Please read the post I made two hours before your reply. This is not an issue that can be solved on the OP’s side because it’s not an actual issue. The destination provider is presenting the incoming CallerID to the called user in E.164 format, not just the OP’s calls.

Tom,

Are you suggesting lots of people are having this problem and are just living with it?

I contacted voip.ms and they say they have no control over it… Not everyone who is using voip.ms trunk is having this problem. I know of one other company that is using freepbx and voip.ms and does not have this trouble. Its a big enough of a problem that if everybody was having it, i would think there would be a bigger uproar.

One temporary workaround is to put a 1 in front of the number in Outbound CallerID “Company Name” <15191234567> this might cause other call back problems such as “do not dial 1 or 0 before the number you are dialing” for landlines but then at least it does not say that i’m from peru.

Live with what? How their provider accepts/delivers calls from/to them? Yes.

Again, we are talking about how the CALLED (i.e. the party you are calling) is RECEIVING calls. Nothing that you or your provider have any control of. Just like how if your DID was called by someone, it doesn’t matter how they sent their CallerID to you, your provider will present the number and CallerID in the format of their choosing.

You have Voip,ms, correct? So that means that Voip.ms has told you “We are going to send you calls in X format. When you send us calls they must be in Y format”. That’s the same for EVERYONE. Only one of my carriers presents calls in 11 digit format (1NXXNXXXXXX) and will accept calls in 11 or 10 digit formats. All the rest present calls and accept calls in E.164 format.

That means if I want to present CallerID to my end users in a 10 digit format (no + or 1) I have to alter the CallerID when I get it from the provider into the format I want to present to my end users.

So again, as I have explained before, you (or any of us) have ZERO CONTROL on how the called party’s provider will present the call to them. On top of that, you (or any of us) also have ZERO CONTROL over the called party’s provider honoring the CallerID that you/we present. So you could present a CallerID number with a custom name but when the called party’s carrier does a CNAM lookup they would replace the custom name with what was in the CNAM database.

Thank you for taking the time to respond. Please keep in mind that im not trying to arguing with you just trying to understand.

What im not understanding is why does the caller id have a + in front of it when the call comes from voip.ms but not when the call comes from voipmuch both going to a bell cell phone?
AND
Why does the + not get added from 1 voip.ms number when calling a bell cell phone but it does when calling from another voip.ms number to a bell cell phone? (Like i mentioned early with my voip.ms number it does add a + but for another company i know they dont have problems with this)

The honest and quick answer that Voip.ms might not tell you, they are an aggregate (like me) and while they have their own network (like me) they use Tier 1 carriers to actually connect to the PSTN. In other words, Voip.ms doesn’t have a direct PSTN connection they use higher level carriers. So that means your call is kinda like this:

Your PBX -> Voip.ms -> (Carrier route Voip.ms sends call over) -> PSTN -> Bell Cell

So it is very possible that when you send a call to one destination Voip.ms is internally going “Oh that destination is cheaper over X route” and when you call another destination they go “Oh that is cheaper over Y route”. But it’s the same case, once those calls get to Voip.ms’s carriers they do what they want with the call and how they present it to the destination carrier.

That means Bell Cell is most likely honoring however the CallerID is being presented to them and some of the carriers Voip.ms use are presenting in E.164 and some are presenting in 11-digit or 10 digit.

But none of this changes the fact that this is all happening at levels that are way out of your control.

Case in point on all this: If you were to actually call one of my DIDs, my end user would 100% get the CallerID of your number presented to them in a 10-digit format. So this “issue” you are having would not be an “issue” for anyone on my network. Because I control how the CallerID is being presented to my end users.

IMO that’s not a temporary workaround, it’s the format with the least compatibility issues and the one you should be using. It is nearly certain that Bell, Rogers, etc. fixed lines will correctly display your number as 10 digits.

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