SIP provider now sending E.164. What all needs re-configuration?

[Gordon Tremeshko]

CUCM 12.5 rookie here.

My SIP provider recently implemented E.164 and now I am no longer receiving inbound calls (outbound still working). Example: they were sending 01135319041234 and now I am receiving +35319041234. What items do I need to update?

Ive tried updating my existing Pattern Definition with the Translation Pattern of \+35319041234 but that does not seem to be the fix. What else am I missing? DO I need a new Transformation Pattern/Profile as well? I was also looking at Route Patterns but those appear to be for outbound calls, which are currently working as expected. Thanks in advance for any advice.

[Roger Kallberg]

I assume that you might have had some translation rules in your SBC that translated the number you used to receive from your service provider, ie 01135319041234 to your directory number? If so you’ll need to modify that to fit what they now send to you, ie +35319041234. You should also look at what you match on the outbound dial peer towards CM and modify that as needed. It all depends on where and in what direction you apply the translation in the SBC.

If you don’t have translation rules in place then you’re using configuration elements in CM to facilitate the translation, as there are a few different options for this it’s not straightforward to give you advice on this based on the information provided so far. What I would suggest is that you run a DNA, Dialed Number Analyser, and select the SIP trunk for your SBC as the origin of the call and then insert the old format of called number into it as the destination to see what happens in CM when you receive the call. If you’ll need help to interpret the output please take screenshots of it a post here. It would also make it easier for us to help you out if you provide us with a little bit of details on how your directory numbers are formed, for example are they the last four digits of the DID or something else?

[Gordon Tremeshko]

Thanks, Roger. My Cisco skills are weak but here is what I can see.

I think by SBC you might mean our ISR4321 for ITSP trunk. I don't see any translation rules in the web GUI that I know how to access.

I do have 3 Translation Patterns in Cisco Unified CM Administration. 

I copied the 2 with 011 prefixes and altered to \+

the ITSP made some upgrades to E164 and no longer is processing 11 dialing. this all worked previously. I blindly assumed I could just update the '011' to '\+' but that was wishful thinking. 

DNA output looks like this

thank you again

[Roger Kallberg]

Yes by SBC I would mean a Cisco router, like the one you have, that acts as a Session Boarder Controller. Usually you would access the router CLI interface via SSH, not any webUI it may have as it’s not very useful usually.

Your DNA output seems to indicate that the call would be routed to a CTI RP named MainNumberCH that has a directory number that is 2900 in the partition named Inbound-Translation-PT.

[Gordon Tremeshko]

Thank you Roger. I was able to SSH into the router, find the destination-patterns and update them as needed.

[Shalid Kurunnan Chalil]

Hi, 

If I were in your position, here's how I might approach the situation:

Considering the flow:

ITSP (Carrier) -- SBC/CUBE -- Call Manager

When the ITSP sends a call with the number format (E164) +35319041234, I would check if the SBC/CUBE has a dial peer that matches the E.164 format. If not, I would recommend either using the session target as +35! or employing a translation-rule and profile to convert it to the format required for sending to the Call Manager if E.164 format isn't preferred.

Regarding the Call Manager configuration, I would ensure that the trunk inbound configuration is set to allow all digits, depending on our numbering plan, and modify the Translation pattern accordingly. 

Regards

Disclaimer:

Responses are based on personal knowledge and experience. Consider them as guidance. Other members may offer different perspectives or better approaches. No responsibility is assumed for outcomes; discretion is advised.