Centralized CUCM and translation rules for SRST sites

Unanswered Question
Sep 22nd, 2010
User Badges:

Hello everyone,


Recently we installed a Communications Manager cluster in order to offer a call processing for about 600 remote branches.

Each branch will have a router with SRST to allow users to make calls even if the MPLS link that connects to the central site goes down.


The customer is requesting us to configure something that would allow them to call an autoattendant at the central site through the PSTN when SRST is active so they are asked to enter the extension number they want to reach. In order to clarify my idea, I'll try to explain this way:


Normal scenario:

Central site (30000) --- MPLS --- (50000) Remote site


User with extension 30000 at the central site will call user with extension 50000 and call will go through the MPLS as pure IP call.



Emergency scenario with SRST at the remote site and no MPLS to the central site.


User will dial extension 30000 and a translation rule on the router will translate the number to 985008800 so the call will be forwarded to the DID associated with the AutoAttedant. The autoattendant will ask for the extension the user wants to reach, in this case, 50000, and the call between the users will be connected.


I'm having issues to achieve this, so, I'd ask for somebody's help in order to finish this task. What I've tried so far is:


1. On the router, create a translation rule as follows:


voice translation-rule 1

rule /5..../ /985008800/

(the translation rule successfully converts any 5.... extension to number 985008800)



2. Then I create a translation profile:


voice translation-profile AutoAttendant

translate called 1


3. Then I apply that profile to a dial-peer (and here is where I think I'm messing it up!)


I have a dial-peer 800 pots as follows:


dial-peer voice 800 pots

destination-pattern 5....

translation-profile incoming AutoAttendant

port 0/2/0:0


If I do some debug voice ccapi inout, I see the extension being converted to the PSTN number but I'm not able to actually route it to the PSTN. Should I then create a new dial-peer with outgoing translation profile?


dial-peer voice 900 pots

destination-pattern 9........

translation-profile outgoing AutoAttendant

port 0/2/0:0


Does anybody have any ideas??? They will be very appreciated!!!! I've been working on this project on different tasks since 8am and it seems I'm running out of ideas.


Thanks a lot!!


Daniel Gomez Q.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Aaron Harrison Thu, 09/23/2010 - 00:35
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi Daniel


Just to clarify this a little:


Scenario 1 - in MPLS 'up' mode, a HQ user dials (for example) 51234, and that goes to the DN over the WAN directly.


Scenario 2 - MPLS 'down', a HQ user dials *what? - the AA pilot number instead of 51234?*, and the AA sends the call to *what number? how does the call reach the gateway?*


There is a 'Call Forward Unregistered' that you may be able to use on each DN, the idea is you set the full PSTN number with PSTN-access prefix no the CF Unregistered field, and when that phone is not registered the call wil automatically divert to the full PSTN number. May be worth trying that?


With regard to your gateway config, I'll assume for now that:


- Calls are somehow reaching the GW over IP from the CCM, and have a calling number of 5xxxx


1) If a call is coming over IP, you use an 'incoming' translation on a corresponding VoIP dial-peer... or:

2) If you want to apply the translation to a POTS peer, it must be outgoing. Correct version of your second peer would be:


dial-peer voice 900 pots

destination-pattern 5....

translation-profile outgoing AutoAttendant

port 0/2/0:0


So the destination-pattern is used on the outgoing match process to select the dial-peer to use, then translations are applied, and then it goes to the selected port (0/2/0:0).


Useful debugs to see what is going on are:


debug voip dial-peer all

debug voice translation


Hope this helps


Aaron

DanielGoQ_2 Thu, 09/23/2010 - 08:16
User Badges:

Hello Aaron,


Thanks a lot for the reply but unfortunately I'm certain I was sleeping yesterday!!


I shouldn't have said user was calling from HQ, the issue is from the Branch office.


Scenario 1: MPLS is up, branch user 50001 calls HQ user 30001, the call goes directly over the WAN.


Scenario 2: MPLS is down, branch user 50001 still want call HQ user 30001 and actually dials 30001 but the router has to do some translation rules so that 30001 translates to 985008800 and the call goes over the PSTN.


Any advise?

Aaron Harrison Thu, 09/23/2010 - 08:32
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi


In that case you can keep it simple - when the phone is registered to the SRST gateway, extensions 5xxxx will not be reachable... so add a dial-peer like so:


dial-peer voice 900 pots

destination-pattern 5....
prefix 98500

port 0/2/0:0


This will match 5xxxx, and the 5 will be stripped automatically. The prefix then inserts the 98500 section, to make 98500xxxx which should be diallable over the PSTN. No AA needed :-)


Regards


Aaron


Please rate helpful posts..

DanielGoQ_2 Thu, 09/23/2010 - 08:53
User Badges:

Sounds good but...


The only DID I have is the one associated to the AutoAttendant number 85008800.


This is the reason why I need to convert any number, like 5XXXX or 7XXXX or 8XXXX to 985008800, that way, when they reach the auto-attendant, they can enter again any extension number they want.


Thanks!

Aaron Harrison Thu, 09/23/2010 - 09:14
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Ah... ok - third time lucky:


dial-peer voice 900 pots

destination-pattern 5....

forward-digits none
prefix 985008800

port 0/2/0:0


Or you could use your translation rule from before with translation-profile outgoing (instead of forward-digits none and the prefix).


Aaron

DanielGoQ_2 Thu, 09/23/2010 - 13:49
User Badges:

For some reason it doesn't seem to work...


This is what I configured:


voice translation-rule 1
rule 1 /788..../ /90445539558419/
!
!
voice translation-profile AutoAttendant
translate called 1

!

!

dial-peer voice 900 pots
translation-profile outgoing AutoAttendant
destination-pattern 788....
port 0/2/0:0


When I dial 7881234 for example, I see the number matching dial-peer 900 but the call doesn't seem to go to the PSTN to number 90445539558419


The rule seems to be working though:


ROUTER(cfg-translation-profile)#$ce translation-rule 1 7881234
Matched with rule 1
Original number: 7881234        Translated number: 90445539558419
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

I attach a debug just in case someone can take a look at it!


Sep 23 20:43:36: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
   Interface=0x66530C0C, Interface Type=6, Destination=, Mode=0x0,
   Call Params(Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=7881234(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
   Subscriber Type Str=, FinalDestinationFlag=FALSE, Outgoing Dial-peer=900, Call Count On=FALSE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Sep 23 20:43:36: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Sep 23 20:43:36: :cc_get_feature_vsa malloc success
Sep 23 20:43:36: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Sep 23 20:43:36:  cc_get_feature_vsa count is 3
Sep 23 20:43:36: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Sep 23 20:43:36: :FEATURE_VSA attributes are: feature_name:0,feature_time:1753601120,feature_id:826
Sep 23 20:43:36: //823/12853B8D8787/CCAPI/ccIFCallSetupRequestPrivate:
   SPI Call Setup Request Is Success; Interface Type=6, FlowMode=1
Sep 23 20:43:36: //823/12853B8D8787/CCAPI/ccCallSetContext:
   Context=0x68544F78
Sep 23 20:43:36: //823/12853B8D8787/CCAPI/cc_api_call_proceeding:
   Interface=0x66530C0C, Progress Indication=NULL(0)
Sep 23 20:43:36: csim_do_test: cid(823), ev(22), disp(0)
Sep 23 20:43:36: csimTraceSct: cid(823),st(0),oldst(0)
Sep 23 20:43:36: csimIgnore  cid(823), st(0),oldst(0), ev(22)
Sep 23 20:43:56: csim_do_test: timeout cid(823), st(0), oldst(0)
Sep 23 20:43:56: //823/12853B8D8787/CCAPI/ccCallDisconnect:
   Cause Value=0, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Sep 23 20:43:56: //823/12853B8D8787/CCAPI/ccCallDisconnect:
   Cause Value=0, Call Entry(Responsed=FALSE, Cause Value=0)
Sep 23 20:43:56: //823/12853B8D8787/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Sep 23 20:43:56: //823/12853B8D8787/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x66530C0C, Tag=0x0, Call Id=823,
   Call Entry(Disconnect Cause=0, Voice Class Cause Code=0, Retry Count=0)
RRSCOTI-MEX01A-71345(config)#
Sep 23 20:43:56: //823/12853B8D8787/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Sep 23 20:43:56: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Sep 23 20:43:56: :cc_free_feature_vsa freeing 6885D458
Sep 23 20:43:56: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Sep 23 20:43:56:  vsacount in free is 2
Sep 23 20:43:56: csim_do_test: cid(823), ev(13), disp(0)
Sep 23 20:43:56: csimTraceSct: cid(823),st(2),oldst(0)
Sep 23 20:43:57: csim: loop = 1, failed = 1
Sep 23 20:43:57: csim: call attempted = 1, setup failed = 1, tone failed = 0

Sep 23 20:43:57: //-1/xxxxxxxxxxxx/CCAPI/ccAppShutdownMode:
   ccAppShutdownMode: remove it from the queue


NOTE: I used csim start since my phones are currently being controlled by CUCM.


Thanks a lot!

Mario Jose Apuy... Thu, 09/23/2010 - 17:54
User Badges:
  • Cisco Employee,

I think you're almost there on this one, if you look at the debug the call is disconnecting with a cause value "0" which means unallocated or unassigned number, that's just because of how you are sending the call.


Since you are applying the roule outgoing on the dial-peer facing the PSTN there's no need to send the 9, unless your service provider expects it; which in most cases they don't and also, since you are using "044" I'm guessing this is an international call, you are missing the international access code. If you are on the US the translation rule should be something like:


voice translation-rule 1
rule 1 /788..../ /011445539558419/


That should do the trick...

DanielGoQ_2 Thu, 09/23/2010 - 22:45
User Badges:

Mario,


Actually, I'm applying the rule to the dial-peer that would match extension 788.... it is not the dial-peer used to go to the PSTN.


044 is a prefix we need to use here in Mexico to dial to any mobile number. Normally, I would dial, 9 to get the dial tone, 044 to indicate it is a mobile phone and then 10 digits for the actual number.


In this case, I'm just using my cell to test but in reality, it would be a local number instead.


Thanks!

Aaron Harrison Thu, 09/23/2010 - 23:52
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi Daniel


Dropping the 9 sounds right to me  as well; normally if you have a dial peer with a destination pattern like this:


9T

or

9.............


.. if it's a pots dial-peer the router automatically strips the 'matched' numbers for you (i.e. the literal 9). Try removing the 9 if you have the sort of setup as it is only significant to the local router and shouldn't normally be sent out to the PSTN.


Regards


Aaron

Actions

This Discussion