Redirecting Called Numbers in SRST – The Alias Command and Hairpin Methods

The Alias Command

Actually, the customer question that spawned my research and eventual testing was whether the alias command that is available under the call-manager-fallback configuration stanza could be used to hairpin a call back to the PSTN with a transformed called party information element.  The answer is simple: no.

The “alias” command is used for a related requirement, but is not intended to hairpin the call.  A quick example may help in explaining why:

assume you have the following alias command: 

alias 1 5551000 to 5551001 preference 1 cfw 5551002 timeout 10

The DID in this example is 5551000
The alternate number in this example is 5551001

What happens in SRST is that when an ephone with an extension of 5551001 registers to the SRST device, a new (dynamic) POTS dial-peer is created for the destination-pattern 5551000.  This new dial-peer will point calls to the virtual port assigned to the ephone.  The key point is that the dynamic dial peer created by the alias command does not get created until the ephone with DN 5551001 registers.  If the ephone never registers, no alias action is taken and calls to 5551000 return fast busy.  If the ephone does register, then that phone rings before being forwarded to the cfw destination.

The alias command comes in handy when you want to take a DID that usually points to a resource on the CUCM (i.e. Hunt Pilot) and you want the call to be extended to phones in SRST mode.  

For Example:

alias 1 5551000 to 5551001 cfw 5551000 timeout 12
alias 2 5551000 to 5551002 cfw 5551000 timeout 12
alias 3 5551000 to 5551003 cfw 5551000 timeout 12

So, in the above example any call to 5551000 will “hunt” through 5551001, 1002, and 1003.

The alias command can also be used in a mask format:

alias 1  5552... to 5551001  

With the above, 5552000 to 5552999 are all redirected to 5551001.

You can also use the command to alias an extension to itself: 

alias 1 5551002 to 5551002 preference 1 cfw 5551003 timeout 12

This seems odd at first, but what it does is allow you to override your default call forwarding configuration (cfb and cfna) in SRST mode.  Think of it this way, in CUCM (normal operation – no SRST) the majority of phones will typically call forward no answer (cfna) or call forward busy (cfb) to voicemail.  However, there is always at least one phone that needs something special like forwarding to another extension (or chain of extensions).  In SRST mode, using an alias command to alias an extension to itself is one way to facilitate these one-off needs.

Hairpin to PSTN – MGCP Fallback

So, the alias command is pretty handy but it cannot be used to hairpin a call to the PSTN.  Of course, if you have the need to hairpin the call back to the PSTN, it is assumed you need to change the called party number.  Otherwise you have a call loop, which would be bad. 

If your SRST gateway is running in MGCP mode during normal operations and then fails over to H.323 mode during WAN failure, the solution to redirecting to the PSTN is really quite simple.  You use a translation profile to change the called party number on ingress, which would then redirect the call back out to the PSTN using one of the standard pots dial peers.

For Example:

voice translation-rule 10
  rule 1 /2025551000/ /917035551234/
  rule 2 /2025551001/ /914105551234/
!
voice translation-profile RedirectMe
  translate called 10
!
dial-peer voice 100 pots
 description My Ingress Dial Peer
 translation-profile incoming RedirectMe
 incoming called-number 202555....
 direct-inward-dial
 port 0/1/0:23
!
dial-peer voice 200 pots
 description An Offnet Dial Peer
 destination-pattern 91[2-9]..[2-9]......
 forward-digits 11
 port 0/1/0:23
!

So, we have a pots dial-peer that is used to handle incoming calls to the system.  When receiving a call, we run it through a translation-profile assigned to dial-peer 100.  If the DID is 2025551001 we change the called party IE to 917035551234.  If the DID is 2025551001 we change the called party IE to 914105551234.  At this point, the dial-peers are evaluated again and we find that both translated numbers match dial-peer 200 and the calls hairpin back out to the PSTN.

Hairpin to PSTN – H323/SRST

The reason the example provided for the MGCP fallback configuration option works is because the configured dial-peers are not used by the gateway for call routing during normal operations (i.e. MGCP is up and healthy).  Now, if your SRST gateway is running H.323 during normal operations then using dial-peers in the manner shown for MGCP presents a problem.

The problem is that calls to the target DNs in translation-rule 10 would always hairpin to the PSTN, even during normal operation.  This is most likely an undesirable situation.  I have pondered several options and have tried various SRST/call-manager-fallback configurations.  None of which worked, so I was left with trying to use the dial-peers in some creative way to accomplish what I wanted.  I thought of two feasible options.  Neither option was exactly what I wanted.  However, one option is viable and worked well in my lab testing. 

The Example:

voice translation-rule 40
  rule 1 /2025551000/ /17035551234/
  rule 2 /2025551001/ /14105551234/
  rule 15 /20255510../ /13015551234/
!
voice translation-profile RedirectMe
 translate called 40
!
dial-peer voice 2001 voip
 description Connection to Primary CM
 preference 1
 destination-pattern 20255510..
 session target ipv4:10.3.4.21
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad
!
dial-peer voice 2002 voip
 description Connection to Secondary CM
 preference 2
 destination-pattern 20255510..
 session target ipv4:10.3.4.20
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad
!
dial-peer voice 91990 pots
 trunkgroup PSTN-DS1-00
 description Default Route for SRST Mode
 translation-profile outgoing RedirectMe
 preference 10
 destination-pattern 20255510..
!

So, this example starts off in a manner that is similar to the MGCP example.  The most notable differences are that translation-rule 40 translates the called party information to the number that does not include the Off Net access code or “steering number prefix”.  Further, we have a “default” route configured.  We’ll get into that shortly.

So, we have the voip dial-peers (2001 and 2002) which facilitate the need to hand calls off to the CUCM cluster for further call processing.  We use the preference command so that we are always sending ingress calls to the CUCM address 10.3.4.21.  If that CUCM is offline, we will direct calls to the CUCM address 10.3.4.20. 

If both CUCM servers are offline (i.e. a WAN outage) we then find a match with dial-peer 91990.  Both voip dial-peers and the 91990 pots dial-peer have the same destination-pattern.  We use the preference command to facilitate a deterministic call path selection.  When the route is in “SRST” mode we use 91990 as a “default route” for the DID range hosted at the site.

In our example, we are hosting the DID range 2025551000 to 2025551099.  Your voip dial-peers, pots dial-peer (91990) and translation-rule 40 should use a DID range that is identical to what is provisioned on the trunk group terminated on the router.

What about this “default route” terminology?  Well, that is a Bill-thing not a Cisco-thing.  What I mean by “default route” is that in SRST mode you will have ephone-dn’s that are registered to the system.  You may also have aliases configured, or other dial-peers.

For example, lets say you have the following ephone-dn’s registered:

2025551099
2025551098
2025551097
2025551096

When a call enters the router to any of the ephone-dn’s or aliases, the call is routed to the appropriate phone line appearance and the phone rings.  When a call enters the router that matches one of the translation rules in rule list 40, the called party is translated to a number which is sent back to the PSTN.  Rule 15, is the “default route” and will only be used when a more specific pattern is not present.

You will want to add this “default route”.  Otherwise, dial-peer 91990 will route the call to the PSTN without modifying the called party.  Your CO switch will then say “hey, this is yours” and send it back to the SRST router, which will then pass it back to the PSTN.  Call loops are bad.  So, the only way to avoid this situation (based on my understanding) is to punt the call to a directory number that is not provisioned on the SRST router’s carrier trunks.

Hopefully someone will find this information helpful.