Solved E164 Format and Call Processing

Status
Not open for further replies.

TecMate

Bronze Partner
Advanced Certified
Joined
Nov 17, 2017
Messages
38
Reaction score
24
Recently our SIP provider (Skyetel) started adding the "+" in front of [country code][subscriber number]

I.E. +12065551212 instead of just 12065551212

Because all of our DIDs were listed in 3CX without the + in front of the number (not E164 format) the calls were being rejected.

Adding a + in front of all our DIDs for incoming and also adding a + to Prepend on all our Outbound Rules fixed the issue but I was wondering how does 3CX process E164 formatted numbers on INCOMING calls?

Is the E164 format not assumed? Or is this totally dependant on the SIP trunk template?

I couldn't find anything about E164 or number format here https://www.3cx.com/blog/docs/voip-provider-template/

I know there is page under 3CX Settings for E164 but this seems to only apply to how 3CX processes numbers from the client side.
 
Hi DanTron,

I think you will find it is based purely on template, I don't believe that Skytel are a supported provider (or at least they are a U.S based company and I don't see them on the U.S supported list) so it does beg the question of why use an un-supported provider ?

With that being said have you talked to them about why they have changed this behavior as well as applying for support: https://www.3cx.com/partners/sip-trunks/voip-provider-interop-form/

FYI they should be SIP Connect certified also: https://www.sipforum.org/technology/sipconnect/
 
Hello @DanTron

Please note that your issue is not related with E164 numbers but with that fact that when your provider changed format, the incoming numbers did not match your DIDs. As i am guessing that your provider does not support rInstance you were facing source identification issues.
You would still face the same issues if the provider changed their format to 00120****** simply because the number would not match.
 
If you had used a * ,as a wildcard on your DID numbers, then anything sent ahead of the remaining X number of digits should route correctly. https://www.3cx.com/docs/manual/inbound-did-call-routing/

Your provider should have given advance notice of the change, to avoid the issues it created.
 
Thank you guys for your great feedback. It is very much appreciated.
leejor: Yes, adding a * in front of my DIDs did solve the issue. Thanks for that!

eddv123: I'm using Skyetel because they are awesome. Their support and service model are excellent. Their support engineers were immediately onto this when it occurred to help me troubleshoot and correct the problem. Which is also why I am currently in the process of helping them become a supported 3CX SIP Trunk provider.
 
Glad to see the issue has been resolved and thank you for updating the thread with your solution.
 
Status
Not open for further replies.

Forum statistics

Threads
111,893
Messages
589,595
Members
164,760
Latest member
SaschaA_