cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4637
Views
9
Helpful
2
Replies

SRST Translation-profiles and Dialplan-pattern commands

kking2008
Level 1
Level 1

I've found a specific issue with these two commands in SRST (Call-manager-fallback) use.  The use of the Translation-profile command within the Call-manager-fallback section allows the manipulation of digits/strings to/from the SRST source as per this documentation.

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml#con10b

And, this document discusses the use of the dialplan-pattern command

http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/command/reference/srsa_a_m.html#wpmkr1203109

I am attempting to use these commands together (for different reasons) and that is where I have found a problem.  I am using the Dialplan-pattern command to create global prefixes in SRST mode so that the E164 called number received via the PRI can be translated to the extension for inbound calling, no problem here.  I have an additional issue to resolve because the directory numbers for the phones are 9 digits and the users are accustomed to dialing 4 digits for internal calling within CUCM.  I am therefore using the SRST translation-profiles INCOMING, to expand the internal 4 digit dialing to the full 9 digit extension.  This works also, as long as the dialplan-pattern command is removed.

Cisco 2921 ISR G2 v15.1(2)T4 - running c2900-universalk9-mz.SPA.151-2.T4.bin

Here is the interaction.  The virtual Dial-peer created by SRST mode in a router looks like the following

VoiceEncapPeer20035

        peer type = voice, system default peer = FALSE, information type = voice,

        description = `',

        tag = 20035, destination-pattern = `899030169$',

        voice reg type = 0, corresponding tag = 0,

        allow watch = FALSE

        answer-address = `', preference=0,

...

        group = 20035, Admin state is up, Operation state is up,

...

        Translation profile (Incoming):SRSTIN71

        Translation profile (Outgoing):

        incoming call blocking:

        translation-profile = `'

        disconnect-cause = `no-service'

        advertise 0x40 capacity_update_timer 25 addrFamily 4 oldAddrFamily 4

        mailbox selection policy: none

        type = pots, prefix = `',

        forward-digits 0

        session-target = `', voice-port = `50/0/35',

        direct-inward-dial = disabled,

        digit_strip = enabled,

The addition of the Dialplan-pattern command adds another virtual dial-peer for the global prefix

VoiceEncapPeer21211

        peer type = voice, system default peer = FALSE, information type = voice,

        description = `',

        tag = 21211, destination-pattern = `1326370169$',

        voice reg type = 0, corresponding tag = 0,

        allow watch = FALSE

        answer-address = `', preference=0,

...

        group = 21211, Admin state is up, Operation state is up,

...

        Translation profile (Incoming):

        Translation profile (Outgoing):

        incoming call blocking:

        translation-profile = `'

        disconnect-cause = `no-service'

        advertise 0x40 capacity_update_timer 25 addrFamily 4 oldAddrFamily 4

        mailbox selection policy: none

        type = pots, prefix = `',

        forward-digits 0

        session-target = `', voice-port = `50/0/35',

        direct-inward-dial = disabled,

        digit_strip = enabled,

Notice how the second dial-peer (tag 21211) created by the dialplan-pattern command does not use the translation-profile like the other dial-peer (tag 20035) correctly does?  I believe this is my problem.  I have done a 'debug voip dialpeer all' and a 'debug voice translation' (with both commands applied) while an SRST phone dials the 4 digit number and I can see that the incoming dial-peer used is 21211, not 20035.  Since tag 21211 is used and no translation profile is applied for this dial-peer the translation does not affect the call.  If I remove the dialplan-pattern command and watch the same scenario then it works successfully because the Incoming dial-peer 20035 is hit where the translation-profile is present.

It appears when both are present the incoming dial-peer 'tie' goes to the latter (without translation) since they both use the same voice-port.

Anyone know how to deal with this interaction?  I looked for a preference attribute to use with the Dialplan-pattern command, but none exists.

thanks in advance

2 Replies 2

Why don't you use voice translation profile for the manipulation of called E164 number for incoming calls? Attach it incoming to either of these, voice port, trunk group, controller T1/E1 or incoming dial peer.

voice translation-rule 1

rule /^132637\(....\)$/ /89903\1/

voice translation-profile IN-E164

translate called 1

Please rate all useful posts.

Sent from Cisco Technical Support iPhone App



Response Signature


I thought about that too.  It means two translations.  One to translate inbound called numbers, and one for outbound calling number translation.

I was hoping that there was a simpler solution/explanation why the Dialplan-pattern command was excluded from the SRST Translation rule, but maybe it was overlooked.

thank you.