How to strip a + from the caller ID, SIP trunk 1

[ejvl]

Hi,
We've a CM 7.1 with Session Manager and SBC's.
Our customer has about 400 locations and many stations need a caller-ID.
Until now, we use the "private numbering" in Avaya, that works fine but the "private numbering" table is limited for about 500 entry's so this table is full now.
The trunk is CM is private and the routing tables are unk-unk.
The only possibility is that we use the "public unknown numbering "table, this table has much more entrys.
To I copied all the entry's from the private to the public table (with Provision), that works fine.
I've created a new route pattern for testing and replace the unk-unk to public.

When I call outside with my test station (9999), the public table is leading, that works fine.
But there is a problem.

I live in the Netherlands, all numbers starting with a "0". So for example I want tot send out 012345678 with my station, I fill the "public numbering" table to send this number, EXT 4, number 0123456789 and the correct Trunk.
When I test, I receive +0123456789 or with another provider in the Netherlands, +123456789

We call out by the Avaya Session Manager so the "repend '+' to Outgoing Calling/Alerting/Diverting/Connected Public Numbers? y" in the signalling group cannot be changed because it's a SIP trunk.In the Trunk this option is set to "No".
So I've tried in the adaptions in the System Manager / Routing.

This adaption is selected in the "SIP Entities" (System Manager / Routing) and this entitie is used in the Routing Policys. SIP Entity as Destination.

But whatever I try, this + is always send and cannot be removed.

Is there a possibility to strip this + and use the Public Unknown table because of the limitations of the private table?

Tnanks.

 

[kyle555]

Numbering format (public/private) is determined based on a number of factors.

If the trunk group has public numbering, then all calls over it will use public numbering.

If you're ultimately using private numbering, then the call uses the private table.

Maybe you can make those test route patterns use a numbering format of natl or pubu/public unknown to leverage the public table.

The adaptation you referenced - is that on the CM entity? If so, that digit conversion would only apply on "outgoing calls from SM" - as in, when it goes from SM to CM. If that adaptation is on the CM SIP Entity, you'd want the conversion on "incoming calls to SM" such that the changes happen when CM sends to SM.

 

[ZeroZeroOne]

Ah! The dreaded plus! There are a couple of places you can change the behavior and remove that leading +.

In the Signaling Group that is used for your public SIP traffic, change the Peer Detection Enabled to n and set the Peer Server to Others. This opens up the next field for you to change.
Set Prepend '+' to Outgoing Calling/Alerting/Diverting/Connected Public Numbers? n. Now all traffic from CM to Session Manager will not include the leading +.

I do this for CM trunks that will handle SIP PSTN calls. No Adaptation needed in SM to remove the plus.

If you do want to use an adaptation then you also have options. In general I do not recommend putting Adaptations between CM and SM but I do see it a lot. That's just my general rule so feel free to ignore it. That Adaptation would look something like this:

You want to remove the + that is sent FROM CM so that goes in the "TO SM" portion. We're talking about the TO: header so we want to specify the DESTINATION as the Address to Modify. This Adaptation would be applied to the CM SIP Entity.

Lastly, if you want to keep the + on all your internal routing and just strip it when sending to the SBC, then you'd use a similar Adaptation. This time, you'll strip the + as part of the Outgoing Calls from SM:

This Adaptation would be applied to the SBC SIP Entity.

In both Adaptation I've selected the DigitConversionAdapter as the Module Name. Stick with that unless you need something specific for your carrier. You can read up on the different Modules in the Help documentation.

 

[ejvl]

Thanks @ZeroZeroOne
The Signalling configuration is the trick.
The adaption configuration won't work, still get the +0123456789 but doesn't matter, the signalling works.
Thanks!