Rewriting inbound caller IDs?

[fred.bloggs]

---------------------------------------- Part 1: regarding your reply----------------------------------------

Quote

 You can set the contact header explicitly for the trunk to the E164-formatted number—would that solve the problem in all cases (and set the number interpretation for the trunk to E164)?

I know how to change the number interpretation for the trunk ("rewrite global numbers"). But I do not know how I can set the contact header explicitly to E164 format. Can you please advice how to do that? If this would be a setting we have to change on the easybell side, that is not possible, as there is no corresponindg setting on theire side.

I tried to set "contact header value" to "{to}" on the trunk settings. But that did not help.

Quote

The alternative would be to have the PBX look at the To-header, and not the Request-URI for an incoming call

Please also advice how to do that.

---------------------------------------- Part 2: general ----------------------------------------

In the easybell trunk I configured "rewrite global numbers" to "E.164 (without leading +)". The TO is correct "0711-xxxxxxx"  but now the FROM is wrong "00-0153xxxxxx".

If I change it to "Use + symbol at beginning" or "For Row", the TO is wrong "0711-49711xxxx" but now the FROM is correct "01538-123xxxx".

So depending of the trunk setting, one is always correct but the corresponding other value is always wrong. I can not manage to get both numbers recognized correctly by Vodia.

 

As in my previous post, here is how easybell announces the call on a Trunk that has multiple numbers:

INVITE sip:49711xxxx@yy.yy.yy.yy:49326;transport=tls;line=xxxx SIP/2.0
Via: SIP/2.0/TLS zz.zz.zz.zz:5061;branch=xxxx;rport
From: <sip:0153xxxx@sip.easybell.de>;tag=xxxxx
To: <sip:49711xxxx@sip.easybell.de>
CSeq: xxxx INVITE
Call-ID: xxxxx
Max-Forwards: 68
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK
Supported: histinfo,from-change
Content-Type: application/sdp
Content-Length: 555
Contact: <sip:2D7xxx-xxxx-xxxx@yy.yy.yyy.yy:5061;transport=tls>

BUT a Trunk that has only one number assigned from easybell (also a trunk but other product) is announced like that:

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP yy.yy.yy.yy;branch=xxxx;rport=5060
From: <sip:0153xxxx@sip.easybell.de>;tag=xxxxx
To: <sip:0049711xxxx@sip.easybell.de>;tag=xxxx
Call-ID: xxxxx
CSeq: 157 INVITE
Contact: <sip:0049711xxx@4yy.yy.yy.yy:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Allow-Events: refer
Accept: application/sdp
User-Agent: Vodia-PBX/66.0.7
Content-Type: application/sdp
Content-Length: 204

In this case however both the TO and FROM are recognized correctly by Vodia with the current trunk template. Note how easybell formats the TO in a different way.
 

So I would appreciate, if you could modify the template in a way that both variants (trunk with multipe numbers and trunk with single number) would work, as we have different trunks form easybell (multi- and single numbers).

If you need any other information to modify the template, feel free to ask. I am happy to help.

 

 

[Vodia PBX]

What you can do is for the single number account just assign in the trunk settings where to send the call to a specific account:

For the multiple account trunk, in Germany usually you can just look for a prefix:

For example if you have number 0305550..0305559 you could use 555 as the prefix and then assign 0..9 to your extensions and accounts.

We'll make an update for easy bell so that this weird 00 or not behavior automatically gets resolved.

[fred.bloggs]

Ok thank you, the prefix search is the way we already do it.

Its' just in the system mails (e.g. voice mail) the users see the wrong formated numbers. But if you are going to modify it with a trunk template update, that is highly apreciated! Thank you. Are there any ETAs for the update? I can also test it upfront, if needed.

[Vodia PBX]

If you like, try the latest 66.0.7 build this should include a new setup for easybell. You'll have to set up a new trunk though. 

[fred.bloggs]

Quote

If you like, try the latest 66.0.7 build this should include a new setup for easybell. You'll have to set up a new trunk though. 

Tested with version 66.0.7 build Jan 25 2021. Works perfectly, for both type of easybell trunks now!

Thank you very much for your fast support 

[koolandrew]

There doesnt seem to be any reference materials on "Rewrite Global Numbers" under Number/Call Identification for a trunk. could you please provide the correct slection for the following scenario.

A tenant/domain that has the following and is using 1 as the default country code

1. Ten digit North American DIDS

2. International dids (it defaults to 011 -country code then number)

It appears that there is not one trunk setting that would work for both types of numbers.

 

Please advise.

[koolandrew]

If this is not possible, please advise. Thanks

[Vodia PBX]

The trunk has somewhat its own life when it comes to the number presentation in the tenant. It is mostly about presenting numbers when generating outbound calls, however also for inbound calls the trunk needs to understand where to send an inbound call. For example a tenant located in the USA might have a trunk in Mexico where numbers must be presented in the local format and not in NANPA format. Because of this, the trunk has its own country code and number presentation settings. 

[koolandrew]

Thanks for replying, unfortunately that answer creates more questions so here we go, as what you are mentioning is probably fairly common, except the part where the Mexican, UK and USA numbers come from the same provider???????????? and or sent to the same provider?? I believe that is much more common that having a local trunk in the varying locales.

1. How do we separate inbound trunks in that situation as both calls are being received from the same provide/ip address etc but they have to be treated differently otherwise only one of them will work.

i) Using the Rewriting global numbers designation, international calls have to be treated using the selection "e.164 without the leading plus" and for 10 digit north american dids you would need to "Use + symbol at the beginning" for international and north american dids respectively.

2. For outbound, how can we display e.164 for the caller id for a trunk that needs a Company Name and +44123456789 (for example) when the country code is for the tenant is set to 1?

As far as we can tell, the best you can do is send 01144123456789 (for example) as the "Number Presentation" that you are referring to above, are for the dialled number, not the caller id presentation.

Again if this is not possible to resolve, so be it. Vodia has a lot of great features.

[Vodia PBX]

Of course the same provider can service multiple countries and most actually do. However they will represent the numbers hopefully in the same format, ideally something that starts with a + to make it abundantly clear. 

Is the problem in the inbound call or the outbound call? 

[koolandrew]

As mentioned in the previous post, it is for both.

 

• •  

Posted Thursday at 02:39 PM

Thanks for replying, unfortunately that answer creates more questions so here we go, as what you are mentioning is probably fairly common, except the part where the Mexican, UK and USA numbers come from the same provider???????????? and or sent to the same provider?? I believe that is much more common that having a local trunk in the varying locales.

1. How do we separate inbound trunks in that situation as both calls are being received from the same provide/ip address etc but they have to be treated differently otherwise only one of them will work.

i) Using the Rewriting global numbers designation, international calls have to be treated using the selection "e.164 without the leading plus" and for 10 digit north american dids you would need to "Use + symbol at the beginning" for international and north american dids respectively.

2. For outbound, how can we display e.164 for the caller id for a trunk that needs a Company Name and +44123456789 (for example) when the country code is for the tenant is set to 1?

As far as we can tell, the best you can do is send 01144123456789 (for example) as the "Number Presentation" that you are referring to above, are for the dialled number, not the caller id presentation.

Again if this is not possible to resolve, so be it. Vodia has a lot of great features.

[Vodia PBX]

For inbound, the PBX needs the setting for the number presentation only when there are ambiguous interpretations. For example 6173998147 means in NANPA +16173998147 while in a European context it could mean +49306173998147. The question which trunk the PBX will associate with the call is described in https://doc.vodia.com/docs/trunk-inbound-routing.

For outbound, the PBX generally comes up with a CNAM and the ANI for the call. You will see the various presentations in the log when you set the log level to 9 for trunks. All you have to do is to pick the right variable and then put it into the header with a {xxx} pattern. The variables are generated based on the number presentation settings for the trunk. See https://doc.vodia.com/docs/trunk-custom-headers for the headers.

We have had cases where a trunk provider needs different formats, e.g. the request-URI needs a different presentation format than the To-header. Such cases need to be handles in JavaScript, which is a separate topic.

Of course if the trunk provider is on the drop down list, all of that stuff is already done for you.

[koolandrew]

Regarding this topic, it begs more questions unfortunately.

1. How can we place a + in front of the caller id whilst using the 1 as the domain country code. When using that setting for Global numbers it puts the + in front of the dialled number as well

2. Regarding the link for Trunk Custom Headers, there is a reference to

Caller-ID fields

For the fields from, to, ppi, pai and rpi the system generates the following content (xx will be replaced with the actual field name):

For example,

{ext-ani-no clip}

a valid example?

3. Is this a valid string for Regular ANI rule as it is not mentioned.

from-ext:ext-ani  !clip:!from-trunk:ext-ani !clip:!from-trunk:trunk-ani !clip:!disa:from !clip:ext-ani !clip:!disa:from !clip:trunk-ani

4. We have tried using {ext-ani-raw} but it doesnt work as there is no caller id presented, as according to the instructions, and doesnt add a + to the caller id.

There is no way to add the + sign to the caller id on the extension or trunk as it changes it to 011 which is not acceptable for the carriers.

 

Please advise.