Call routing to .T destination over 2 different channels

Answered Question
Mar 2nd, 2010

Hi, All!

Now I have the next problem: on my voice gateway AS5350 I have SIP trunk and PRI. This channels point to the same destination .T

Outgoing calls camming from CUCM 7.1.

I need to make the outgoing call routing based on incoming calling number, for example:

calling numeber 11111 must make outgoing calls throught SIP trunk

calling number 22222 must make outgoing calls throught PRI connection.

I can't use translation patterns for prefix called number and after that strip digits on pots dial-peer, because this translation is visible for subscribers.

Thank you for help )

Correct Answer by William Bell about 6 years 11 months ago

Actually, in regards to:

"I can't use translation patterns for prefix called number and after that  strip digits on pots dial-peer, because this translation is visible for  subscribers."

I know what you ran into and you can accomodate this on the dial-peers.  I had a similar requirement a while back and I handled it by prefixing a 3-digit access code (my own convention) on the called party number before handing it off to the gateway.  Then I used a combination of forward-digits and called-party translations to give the PSTN what they wanted and also mask the pattern on the IP phone display.  My scenario isn't exactly the same as yours, but maybe it will give you some ideas.

voice translation-rule 30

rule 1 /^101/ //

rule 2 /^102/ //

!

voice translation-profile normal-called-translate

translate called 30

!

dial-peer voice 91010 pots

destination-pattern 101.T    !the 101 will get stripped

translation-profile outgoing normal-called-translate  !this will "hide" the 101 from your IP phone display

!

dial-peer voice 91020 pots

destination-pattern 102.T

translation-profile outgoing normal-called-translate !this will "hide" the 101 from your IP phone display

!

The only problem is that none of the above triggers on "called party" information and you would have to do something on the CUCM.  I suppose you could do something on the ingress side of the call signal received by the gateway.  With the CUCM one approach would be to use a Standard Local Route Group (SLRG) config.  But this is only viable if the 1111 and 2222 in your example are on two separate phones.  If both lines are on the same phone then SLRG won't help and you would have to use line level CSS and translation/route patterns to have the same destination pattern do different called party transforms.  Not incredibly scalable.

Anyway, some additional food for thought.

HTH.


Regards,
Bill

Correct Answer by Paolo Bevilacqua about 6 years 11 months ago

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00801c0a88.shtml

Otherwise you can do COR based configuratio, still using answer-address as discriminator.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
William Bell Tue, 03/02/2010 - 06:51

Actually, in regards to:

"I can't use translation patterns for prefix called number and after that  strip digits on pots dial-peer, because this translation is visible for  subscribers."

I know what you ran into and you can accomodate this on the dial-peers.  I had a similar requirement a while back and I handled it by prefixing a 3-digit access code (my own convention) on the called party number before handing it off to the gateway.  Then I used a combination of forward-digits and called-party translations to give the PSTN what they wanted and also mask the pattern on the IP phone display.  My scenario isn't exactly the same as yours, but maybe it will give you some ideas.

voice translation-rule 30

rule 1 /^101/ //

rule 2 /^102/ //

!

voice translation-profile normal-called-translate

translate called 30

!

dial-peer voice 91010 pots

destination-pattern 101.T    !the 101 will get stripped

translation-profile outgoing normal-called-translate  !this will "hide" the 101 from your IP phone display

!

dial-peer voice 91020 pots

destination-pattern 102.T

translation-profile outgoing normal-called-translate !this will "hide" the 101 from your IP phone display

!

The only problem is that none of the above triggers on "called party" information and you would have to do something on the CUCM.  I suppose you could do something on the ingress side of the call signal received by the gateway.  With the CUCM one approach would be to use a Standard Local Route Group (SLRG) config.  But this is only viable if the 1111 and 2222 in your example are on two separate phones.  If both lines are on the same phone then SLRG won't help and you would have to use line level CSS and translation/route patterns to have the same destination pattern do different called party transforms.  Not incredibly scalable.

Anyway, some additional food for thought.

HTH.


Regards,
Bill

lidavpast Thu, 03/04/2010 - 01:31

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Thank you all very mach! Your solutions were good and helpful!

I applied the COR list, and all working fine.

But after reading the next post from William, I understood where I need implement translations to remove unwonted digits )

Actions

This Discussion