Need for translation rules.... but how?

[TinyLittleAdmin]

Hi community,

I've alread tried to get some info about this in the german section of this forum... wasn't very successfull so far. So I'd like to take the chance here. im not a cube or ccm pro - so i would be very thankfull for help. my situation:

a local service provider (sp) changes telephony from classic QSIG/ISDN to SIP. on the client side is a very old callmanager (ccm) which itself doesn't support sip trunks. so an older cisco 2800 is in place and prepared as CUBE. the setup is:

sp <> cube <> ccm <> cisco ip phone

lets say the reginal number is 99999, internal numbers are 400650X  (so range 4006500 to 4006510).

in general that works fine, the sip trunk is established. incoming calls (from sp) and outgoing calls (to sp) work fine. here comes the but: outgoing calls dont get the right number. it looks like the internal phone number reaches the cube and is than directly forwared to sp. the sp than simply adds the regional code and "ignores" the internal number and just uses the first one in the range. whats happens is: a call from internal number 4006504 which should reach a mobile as 999994006504 is instead shown as 999994006500.

so i think i need a translation rule for calls from ccm accross the cube to sp that takes the internal number and adds the regional code in front of it.

i've tried some translation rules and added them to the dial peers - but it changes nothing. there are in total five dial-peers:

sp to cube, ccm to cube, cube to sp, cube to ccm (subscripe), cube to ccm (publish)

i think my problem is that i didn't really understand how translation rules work and how to bind them to the correct interface/dial peer.

thanks for your time and help.

[Maren Mahoney]

If your old CUCM does not support SIP trunking, I would imagine that you have acquired the CUBE as an H323 gateway. The first thing I'd do is look at a debug of H323 incoming to the CUBE to see what digits CUCM is sending. Alternately, you can look at the trace file in CUCM to look at the outbound signaling.

Then, identify what your CUBE is sending to the service provider. What does the INVITE out to the SP look like? Does it have the actual caller ID or the 'main number' caller ID?

It is entirely possible that your service provider is overriding the caller ID with the main number, rather than it being an issue with what you are sending. That is common with ISDN and the service provider may not have changed that behavior.

Maren

[Nithin Eluvathingal]

If your DID is 400650X, and if you are sending calling information as 4006504 ISP wont translate this to 4006500. They does this, if you are sending calling number other than your DID block. 

Take debug CCapi inout from gateway. 

As an alternative for translation You can use external phone number mask on extension and on RP enable "Use Calling Party's External Phone Number Mask"

[Roger Kallberg]

The SP might very well translate the called number if it is sent in the wrong format, not just if it's sent outside of assigned range.

[Roger Kallberg · Accepted solution]

If your internal range is 400650X and you'd want to show the number as 99999400650X when you make a call out. To achieve this you would need to have this configuration.

voice translation-rule 10
 rule 1 /^\(400650.\)$/ /99999\1/
!
voice translation-profile PSTN-OUT
 translate calling 10
!
dial-peer voice 110 voip !your outbound dial-peer toward your service provider
 translation-profile outgoing PSTN-OUT

For more details look at this document Voice Translation Rules - Cisco

[TinyLittleAdmin]

Thanks Maren and Nithin.

The connection is SIP only - sp to cube is SIP and cube to ccm's too. in the routers debug log (which is a ton of infos....!) i can find some entries showing the correct internal number 4006504 and the correct target number for the mobile phone.

meanwhile i found an info sheet from the provider saying that they always expect the full number for the target (called number). so i should try to set cube and/or ccm to send 999994006504 instead of just 4006504. i'm going to test it with the external phone number mask setting.

[Nithin Eluvathingal]

If you want  to use voice translation, try the configuration @Roger Kallberg shared.  

[TinyLittleAdmin]

Dear all - and especially Roger,

that solved it! Amazing!

There is now just another "problem" but I think it's again something I can solve with the right translation rule. On the mobile phone the incoming call from an internal phone is now shown as "+49999994006504". (+49 for germany). that is fine in general. the call works. But if the mobile uses the number to call back - the call reaches the internal Cisco phone also with the starting "49" - so the cisco ip phone shows "49017029xxxxx" as caller. And the ccm doesn't know what to do with that number if you try a call back. So I think I need a translation rule for incoming calls from sp to cube that removes the "49" and replaces it with a "0". Or - the other way around: an incoming call from the ccm to the outside world accross cube with a starting "49" to be replaced with a "0". Thats again... my problem to understand the logic of call routing/translation.

Have a great day!

[Roger Kallberg]

If you need to manipulate calling and/or called number in the direction towards CM you would simply create the appropriate voice translation rule and profile that you attach, in the outbound direction, on the dial-peer used for sending calls to CM.

Basically you could as a starting point take what I suggested for the outbound direction to PSTN and modify it to fit your need towards CM. For this you'd create a new rule, attach it to a new profile as the type of number that you want to modify and attach the profile in the outbound direction on the dial peer towards CM.

[TinyLittleAdmin]

Hi Roger,

thanks again for your time and great help. To be fair.... I'm still struggling with all the call routing things and to understand how they work. Do I need an "incoming" or an "outgoing" translation profile? Do I have to use a "called" translation rule or a "calling" one? Which one is the right dial-peer?... But it's getting better.

At the end - with a bit of time I found the correct solution to be this:

voice translation-rule 5

rule 1 /^49/ /00/
rule 2 /^\+49/ /00/

What I didn't know.... the ccm is set to use an extra "0" for outside calls. So therefore I've set the rule to use "00". But know everything looks fine.

[Roger Kallberg]

Recommend you to think about calls coming from someone outside of Germany. Your rule would only cater to calls from anyone that originates from +49 or 49 without a + in-front.

To your questions, without an insight into the details on your configuration it's practically impossible to give you an answer on what is the "right" dial peer.

It would be calling number that you should modify with your rule(s) and it could be attached either in the inbound direction on the inbound dial peer from you service provider or you could put it in the outbound direction on the dial peer that sends calls outbound to CM.

For a wealth of information on how dial peer matching and call routing works in IOS please see this fantastic document. https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html

[Roger Kallberg]

Something similar to this could be what you’d need to cater for calls that originates from outside of Germany.

voice translation-rule 5
 rule 1 /^49\(.*\)/ /00\1/
 rule 2 /^\+49\(.*\)/ /00\1/
 rule 3 /^\+\(.*\)/ /000\1/

Not sure if you actually need to have rule 1, but as you had it in your post I included it.

[Roger Kallberg · Accepted solution]

Or as an option you could configure call routing for +E.164 formatted numbers in CM.

My personal commendation would be to go with a pure +E.164 setup, ie go with DNs in +E.164 and setup call routing to handle calling to +E.164 external numbers. You can still support calling in localized formats, but that would be an overlay on the top that uses the underlying +E.164 call routing.