Dial Peers and SRST

I recently worked on a project involving a centralized four-site Unified Communications Manager (UCM) deployment. With any centralized deployment, it’s important to provide call processing redundancy at the remote sites. No doubt many, if not most, readers know Survivable Remote Site Telephony (SRST) provides this functionality.

During the startup process, the phone downloads a configuration file from the TFTP server which, among many things, tells the phone what IP address it should contact for SRST services when it can no longer reach the UCM servers. Identifying the SRST router by IP address is important; during a WAN outage the branch site might not have access to a DNS server.

Back to router for a moment. When necessary, the phone contacts the router and attempts registration. Depending upon the setup, the router will probably query the phone for the directory number (DN) information needed to get it up and running. This is sometimes referred to auto-provisioning.

Which brings me to point I’ve been working up to. Once registered, the dial peers configured on the routers direct the calls. The dial peers need to match what the users are actually dialing. If users dial ‘8’ or ‘9’ for an outside line, you want the dial peers to be configured to match.

However, you might actually need two sets of dial peers. If the router at the branch site is used for processing calls during normal operating mode, and if the CUCM has been configured to remove the outside line access code before sending calls to the router, then you need a set of dial peers which do not have the outside line access code at the start of them. There is an easier option – just configure one set of dial peers on the router and include the outside line access code. Then configure the CUCM to not discard the access code before passing the call to the router. The need for two sets of dial peers has been eliminated.

Where it starts to get messy is when you use Tail End Hop Off (TEHO) and have different sites with different access codes. Say, for example, you have offices in Toronto and Vancouver. When a Toronto user dials a Vancouver number, the call is routed out the Vancouver gateway. Toronto uses ‘9’ as their outside line access code, but Vancouver has extension numbers in the 9XXX range, so they use ‘8’ instead. Now it’s not so easy any more. It looks like you’re back to having two sets of dial peers. To make matters worse, say an office were opened in Montreal that was going to use ‘7’ as their outside line access code.

I’ve seen one setup which has scaled reasonably well for situations like this. The customer selects some prefix to be used for all PSTN-bound calls, maybe it’s 1#. They configure two sets of dial peers on the branch routers. One set starting with the PSTN access code, and the other with the site code in use at that location. There is some digit manipulation to be done on the CUCM. If you use gatekeepers, you’ll need to coordinate your selection of prefix with the gatekeeper, but other than that, it’s pretty much a done deal.

One final note, users might be used to dialing numbers at other sites using abbreviated dialing. This could be an extension or an “access code followed by site code followed by extension number” type of setup. Either way, you may need to consider creating translation rules to allow the users to continue using abbreviated dialing while in SRST mode. Readers who work in larger sites will quickly recognize this is an administratively rich solution; the more sites you have the more entries you need to make. Moreover, each time a site is added, removed, or modified it could potentially involve updating translation rules on hundreds of devices world-wide. Next week, I’ll be writing about the case for dialing other sites as if they were a PSTN destination, which is a possible solution to this issue.

Author: Bob Long

In this article

Join the Conversation