04-14-2022 05:57 AM - edited 04-14-2022 06:01 AM
Dear Community,
I have a setup of a Cisco 2800 router acting as CUBE and two callmanagers (6.2 subscriber/publisher). Besides all the other SIP stuff I've created five dial peers:
- incoming from provider
- incoming from cucm
- outgoing to cucm (2x with individual IPs)
- outgoing to provider
Outgoing calls work fine. But whenever an external caller tries to call us, it takes a few seconds, and than the call never hits the internal phone. The provider confirms the problem (on our end!) and describes it as follows: incoming calls are instantly routed back by our CUBE to the provider in a miss-formated way. As a result the providers environment thinks its a local/regional call and again add the pre-digits. So the basic problem: all these incoming calls are not correctly "terminated" on our end.
Our internal phones do have four digits. The pre-dial is lets say "+49445566". So the full number is +494455661234. Our cucm adds two "00" to any outgoing call by default.
I gues it's something with translations-rules? Or the call doesn't go the right way (dial-peer). At the moment I only have one translation-rule active. For any outgoing call it adds the regional digits prior to the internal extension.
I dont see the problem. In my very limited logic I'd say - if outgoing calls work (so caller id is correctly transmitted to provider), why doesn't it work for incoming...)
Thanks in advance.
Solved! Go to Solution.
04-15-2022 11:18 AM
Hi Roger,
your help is really appreciated. Ill do my best to get through all these infos. But for now I'm really confused. I can't find the reason why it has worked with the test numbers and now it doesn't for our normal extensions. Also checking all the syslog debugs.... sometimes it feels like I found something... but at the end I didnt. For example: I've seen that calls from the cucm dont come with a "+49" (germany). The called number ist just shown with a single "0" (instead of +49445566YYYY its 0445566YYYY). And those calls - work!
I'll take a break - maybe in a few hours.
04-15-2022 01:07 PM
Advise you to focus on one direction at a time and not go out on a tangent with non related information. What has the format of numbers for calls from CM into the gateway to do with the problem at hand? What your asking for help on is for calls inbound from your service provider to your gateway and then to CM?
04-15-2022 11:26 AM
Instead of presenting you with a ready made solution you’ll likely learn more by figuring this out in details yourself with a little bit of help on the way. Take in the advice given and the information shared in various documents, with this you should be able to get the configuration lined up and learn a few things along the way.
04-16-2022 02:16 AM - edited 04-16-2022 04:18 AM
Hi Roger,
I would fully agree to your point - without the fact, that there is now a phone system not picking up incoming calls for two days.... (smiley)
I'm am absolutley sure the error is either with this translation rule, we've used for the test phone numbers. Or a missing one, that doesn't fix incoming calls in a way, our cucm expects them.
voice translation-rule 1
rule 1 /^\(400501.$\)/ /04455\1/
rule 2 /^\+49/ /0049/
rule 3 /^49/ /0/
rule 4 /.../ /04455509&/
For the test phase the provider gave me a new range of numbers where only the last digit was for internal phones. So I've created two internal cucm attached phone having numbers 4005011 and 4005012. And everything worked fine. The full number +4944554005011 or +4944554005012 was reachable from outside, also outgoing calls worked fine. My understanding of that translation rule is:
rule 1 = every call with just 400501X gets the 04455 added in front
rule 2 = every call with starting +49 gets replaced with 0049
rule 3 = every call with starting 49 gets replaced with 0
rule 4 = every three digits number gets changed to 04455509 + the three digits
Now those test numbers are gone. Our internal phones do have three digits only (with full number +49445566XXX). So my explanation why this has worked during the test environment: calls to our normal phones NEVER went the way through the SIP trunk but still through the old connection. Only those for the test connection where handled by the SIP trunk. Which at the ends means: the setup of the cube was fine for those two test phones. But it never covered the normal phones. With that in mind I've checked the config on the router for the old connection - and found nothing. No patterns, no translation rules. Looks like "call handling" was done fully by the cucm.
The provider has confirmed that the problem is always the same:
- our phone system doesn't pick up the incoming call and sends it back
- but: the calls send back don't have the "+" in front of it (only 049445566xxx). so providers system things its a local call and again adds the regional "+494455"
- than the hole thing "explodes". but the basic problems still is - our end doesn't pick it up (smiley)
Meanwhile I've also tried Shalids "fix" which really makes sense to me (as I dont see +49 patterns in cucm) - but it doesn't help:
voice translation-rule 1
rule 1 /\+49445566\(....\)/ /0445566\1/
voice translation-profile IN
translate called 1
dial-peer voice 1 voip
translation-profile incoming IN
But I dont give up.... (smiley)
04-16-2022 06:19 AM - edited 04-16-2022 06:21 AM
04-16-2022 07:58 AM - edited 04-16-2022 08:00 AM
04-16-2022 08:51 AM
Try with this.
voice service voip address-hiding mode border-element licence capacity 1 ! voice class uri CUCM sip host ipv4:xxx.xxx.xxx.xxx ;IP for CPE Publisher host ipv4:yyy.yyy.yyy.yyy ;IP for CPE Subscriber ! voice class uri PSTN sip host ipv4:siptrunkXXX ! voice class e164-pattern-map 1 description E164 Pattern Map for called number to CUCM e164 +49445566... ! voice class e164-pattern-map 2000 description E164 Pattern Map for called number to PSTN e164 0T ! voice class server-group 1 ipv4 yyy.yyy.yyy.yyy preference 1 ;IP for CPE Subscriber
ipv4 xxx.xxx.xxx.xxx preference 2 ;IP for CPE Publisher description CUCM server group ! voice class sip-options-keepalive 1 description Used for Server Group SIP OPTIONS PING ! voice translation-rule 1 no rule 5 rule 1 /^...$/ /445566\0/ ! voice translation-rule 2 rule 1 /^\+49445566\(...\)$/ /\1/ ! voice translation-rule 3 rule 1 /^0\(.*\)/ /\1/ ! voice translation-rule 5
rule 1 /^49\(.*\)/ /00\1/
rule 2 /^\+49\(.*\)/ /00\1/
rule 3 /^\+\(.*\)/ /000\1/ ! no voice translation-profile 1 ! no voice translation-profile ccm_incoming ! no voice translation-profile cube_to_ccm ! no voice translation-profile cube_to_provider ! no voice translation-profile provider_incoming ! voice translation-profile cube_to_ccm-out translate called 2 ! voice translation-profile cube_to_provider-out translate calling 1 translate called 3 ! voice translation-profile provider_incoming-in translate calling 5 ! dial-peer voice 1 voip description incoming from provider to cube translation-profile incoming provider_incoming-in voice-class codec 1 session protocol sipv2 no incoming called-number +49445566... incoming uri via PSTN dtmf-relay rtp-nte no vad ! dial-peer voice 9 voip description outgoing to provider from cube no translation-profile outgoing ccm_incoming translation-profile outgoing cube_to_provider-out no destination-pattern . destination e164-pattern-map 2000 voice-class codec 1 session protocol sipv2 session target dns:siptrunkXXX voice-class sip options-keepalive voice-class sip audio forced dtmf-relay rtp-nte no vad ! dial-peer voice 11 voip description outgoing from cube to CM translation-profile outgoing cube_to_ccm-out no destination-pattern 0445566.... destination e164-pattern-map 1 voice-class codec 1 session protocol sipv2 no session target ipv4:xxx.xxx.xxx.xxx session server-group 1 voice-class sip options-keepalive profile 1 dtmf-relay rtp-nte sip-kpml no vad ! no dial-peer voice 10 voip ! dial-peer voice 2 voip description incoming from cucm to cube voice-class codec 1 session protocol sipv2 incoming uri via CUCM dtmf-relay rtp-nte sip-kpml no vad !
This configuration assumes that you send the leading zero for outbound calls, ie you need to remove the discard digit instruction on your route patter(s) in CM so that it is kept when sent to the gateway. That zero will be removed by voice translation profile cube_to_provider-out in the outbound direction on dial peer 9.
04-16-2022 12:20 PM - edited 04-16-2022 12:22 PM
Many thanks to everyone but especially to Roger! I had to change some parts of Rogers last config recommendation as some settings didn't work on my cube router (like "voice class uri with IPs and E164 pattern - maybe too old firmware?), but it's solved. I'll post the running solution later here. Now it's time for something cold to drink....
04-16-2022 12:50 PM - edited 05-02-2022 07:15 AM
And here is my working setup - which I've never could have done without your help. Please keep in mind - IPs are hidden and DIDs is not my original one! I've also only listed the important parts I had to change. If someone tries to use this in future - maybe you need this extra info: internal phones attached to cucm do have to dial an extra 0 to get outside. And the callmanager isn't configured to use E164 patterns ("+49" for germany). Most of internal phones have three digits extensions, but there are also a few with four digits. Also an attendant place is reachable via just one 0.
Works on two CallManagers with version 6.1.2.1002-1 (I know - very old!) and a Cisco router type 2800 dealing as "cube" with running IOS (C2800NM-SPSERVICESK9-M), Version 12.4(15)T5
(UPDATED config 2022/05/02)
voice translation-rule 1
rule 1 /^....$/ /+49445566\0/
rule 2 /^...$/ /+49445566\0/
!
voice translation-rule 2
rule 1 /^\+49445566\(0\)$/ /\1/
rule 2 /^\+49445566\(....\)$/ /\1/
rule 3 /^\+49445566\(...\)$/ /\1/
!
voice translation-rule 5
rule 1 /^49\(.*\)/ /00\1/
rule 2 /^\+49\(.*\)/ /00\1/
rule 3 /^\+\(.*\)/ /000\1/
! voice translation-profile cube_to_ccm-out translate called 2 ! voice translation-profile cube_to_provider-out translate calling 1 ! voice translation-profile provider_incoming-in translate calling 5 ! dial-peer voice 1 voip description ### incoming provider to cube ### translation-profile incoming provider_incoming-in voice-class codec 1 session protocol sipv2 session target sip-server incoming called-number +49445566T dtmf-relay rtp-nte sip-notify no vad ! dial-peer voice 9 voip description ### outgoing cube to provider ### translation-profile outgoing cube_to_provider-out destination-pattern 0T voice-class codec 1 session protocol sipv2 session target dns:siptrunk3XXX dtmf-relay rtp-nte no vad ! dial-peer voice 11 voip description ### outgoing cube to publisher ### translation-profile outgoing cube_to_ccm-out destination-pattern +49445566T voice-class codec 1 session protocol sipv2 session target ipv4:yyy.yyy.yyy.yyy dtmf-relay rtp-nte no vad ! dial-peer voice 10 voip description ### outgoing cube to subscriber ### translation-profile outgoing cube_to_ccm-out destination-pattern +49445566T voice-class codec 1 session protocol sipv2 session target ipv4:xxx.xxx.xxx.xxx dtmf-relay rtp-nte no vad ! dial-peer voice 2 voip description ### incoming cucm to cube ### voice-class codec 1 session protocol sipv2 session target sip-server incoming called-number 0.T dtmf-relay rtp-nte no vad !
04-16-2022 01:12 PM
Glad you managed to get it to work. One last thing, on dial peer 2 you don’t need this line.
session target sip-server
That is used for outbound dial peers and this dial peer is used as an inbound, so that command is not relevant.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide