This chapter is from the book
This chapter is from the book
This chapter is from the book
Support for Multiple MOH Sources
Cisco Unified SRST v8.x also introduces support for multiple Music On Hold (MOH) sources.
Before Cisco Unified SRST v8.x, only a single MOH file was supported by Cisco Unified SRST, CUCM Express in SRST mode, and CUCM Express in standalone mode. Cisco Unified SRST v8.x allows you to configure up to five additional MOH sources by configuring MOH groups. Only SCCP IP Phones support these newly introduced MOH groups. You can configure each MOH group with an individual MOH file that is located in the flash memory of the router, and you can enable multicast MOH for each MOH group. Each MOH group is configured with the DN ranges that should use the corresponding MOH group when callers are put on hold, as described in Chapter 7, "Implementing Cisco Unified Communications Manager Express (CUCME) in SRST Mode."
The traditional MOH configuration for Cisco Unified SRST and CUCM Express is still supported. It is used by all phones that do not have a MOH group assigned. All these phones are SIP and SCCP phones whose DNs have not been specified in any MOH group. MOH files can be cached in router RAM. This process reduces the amount of read operations in flash, but it requires enough available RAM at the router. You can limit RAM usage for MOH file caching by using smaller MOH files.
Dial Plan Requirements for MGCP Fallback and SRST Scenarios
Figure 5-11 illustrates the requirements of standalone dial plans to work with MGCP fallback and SRST.
)
Figure 5-11 SRST Dial Plan Requirements for Calls from the Remote Site
SRST failover leaves the remote site independent from the complex dial plan implemented in CUCM at the main site. The SRST router needs to have a dial plan implemented to allow all remote-site phones, all main-site phones, and all PSTN destinations to be reached with the same numbers as in standard mode.
During fallback, users should be able to dial main-site directory numbers as usual. Because these calls have to be routed over the PSTN during fallback, main-site extensions have to be translated to E.164 PSTN numbers at the PSTN gateway.
Most enterprises limit the range of destinations that can be reached from specific extensions by applying class of service (CoS) to the extensions. This limitation should still be valid during times in SRST mode by applying IOS class of restriction (COR), as described in the next chapter.
Ensuring Connectivity for Remote Sites
When SRST is active, you must take several measures to ensure connectivity from remote sites to PSTN destinations, between different sites, and inside the site itself.
To guarantee PSTN connectivity, dial peers with destination patterns corresponding to the PSTN access code have to be implemented. In H.323 or SIP gateways, these dial peers must be present for normal operation. When MGCP gateways are used, dial peers are activated by the MGCP-gateway-fallback mechanism. Interdigit timeout adopts open numbering plans that do not have a fixed number of digits.
Voice translation profiles that are applied to dial peers, the voice interface, or the voice port modify the calling party ID to enable callback from call lists.
For intrasite and intersite connectivity, voice translation profiles are configured to expand called numbers to PSTN format during fallback.
The Cisco IOS command dialplan-pattern in CallManager-Fallback configuration mode performs digit manipulation on the incoming called numbers to match the remote-site extensions. It ensures that internal extensions can be dialed even though the lines are configured with the site code and extension. The Line Text Label settings defined in CUCM are not applied to the SRST phones, so the complete DN applied to the line is visible to the user.
Ensuring Connectivity from the Main Site Using Call Forward Unregistered
During fallback, main-site users should still be able to call remote-site users by using their extension numbers, as shown in Figure 5-12.
)
Figure 5-12 Ensure Connectivity from the Main Site Using Call Forward Unregistered
CUCM considers the remotesite phones unregistered and cannot route calls to the affected IP Phone DNs. Therefore, if mainsite users dial internal extensions during the IP WAN outage, the calls fail or go to voice mail.
To allow remote IP Phones to be reached from mainsite IP Phones, Call Forward Unregistered (CFUR) can be configured for the remotesite phones. CFUR should be configured with the PSTN number of the remotesite gateway so that internal calls for remote IP Phones get forwarded to the appropriate PSTN number.
CFUR Considerations
CFUR was first implemented in CCM Release 4.2.
As mentioned earlier, the CFUR feature allows calls placed to a temporarily unregistered IP Phone to be rerouted to a configurable number. The configuration of CFUR has two main elements:
- Destination selection: When the DN is unregistered, calls can be rerouted to voice mail or to the DN that was used to reach the IP Phone through the PSTN.
- Calling Search Space (CSS): CUCM attempts to route the call to the configured destination number using the CFUR CSS of the directory number that was called. The CFUR CSS is configured on the target IP Phone and is used by all devices calling the unregistered IP Phone. This means that all calling devices use the same combination of route pattern, route list, route group, and gateway to place the call. In addition, all CFUR calls to a given unregistered device are routed through the same unique gateway, regardless of the location of the calling IP Phone. It is recommended that you select a centralized gateway as the egress point to the PSTN for CFUR calls and configure the CFUR CSS to route calls to the CFUR destination through this centralized gateway.
If an IP Phone is unregistered while the gateway that is associated with the direct inward dialing (DID) number of that phone is still under the control of CUCM, CFUR functionality can result in telephony routing loops. For example, if an IP Phone is simply disconnected from the network, the initial call to the phone would prompt the system to attempt a CFUR call to the DID of the phone through the PSTN. The resulting incoming PSTN call would in turn trigger another CFUR attempt to reach the directory number of the same phone, triggering yet another CFUR call from the central PSTN gateway through the PSTN. This cycle potentially could repeat itself until system resources are exhausted.
The CUCM service parameter Max Forward UnRegistered Hops to DN in the Clusterwide Parameters (Feature—Forward) section in CUCM Administration controls the maximum number of CFUR calls that are allowed for a directory number at one time. The default value of 0 means that the counter is disabled. If any DNs are configured to reroute CFUR calls through the PSTN, loop prevention is required. Configuring this service parameter to a value of 1 would stop CFUR attempts as soon as a single call was placed through the CFUR mechanism. This setting would also allow only one call to be forwarded to voice mail, if CFUR is so configured. Configuring this service parameter to a value of 2 would allow up to two simultaneous callers to reach the voice mail of a DN whose CFUR setting is configured for voice mail. It would also limit potential loops to two for DNs whose CFUR configuration sends calls through the PSTN.
CFUR Interaction with Globalized Call Routing
CFUR can benefit as follows from globalized call routing when a CUCM cluster serves multiple countries if a globalized number is used as a CFUR destination number:
- CFUR calls are placed to global number.
- Single route pattern (\+!) sufficient for all CFUR calls.
- Same route pattern can be used for Automated Alternate Routing (AAR) and PSTN access.
- Route pattern refers to single route list.
- Route list includes only Standard Local Route Group.
- CFUR CSS can be the same for all phones.
If globalized numbers are used as CFUR destinations, calls to unregistered phones (for example, phones that lost IP connectivity to CUCM and are in SRST mode) are using the only configured off-net route pattern \+! for CFUR. All calling devices will use the same route pattern, route list, and route group to place the call. This route pattern is a general off-net route pattern and is used for PSTN calls, AAR calls, and CFUR calls. The CFUR CSS can be the same for all phones, and the local gateway will be used for the CFUR call because local route groups are configured.
Without using local route groups, the CFUR CSS determines the gateway that is used for the CFUR call. The CFUR CSS of the phone that is unregistered is used—not the one of the phone that tries to reach the unregistered phone. This means that all callers use the same CFUR CSS when calling an unregistered phone (the CFUR CSS configured at the destination phone). Consequently, if callers are located at different sites, they will all use the same gateway for the CFUR call. Usually, the main site gateway is used for that purpose, which means that the CFUR CSS (applied to all phones) provides access to PSTN route patterns that use the main site gateway (via the referenced route list and route group). With local route groups, each caller can use its local gateway for CFUR calls; there is no need to use the IP WAN toward the main site and then break out to the PSTN with the CFUR call at the main site gateway. Depending on the deployment, this can be a huge improvement for reaching sites that lost IP connectivity to CUCM.
CFUR Example Without Globalized Call Routing
Figure 5-13 illustrates the call flow with CFUR without local route groups.
)
Figure 5-13 CFUR Example Without Globalized Call Routing
Three sites are in the figure: HQ, Site 1, and Site 2. The remote sites are backed up by SRST gateways. If IP connectivity between Site 1 and the HQ fails, Site 1 phones will failover to SRST mode. They can still call the HQ and Site 2 via the PSTN. When an HQ phone attempts to call a phone at Site 1 that is unregistered in CUCM, the call is placed to the CFUR destination configured at the Site 1 phone (915215553001 in this example). The CFUR CSS of the Site 1 phone ensures that route pattern 9.@ is used, which refers to how the HQ gateway is accessed. Therefore, the call is redirected to the PSTN number of the called phone and sent to the HQ gateway.
When a user at Site 2 attempts to call a phone at Site 1, the same thing happens. The CFUR destination 915215553001 is called using the CFUR CSS configured at the Site 1 phone and therefore matches the 9.@ route pattern that refers to the HQ gateway and not to a 9.@ route pattern referring to a Site 2 gateway. Therefore, the call uses the IP WAN to get from Site 2 to the HQ and, from there, it breaks out to the PSTN toward Site 1. If more sites existed, they would all use the HQ gateway for CFUR calls to Site 1. This can lead to suboptimal routing. In addition, different route patterns may be needed, depending on the destination of the CFUR call. In an international deployment, the CFUR destination number may be a mix of national and international numbers. Each destination number has to be specified in a way that it can be routed by the CFUR CSS. There is no common format for all CFUR destinations, in that some may be specified in national format and others in international format.
CFUR Example with Globalized Call Routing
Figure 5-14 shows the same scenario, but with globalized call routing.
)
Figure 5-14 CFUR Example With Globalized Call Routing
There is only a single \+! route pattern; the referenced route list has local route groups enabled. All phones use the same CFUR CSS, which provides access to the partition of the global route pattern. The egress gateway is selected by the local route group feature. Localization of the called number occurs at the egress gateway by global transformations. If a called is placed to an unregistered phone of Site 1, the CFUR destination +15215553001 is called using the single off-net route pattern, which is configured to use the local route group (in the referenced route list). Consequently, like any other PSTN call, CFUR calls use the local gateway instead of the HQ gateway, regardless of the caller's location. There is no need for all callers to use the same gateway for CFUR calls. In addition, all CFUR destination numbers are specified in a global format (E.164 with + prefix).
Keeping Calling Privileges Active in SRST Mode
Under normal conditions in multisite deployments with centralized call processing, calling privileges are implemented using partitions and CSSs within CUCM.
However, when IP WAN connectivity is lost between a branch site and the central site, Cisco Unified SRST takes control of the branch IP Phones, and the entire configuration that is related to partitions and CSSs is unavailable until IP WAN connectivity is restored. Therefore, it is desirable to implement CoSs within the branch router when running in SRST mode.
For this application, you must define CoSs in Cisco IOS routers using the COR functionality. You can adapt the COR functionality to replicate the CUCM concepts of partitions and CSSs by following these guidelines:
- Named tags have to be defined for each type of call that you want to distinguish.
- Outgoing COR lists containing a single tag each have to be assigned to the outgoing dial peers that should not be available to all users. These outgoing COR lists are equivalent to partitions in CUCM.
- Incoming COR lists containing one or more tags have to be assigned to the directory numbers that belong to the various CoSs. Incoming COR lists are equivalent to CSSs in CUCM.
SRST Dial Plan Example
Call-routing components on Cisco IOS routers and CUCM are necessary before a dial plan will work in SRST mode, as shown in Figure 5-15.
)
Figure 5-15 Cisco Unified SRST Dial Plan Requirement Example
CFUR must be defined on the CUCM side. Configuring the Cisco IOS router is more complex when you use dial peers, COR, dial plan pattern, and voice translation profiles to define the simplified SRST dial plan. Note how this example lets you dial 9 to get out to all numbers on the PSTN from the remote sites but limits 900 calls with COR to align with the same restrictions set in CUCM.