H323 gateway in SRST modus: transfers versus translations

[antoinemeunier]

Hello,

I am facing a problem with a Cisco 3945e voice router version 15.1.2(T2) (but I guess it applies to all voice routers in all versions).

All the devices have a DN with 6 digits; the two first digits are the zone, the four last are theier actual number;

for example: 802345 where 80 is the zone.

In normal mode, the users are used to dial four digits within their own zone for internal calls (in this example, device 806789 would call 2345, which is translated to 802345).

For external calls, users dial a 0 followed by the PSTN number, for example 0015666666 which is a national number.

This customer has a very complex H323 gateway setup with a lot of dial-peers.

In normal modus, when they call to the PSTN, the first 0 is stripped in the route pattern, sending the call to the voice router with called nr: 015666666.

The dial-peer that matches external calls to the PSTN is the following (0 for normal calls, 1 is for emergency numbers):

dial-peer voice 400 pots

trunkgroup 1

description to BGC

destination-pattern [01]T

progress_ind setup enable 3

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

no digit-strip

The problem is during SRST mode; I have implemented some translation rules so that the users can call internally with the four digits, and also to let them call PSTN numbers with the extra 0:

call-manager-fallback

  translation-profile incoming SRST-fromIPPhone

  translation-profile outgoing SRST-toIPPhone

voice translation-profile SRST-fromIPPhone

translate called 701

!

voice translation-profile SRST-toBGC

translate calling 700

translate called 702

!

voice translation-profile SRST-toIPPhone

translate calling 102

voice translation-rule 700

rule 1 /^801\([2345]\)/ /25011\1/ type any national plan any isdn

rule 2 /^802\([12]\)/ /25102\1/ type any national plan any isdn

rule 3 /^802\([456]\)/ /25012\1/ type any national plan any isdn

rule 4 /^802\([789]\)/ /25192\1/ type any national plan any isdn

rule 5 /^803\([0123456]\)/ /25193\1/ type any national plan any isdn

rule 6 /^8039/ /250839/ type any national plan any isdn

rule 7 /^804\([01]\)/ /25084\1/ type any national plan any isdn

rule 8 /^805\([01]\)/ /25195\1/ type any national plan any isdn

rule 9 /^805\([2345]\)/ /22135\1/ type any national plan any isdn

rule 10 /^805\([679]\)/ /25015\1/ type any national plan any isdn

rule 11 /^806/ /25186/ type any national plan any isdn

rule 12 /^807/ /25107/ type any national plan any isdn

rule 13 /^803\([3479]\)/ /22063\1/ type any national plan any isdn

rule 14 /^982\([567]\)/ /23822\1/ type any national plan any isdn

rule 15 /^85\([27]\)/ /2336\1/ type any national plan any isdn

!

voice translation-rule 701

rule 1 /^0/ /#79/ type any unknown

rule 2 /4444/ /#79025107010/

rule 3 /[2-7].../ /80\0/

!

voice translation-rule 702

rule 1 /^#79/ //

voice translation-rule 102

rule 1 /^/ /00/ type national national

rule 2 /^/ /000/ type international international

I work with this prefix #79 so that the full ISDN calling number would only apply to the call when the call goes to the PSTN, not for internal calls. Therefore, I have the same dial-peer, but with the prefix and the translation profile for the calling number.

dial-peer voice 803 pots

trunkgroup 1

description to BGC

translation-profile outgoing SRST-toBGC

preference 1

destination-pattern #79[01]T

progress_ind setup enable 3

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

no digit-strip

--> everything of this setup works fine; but I have problems with the transfers in SRST;

Users are allowed to transfer to external numbers, and to internal numbers (using the short numbering).

call-manager-fallback

transfer-pattern 0T

transfer-pattern 7...

transfer-pattern 6...

transfer-pattern 5...

transfer-pattern 4...

transfer-pattern 3...

transfer-pattern 2...

The problems is, that when they transfer a call, the translation rules of the SRST setup are not taken into account.

Thus, transferring to 2345 for example, will not help, because the called number is not translated to 802345 like for a normal call in SRST; the same problem exists for a transfer to 0015666666; the number is not translated to #79015666666.

The only solution that I find until now, is to have my original dial-peer changed to 0[01]T, but this affects the normal modus, and I want to avoid this..

Is there any other way to have the SRST translation applied for the SRST transfer?

Thanks a lot!

Best regards,

Antoine

[Ayodeji Okanlawon]

You can easily resolve this by creating a dial-peer for the xferred number in SRST and then apply the xlation rule to the dial-peer.

eg dial-peer 10001 voip

destination-patter [234567]...

(apply the xlation rule that prefix 80 here)

that shuld work.

[antoinemeunier]

Hello aokanlawon,

Thanks for the answer, however, this can be risky, because of other dial-peers existing on the gateway... like I said before, it is a very complex setup.

Anyway, I will try the solution. I think I will have to work with the incoming called-number [234567]... statement instead of the dest-patt, because voip dial-peers with dest-patt and no sess target statement are not valid?

What about the second part of the question; i.e. translation for transfers to external calls: 0015666666, for example.

I am afraid that if I make a voip-dial-peer for this (incoming called-nr 00........), all calls from the CUCM in normal modus, calling external international PSTN numbers, will also match this dial-peer.

Best regards,

Antoine

[Chris Deren]

You should not be stripping any digits in CUCM, and only perform the stripping on the GW, this way you can accomplish the same routing without creating overlaps both on CUCM and the SRST GW.

HTH,

Chris

[Ayodeji Okanlawon]

Antoine,

First and foremost as Chris suggested do not do any digit stripping on the CUCM. Always pass all digits to your gateway that way you will avoid issues like this.

Secondly, I am assuming that this pattern is never passed to your gateway and it is only used for SRST purpose. if this is the case then you should be fine. You can use the loopback address of the gateway if you have one as the session target or an existing interface ip

The other question is similar. You need to define the pattern you want transferred. so if you want the 001....you need to define a new dial-peer that  matches that. because that pattern will only be matched in SRST, your normal calls from CUCM during normal operation will be fine as they wont match this pattern.

[antoinemeunier]

Hello all,

I have been doing some tests in lab:

- have tried with the command translate redirect-target in my translation profile, but it did not seem to help

- have tried to change the transfer-system to local-consult

--> this seems to help, transfers in SRST seem to use the translation profile when using this system

Does this command have any impact on the rest of the SRST use?

Thanks to all for the info until now.

Best regards,

Antoine

[antoinemeunier]

using the dual-line command solves the issue under the dn config.

When making a full-cons transfer, the call will be initiated from the IP-phone's second line, and uses then the translation profile of SRST mode