SIP Trunk rules/stripping saves wrong number in the Phonebook (loses the E164 format)

Status
Not open for further replies.

pawsius

Free User
Joined
May 20, 2020
Messages
5
Reaction score
0
I have a 3CX system in the UK connected to an Avaya system in France via a 3 channel SIP trunk. It works perfect. Both have external SIP connections in their respective countries so calls form UK into the French landline and mobile network are essentially free.

In the UK, when we dial a +33 xxxxxxxxxx number the outbound rules strip the +33 and add a 5 to the start which then sends it down the SIP trunk to the French Avaya system. The French Avaya then recognises the 5 which it strips and it routes to the external French network by appending a 0 to the start. The same happends in reverse and all is perfect...

except when it comes to the phonebook storage in 3CX. Despite the number coming from the phonebook as +33 xxxxxxx, it stores the number dialled +33 xxxxx (in Call History) as the stripped down.. 0XXXXXXXXXX. It doesnt keep the full international original format of the number. This means that to re-dial, we have to go back in the phonebook and look it up again rather than a quick redial from call history. Obviously the rules dont pick up on the number to act because the E164 format is now lost.

Any ideas how we can force it to keep the E164 format??
 
Making the call from either the Android App or the Windows Browser extension or Windows App. We have the latest standalone internal server based linux V16.

We dial from the Mobile Phone or PC phonebook in the app (not the 3CX internal phonebook). It will correctly take the +33 XXXX format number from the mobile phonebook and the rules recognise the +33 at the start of the number which they strip and append a 5 which is then sent down the SIP channel to the French system. But the number is not stored in the Call History in its original +33 XXXX format but rather as 0XXXXX. It seems the E164 has removed the Country Code header. The number cannot therefore be redialled from Call History.
 
Hi pawsius

You might notice that if the call is not answered, the call history retains the correct number. Can you please confirm if this is true?
 
Hi John

Well spotted. Yes if a call is not answered it does retain the country format. But if it is answered it strips the country code. To be more exact if the French number is stored as +33 xxxxxxx and it is unanswered, it will store it in call history as 0033 xxxxxx - so it does still perform a minor reformat by replacing the + with a 00 (but that is no problem since my rules can forward down the SIP trunk both +33 and 0033 to France.). So we must be nearer to a solution? Why does it keep the format for unanswered calls and strip the country code in call history if answered? Most importantly, how can we prevent this?
 
Thanks for confirming. This has already been identified and it is planned to be addressed in a future release.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,951
Messages
589,886
Members
164,843
Latest member
sambannoura