Use 4 digit instead of 9 with AA in CUE

[ichehouri]

I have centralized call processing cluster and more than 100 remote sites that have 2921 GWs configured as H323 plus they work as SRST for the local users. the remote gateways also have CUE working as VM and AA and they have FXO pots for local users PSTN calls

Iam using variable length dialing plan (ex. an extension will be configured as 601012000, the 6 is the access code, 0101 is the branch number and 2000 is the local extension). the local users will call each other with 4 digit (i have translation pattern to do that in CUCM) and site to site will be calling 9 digits.

If the phones are registered to CUCM, i have no issue in case local users call each other with 4 digits and in case a PSTN user calls AA and enters 4 digits (iam configuring the H323 gateways in CUCM to use translation pattern)

the issue iam facing is in case of SRST. if a PSTN user calls to site main number and forwarded to AA then the gateway is unable to use the translation pattern configured under call-manager fallback. note that in SRST local users can call each other using the translation pattern configured under call-manager fallback

the following is the translation iam using

voice translation-rule 1

rule 1 /^2.../ /60101&/

!

!

voice translation-profile Extension

translate called 1

below is the call-manager fallback configuration

call-manager-fallback

secondary-dialtone 1

max-conferences 8 gain -6

transfer-system full-consult

ip source-address 192.168.105.1 port 2000

max-ephones 100

max-dn 150 dual-line

keepalive 10

voicemail 601012504

translation-profile incoming Extension

call-forward busy 601012504

call-forward noan 601012504 timeout 20

mwi relay

moh moh1.wav

multicast moh 239.1.1.1 port 16384 route 192.168.105.1

cor incoming Internal-CSS default

cor incoming Local-CSS 1 601012002

cor incoming National-CSS 2 601012001

cor incoming Mobile-CSS 3 601012000

note that if i use alias (alias 1 2000 to 601012000) under call-manager fallback the PSTN forwarded to AA can enter 2000 and will be forwarded to 601012000 succesfuly. but in this case i have to enter the alias for every user and there is limitation of only 10 alias which is not enough)

i am wondering why alias is ok while the translation-profile is not.

[dksingh]

Pl. change this for a quick test?

translation-profile outgoing Extension

[ichehouri]

i already tested this also. i had:

translation-profile incoming Extension

translation-profile outgoing Extension

i also tried to have a dial-peer:

dial-peer voice 200 voip

translation-profile incoming Extension

session protocol sipv2

incoming called-number 2000

dtmf-relay h245-alphanumeric

codec g711ulaw

and also tested the following:

dial-peer voice 200 voip

translation-profile incoming Extension

session protocol sipv2

answer-address 2000

dtmf-relay h245-alphanumeric

codec g711ulaw

and tested the following:

dial-peer voice 200 voip

translation-profile outgoing Extension

session protocol sipv2

answer-address 2000

dtmf-relay h245-alphanumeric

codec g711ulaw

non of the above worked.

any suggestions

[dksingh]

hmm so u applied translation-profile outgoing Extension under call-manager-fallback and

got the same results?

Don't think applying that xlation on voip dialpeer with help as most likely for the transfer

CUE is sending a BYE with Also header or Refer than a new call leg (invite)

Can  u get rid of any voice translation CLI configured under call-manager-fallback and try

the 'old' translation-rule?

config t

translation-rule 100
Rule 1 2... 601012

call-manager-fallback

  translate called 100

[ichehouri]

OK i will try that and will let you know the results.

[ashok_boin]

Hi,

One important point to note for translation profiles under SRST (Call-manager-fallback). They apply only from/to IP phones registered with it.

Pls find the details below.

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

So, you need to have translations by other techniques like on dial peers. Did you try to use "destination-pattern" for outbound dial peer as "answer-address" and "incoming called-number" are generally meant for inbound dial peer matching, not for outbound dial peer.

Regards...

-Ashok.

[ichehouri]

Hi Ashok,

thanks for the explanation. i will try to have destination-pattern under dial-peer also and will let you know the result.

regards,

Ibrahim

[dksingh]

Hi Ashok,

What u mentioned is correct in terms of xlation (under call-man-fallbk) being applicable to
calls to/fro IP phones in SRST mode. These xlations are automatically applied to the
virtual DN/dialpeers (tag = 20xxx) that are created  when individual IP phones register with
SRST router. So there is no way to manipulate that part. show call-manager-fall dial-peer will
show.
Call going to an IP phone (from the router) will be considered outbound for selection of 20xxx
dialpeer so as long as the xlation is applied under call-man-fallbk in the outward  direction,
one would think it'd  work. But the challenge is selecting that outbound dialpeer based on 4-digits
DNIS coming in as part of xfer from CUE/AA  when IP phones are registering 9-digits DN

(aka 9 digit dest-pattern)
We can use a loopback dialpeer to perform digit manipulation but there has to be a simpler way.
Maybe a careful use of num-exp or dialplan pattern will work around this.

Thx.
DK

[ichehouri]

I tried both translate called 1 under call-manager fallback and also tried the outgoing dial-peer with destination-pattern 1000 but still no success

it is realy challenging. the only way it is working is through alias under call-manager fallback. is there a way to right an alias that will allow to enter 1... and convert it to 801011...

i tried to do that but it does not support the dot (.)

any other options we can try

regards,

Ibrahim

[dksingh · Accepted solution]

Hi Ibrahim

I am pretty sure you can do following for that:

num-exp 1... 801011...

The challenge with this is that it will be applicable

all times whether SRST is active or not so would

need some adjustment to your h323 voip dialpeer

that is used for sending calls to CUCM in normal

mode and taking out the translation pattern on CUCM.

Unlike MGCP/SCCP GW, I always recommend to

do all xlations on the GW/IOS itself when using

H323/SIP.

DK

[ichehouri]

Hi DK,

thanks. i tested the num-exp and it worked perfactly. but iam wondering if this is a recomended way or there is a better way since it is a global command and it will take effect in normal mode and in SRST so there is no much control on it.

[ashok_boin]

Hi Ibrahim,

I think you were still having translation profiles applied on the incoming dial peers. If yes, you would have tried the destination pattern 80101... instead of 1...

The reason is like this...

The router selects an inbound dial peer by matching the information  elements in the setup message with the dial peer attributes. The router  attempts to match these items in the following order:

1. Called number with the incoming called-number command

2. Calling number with the answer-address command

3. Calling number with the destination-pattern command

4. Incoming voice port with the configured voice por

And here it applies all necessary translations or any other service parameters if you have put any. Then after, it will try to match another Outgoing dial peer with "destination-pattern".

Regards..

-Ashok.