Configuring SRST

Dial Plan Considerations

When you are running in SRST mode, the gateway is responsible for processing all calls. This means you must configure appropriate dial peers, translations, and class of service (COS) to support your requirements. For H.323 and SIP gateways, the impact is minimal, because you already have dial peers to route calls to the PSTN. For MGCP gateways, the impact can be considerable, because the dial plan in the call agent is no longer available. You need to add dial peers for the voice ports that MGCP typically controls.

Planning

You need to consider several factors when implementing your dial plan in CallManager. The considerations vary by gateway type and are detailed in the sections that follow.

H.323 Gateways

One common issue with H.323 gateways and SRST is the access code. Assume that your users dial an access code of 9 to get an outside line. The service provider does not expect to receive this access code, so you must strip it before the digits are sent so that the call is routed correctly. If you strip the access code in CallManager, your dial peers in the H.323 gateway will be built without the access code. If your users dial the access code while in SRST mode, the call either will not match the appropriate dial peer or the access code will not be stripped before the digits are sent to the service provider. To prevent this, always send the access code to the H.323 gateway and build your dial peers to match the digit strings appropriately.

You might also need to duplicate digit translations in the gateway. For example, your company policy might be to send only the main number for your site instead of the individual direct inward dial (DID) numbers. You should also implement Class of Restrictions (COR) to mimic your CallManager Class of Control configuration, as described in Chapter 12, "Configuring Class of Restrictions."

An additional consideration is route patterns that you are blocking in CallManager. In many countries, blocks of numbers are reserved for "premium" calls with high per-minute charges. These numbers are typically used for things like playing sports scores or for adult-themed businesses. Many companies block access to these premium calls by building a specific route pattern in CallManager and selecting the option Block instead of Route. Because the premium call is never sent to the gateway, it is not necessary to block the route pattern using a dial peer. In SRST mode, it might be possible for your users to place these calls unless you specifically configure the gateway to deny them.

MGCP Gateways

MGCP gateways require you to build an appropriate dial plan when running in MGCP Gateway Fallback mode. In addition to all the H.323 considerations, you also have to build dial peers for basic PSTN connectivity and to properly route inbound calls from the PSTN. Example 13-3 shows an MGCP dial plan for basic connectivity to the U.S. PSTN.

Direct Extension Dialing

The dial plan in a centralized call processing design typically allows your remote site users to dial other locations directly using their extension or by using their site code plus their extension. For both H.323 and MGCP gateways, you should consider adding plain old telephone service (POTS) dial peers to allow direct extension dialing while in SRST mode. The destination patterns for these POTS dial peers will match your existing extension ranges or site codes and prefix the appropriate digits to route the call over the PSTN, as shown in Example 13-4.

This configuration minimizes the impact on your remote site users. CallManager 4.2 has added a feature that minimizes the impact of SRST on your centralized phones. When a remote site is in SRST mode, those phones appear as unregistered to CallManager. CallManager has no way to know that those phones are reachable over the PSTN. In previous versions, calls to unregistered phones were forwarded to voice mail if it was configured, or callers received a reorder tone. CallManager 4.2 added a Call Forward on Unregistered field to the Line Configuration. This feature allows other users to dial the extension and be routed over the PSTN if the destination phone is in SRST mode.

Configuring SRST Dial Plan Patterns

When an IP phone registers with the SRST gateway, each extension on the phone is associated with one of the virtual dial peers created when you entered the max-dn command. This allows the IP phones to call each other but might result in problems with inbound calls from the PSTN. Unless the dialed number identification service (DNIS) information sent by the service provider matches the extension, inbound calls are not routed to the correct phone. You can resolve this issue by using voice translation rules to map the DNIS to the extension. You can also use the dialplan-pattern command if the service provider is sending the E.164 address as the DNIS:

dialplan-pattern tag pattern extension-length digits

When you configure the dialplan-pattern, the gateway creates two virtual dial peers per extension: one with a destination pattern of the extension, and one matching the pattern in the dialplan-pattern configuration. Figure 13-4 illustrates the use of the dialplan-pattern command.

Figure 13-4. dialplan-pattern Configuration

The IP phone has registered with the Miami gateway with its extension of 150. The service provider is sending the full E.164 address of 3055550105 as the DNIS. You would configure dialplan-pattern 1 3055550... extension-length 3 to create the two virtual dial peers you need. This configuration has the added benefit of sending the E.164 address as the automatic number identification (ANI) on outbound calls from this IP phone.