cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2474
Views
0
Helpful
1
Replies

SIP Called and Calling Number Transformation

aedamasceno
Level 1
Level 1

Guys, I need a little help with SIP Called Number transformations. I am going to be as specific as possible to try to explain the problem I am facing.

When I make a call using SIP, the transformations I make in the Route List are completely disregarded by the Gateway when the call reaches the GW.

 

Route Pattern: 0.[2-5]XXXXXXXX,
DDI Predot

 

RL-SIP: Standard Local Route Group
Calling Party Transformations:
Calling Party Transform Mask 119XXXXXXXX
Called Party Transformations:
DDI NANP:Predot
Prefix Digits (Outgoing Calls): 011

In the gateway, I have the following config:

This is an outbound transformation:

voice translation-rule 1
 rule 1 /^00\(.*\)/ /041\1/

voice translation-profile STRIP0
 translate called 1
 

dial-peer voice 1 voip
 description OUTBOUND
 translation-profile outgoing STRIP0
 destination-pattern 0[1-9].[2-5].......$
 session protocol sipv2
 session target dns:damasceno.com
 voice-class codec 1 offer-all
 voice-class sip options-keepalive up-interval 6 down-interval 5 retry 2
 dtmf-relay rtp-nte
 ip qos dscp cs3 signaling
 no vad

 

I need to send to the SIP Provider the number 041 before the actual number. Let's assume the number is 851234-5678, then I need to send to the provider 0418512345678. However, I don't want to show in the display as the final destination number. I wanna show only the 08512345678. When I make the configuration using H.323, I don't have this problem. But when using SIP, I see on the display what is being sent to the SIP Provider.

Do you guys know a way to hide what I am sending to the Gateway but keep the display? I always knew that when we use Route Pattern and Route List combined, whatever is in the Route Pattern is shown on the display and the Route List sends the correct transformation to the GW.

I already tried under voice service voip, sip, the command "no update-callerid", but it is the same as nothing. Please keep in mind that I have to send the call to the GW, I can't send the call from the CUCM straight to the SIP Provider.

Any hints?

Also I wanna know if it is possible to do in a SIP Trunk the Subscriber, National and International transformation for calling numbers, like we do it in Gateways to make them E.164 compliant.

 

Thanks

 

1 Reply 1

aedamasceno
Level 1
Level 1

Nobody answered this question, but I finally got it working. So, I am posting my own answer to another engineer who had the same problem as me. You can see it at: https://supportforums.cisco.com/discussion/11261101/globalization-and-sip-trunks

Hello Sam,

After a lot of research on my personal Lab, I was able to achieve Globalization in SIP Trunks. This is how I did:

I created two partitions, CALLING-XFORM-DP-PT, and CALLING-XFORM-TRK-PT.

One is for the Device Pool, and the other one is for the SIP Trunk. Create the CSSs and add your partitions > CALLING-XFORM-DP-CSS with CALLING-XFORM-DP-PT inside and CALLING-XFORM-DP-CSS with CALLING-XFORM-TRK-PT inside.

Now create two Device Pools, one for the Trunk and one for your Phones.

PHONES-DP and TRUNK-DP were the Device Pools I created. I am trying to be as specific as possible so everybody understands, so bear with me. :)

Now, put the CSSs accordingly. Go to PHONES-DP "Device Mobility Related Information" field and put CALLING-XFORM-DP-CSS there. Save and reset.

On TRUNK-DP you are not require to do anything, of course there is an "unless", but let's stick with your main concern, otherwise this post will be bigger than it will be.

Go to the Trunk itself and add the CALLING-XFORM-TRK-CSS to the "Incoming Calling Party Settings" field. Uncheck the "Use Device Pool CSS" and leave "Strip Digits" and "Prefix" fields in its defaults. Save and Reset.

Now, create your Calling Party Transformation Patterns. I will explain to you using the Brazilian national standard.

For Local Calls, here in Sao Paulo, we receive 11 which is the area code and 8 or 9 digits after that for local number. So, I created the Calling Party Xform mask as follows:

1 - 11.9XXXXXXXX > discard digit instruction: Predot > Prefix +5511
2 - 11.[2-9]XXXXXXX > discard digit instruction: Predot > Prefix +5511

I didn't change the TON or the Plan because it doesn't matter. SIP doesn't recognize these fields.

Now, same thing for national calls. We receive the area code and 8 or 9 digits. Since we already have specific Patterns for Local calls, it is ok to have a more generic pattern for other area codes

1 - [1-9][1-9]9XXXXXXXX > No Discard Digit Instruction > Prefix +55

For international calls, our SP always sends 00 in front of the number. Knowing that, it was easy to simply add the following pattern.

1 - 00.! > discard digit instruction: Predot > Prefix +

Now, you create the Calling Party Transformation Patterns for Phone Device Pools. Achieving Localization as well.

Local Numbers

1 - \+5511.9XXXXXXXX > discard digit instruction: Predot > No need to prefix anything
2 - \+5511.[2-9]XXXXXXX > discard digit instruction: Predot > No need to prefix anything


National Numbers
3 - \+55.[1-9][1-9]9XXXXXXXX > discard digit instruction: Predot > Prefix 0
4 - \+55.[1-9][1-9][2-9]XXXXXXX > discard digit instruction: Predot > Prefix 0
(in Brazil we used to have the numbers delivered to us as 0 + area code + number. That Prefix is just to achieve localization for us)


There is no need to do anything for International Numbers at this level, because if the number is different from +55, there is nothing to be done, just receive the +E164 format.


After all that you will be able to even do Plus Dialing. If you need any help setting it up, please let me know.

Don't forget that if your provider sends you the digits in a way that you can't do much on CUCM, try to identify the numbers by adding a translation pattern in your Trunk (if it is Cisco, of course) before the numbers enter on CUCM. Then use the Calling Party Transformation Patterns to strip off any identification you gave for the inbound numbers.

I hope this helps.