SRST Hairpin to PSTN

[William Bell]

I have searched through the forum and I have seen various threads on this topic but none that fit my particular scenario/question.  I have an ISR voice gateway at a remote site (IOS 12.4(24)T2) that is configured to be an SRST router for phones at the remote site.  This voice gateway is also configured to run H.323 (i.e. no MGCP).

When in SRST mode, I want calls to a specific DID to be hairpinned back out to the PSTN to a different called party number.  If the gateway was running MGCP with fallback to H.323, then this would be simple.  The method for a MGCP approach is to have a pots dial-peer with an inbound translation profile that would redirect to the PSTN, like so:

voice translation-rule 10

rule 1 /2025551000/ /914105559999/

!

voice translation-profile redirecttopstn

translate called 10

!

dial-peer voice 100 pots

description inbound dial-peer

incoming called-number 202555....

...snip...

translation-profile incoming redirecttopstn

...snip...

!

dial-peer voice 200 pots

description a normal LD dialpeer

destination-pattern 91[2-9]..[2-9]......

...snip...

!

Now, the problem when the gateway is running H.323 is that I don't need to do the redirection because the WAN is healthy, and I can just route the call to my CUCM cluster using the voip dial-peer.  However, if I were to put in the translation-profile approach as shown above, all calls to the target DID would redirect whether the WAN is healthy or not.

So, I need something that would only be inserted in the call path when SRST is engaged.  Any thoughts?

Regards,

Bill

Now

[William Bell]

So, I did some additional thinking on this and came up with two hair brain schemes, one of which is somewhat workable

but not perfect.  A config will help...

voice translation-rule 40

  rule 1 /2025552999/ /14105551212/

  rule 2 /2025552900/ /17035551212/

  rule 15 reject /2025552.../

!

voice translation-profile srst-redirect

  translate called 40

!

dial-peer voice 3100 voip

  destination-pattern 2025552...

  preference 1

  session target ipv4:10.10.10.10

  ...snip...

!

dial-peer voice 3101 voip

  destination-pattern 2025552...

  preference 2

  session target ipv4:11.11.11.11

  ....snip...

!

dial-peer voice 3102 pots

destination-peetern 2025552...

translation-profile outgoing srst-redirect

preference 10

port

!

So, during SRST mode I would have ephone-dns like the following:

9165552001$

9165552002$

9165552100$

etc...

Basically, what I am attempting to do with the dial-peer/translation config is specify a default route.  I am using the same pattern that is assigned to the voip dial-peers and giving it a lower preference so that (a) during normal (healthy) operations I am using the voip dial-peers and shouldn't ever hit the pots and (b) when the call managers are not available (i.e. wan outage) I use the pots dial-peer as a "default" route for any 10-digit numbers in my DID range that are not assigned to an ephone.

Boy, what a mouth full.

I tested various calls with this config and everything works....mostly.  I wanted to use the "reject" option in the translation-rule to avoid unnecessary spillage (and worse - call loops) to the PSTN.  I didn't think it would work the way I hoped and it doesn't.  The calls still try to route to the PSTN (though, it fails because I am giving 3-digits (chop, chop)).  That isn't exactly clean.  I suppose I could tell the customer to give us a generic unity message that says "sorry dude, we are broken" message, but I like to have that loose end tied up if I can, without involving an external application.

So,  my original question is still the same with a little twist.  I am curious what some of you dial-peer/h323/srst gurus think of the config I posted above (within the context of my need).  If there is a better way I would like to hear it.  I would also like to hear about flaws in my logic on the above config.  I don't want to put some half-baked idea into production.  As I stated, I know of one caveat.  If someone has an idea on how to resolve that caveat, I would like to hear that to.

Maybe I ask for too much, but this has to be somewhat interesting to someone ;-)

Thanks in advance.

Bill

[glenn.martindell]

Bill,

Have you tried applying your tranlstion profile under the call manager fallback config?

Thanks,

Glenn

[William Bell]

Hey Glenn!  How have you been?

To answer your question, this wouldn't work (I don't think) because the ingress translation profiles under call-manager-fallback apply to call legs originated from registered ephones.  I believe the outbound translation profiles are for egress call legs to the registered ephones.  I need something to catch the ingress call leg from the PSTN.

I did try this out when I was first attempting to resolve my own question and it didn't work.

Thanks,
Bill

[Aaron Harrison · Accepted solution]

Hi Bill

I don’t see much wrong with your config.

As you've seen, the translation profile reject will reject the call from the translation, but not from being routed via the dial-peer.

If you just want the two 2025552999/2025552000 numbers to be re-routed to the PSTN, you can set up a dial-peer for each of those numbers, which matches the whole number and then does a prefix of the whole number (to avoid the need for translation-profiles and simplify it a little) like so:

dial-peer voice 3102 pots

destination-peetern 2025552999

prefix 14105551212

translation-profile outgoing srst-redirect

preference 10

port

dial-peer voice 3102 pots

destination-peetern 2025552000

prefix 17035551212

translation-profile outgoing srst-redirect

preference 10

port

The other side of this is as soon as you have a longer match you'll probably find that these dial-peers become first choice even if your CCMs are up, so you would have to duplicate your dial-peer 3100 and 3101 with copies that have full 10-digit matches and a higher preference, e.g.:

dial-peer voice 3103 voip

destination-pattern 2025552999

preference 1

session target ipv4:10.10.10.10

...snip...

!

dial-peer voice 3104 voip

destination-pattern 2025552000

preference 2

session target ipv4:11.11.11.11

....snip...

As you say, MGCP would be easy... with H.323 there's often not as clean a config as you might like...

Aaron

[William Bell]

Aaron,

Thanks for checking the config (+5 for you).  Yeah, I thought about the specific pattern matching on egress but I didn't like the idea of the potential increase in dial-peers to implement the "feature" and also provide the proper VoIP call path selection during normal operations.  So, I will present the config to the customer with the known caveats and some other thoughts.

Thanks again,

Bill

[Marwan ALshawi]

you also could use an unusual way by using EEM

in this way you may send icmp to the PUB and SUB if both are down you can change the dial peer to what ever you want ( automatically) if it comes back then you change back to the original config

you can search for EEM and how it can be used with IOS commands in cisco.com

good luck

[Marwan ALshawi]

By the way your case can be solved simply by using one of the ways bellow

as you mentioned you are usign H323 with CCM

during the fallback you need to send calls to certain numbers within the DID back to the PSTN

all you need to configure is

configure the desired translation rul and profile to be used during the SRST mode

then apply it under the fallback manager config

but keep in mind that the application of the translation profile under the fallback will work the OTHER way to the dial-peer

for example if you need the translation to be applied for incoming calls during the fall back apply output under the fallback config mode

the other simple way is to use the alias command under the fall back mode

just search is in SRST command reference simple one

because if you use translation as you mentioned above may work with some tricks but will be hard to troubleshoot if you got issue

good luck

if helpful Rate

[William Bell]

Alias command does not function in the way I need.  I need the call to hairpin back to the PSTN.  The Alias command is not intended for this purpose.

Translations under call-manager fallback did not work for me.

Regards,

Bill

[Aaron Harrison]

Hi

My understanding is that the translations under c-m-fallback are for calls extended to IP phones registered to that service... so as the call never goes that way, it won't hit those TX patterns.

Regards

Aaron

[William Bell]

Exactly.

[Marwan ALshawi]

you may try  CME-SRST

create ephone-dn with the number you have with CFA to the PSTN number 

To avoid incorrect routing when you prebuild ephone-dns for Cisco Unified Communications Manager phones in Cisco Unified CME, use the preference command in ephone-dn and voip-dial-peer configuration mode to create a higher preference (0 being the highest) for the voip dial peer than the preference for the prebuilt directory number

i think this will solve yur isue

good luck

[Marwan ALshawi]

did you try it with CME-SRST

[William Bell]

No, I did not try this configuration as it is not applicable in this particular use case.  My question is around SRST, not CME-SRST.   But you are correct, if I were using CME I would have other options than the one that I have already identified and tested.

Thanks,
Bill

[joel.davila]

You could always use my example below. Basically you would need translation profile to match the inbound number and translate it to the number you want to hairpin the call too. In the example below the voip-dialpeer's session target address is the ip address of the gateway itself and we basically set the preference to 4 since we already have other voip dialpeers on this device. Since the intent is to use this during srst the preference should take care of conflicting.

voice translation-rule 1

rule 1 /5551234/ /913215551212/

!

!

voice translation-profile Redirect

translate called 1

!

!

dial-peer voice 10 voip

description :

translation-profile incoming Redirect

preference 4

destination-pattern 5551234

modem passthrough nse codec g711ulaw

session target ipv4:192.168.2.1

incoming called-number .

voice-class codec 1 

voice-class h323 1

dtmf-relay h245-alphanumeric

fax rate disable

no vad