The PSTN Fallback feature monitors congestion in the IP network and redirects calls to the Public Switched Telephone Network (PSTN) or rejects calls on the basis of network congestion. This feature can also use the ICMP ping mechanism to detect loss of network connectivity and then reroute calls. The fallback subsystem has a network traffic cache that maintains the Calculated Planning Impairment Factor (ICPIF) or delay/loss values for various destinations. Performance is improved because each new call to a well-known destination does not have to wait on a probe to be admitted and the value is usually cached from a previous call.
ICPIF calculates an impairment factor for every piece of equipment along the voice path and then adds them up to get the total impairment value. Refer to International Telecommunication Union (ITU) standard G.113 for more information. The ITU assigns a value to the types of impairment, such as noise, delay, and echo.
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see
Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Service Assurance Agent (SAA) is a network congestion analysis mechanism that provides delay, jitter, and packet loss information for the configured IP addresses. SAA is based on a client/server protocol defined on the User Datagram Protocol (UDP). UDP is a connectionless transport layer protocol in the IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. The SAA probe packets go out on randomly selected ports from the top end of the audio UDP port range.
The information that the SAA probes gather is used to calculate the ICPIF or delay/loss values that are stored in a fallback cache, where they remain until the cache ages out or overflows. Until an entry ages out, probes are sent periodically for that particular destination. This time interval is user configurable.
With this feature enhancement, you can also configure codes that indicate the cause of the network rejection; for example, packets that are lost or that take too long to be transmitted. A default cause code of 49 displays the message qos-unavail, which means Quality of Service is unavailable.
Note
The Cisco SAA functionality in Cisco IOS software was formerly known as Response Time Reporter (RTR). In the How to Configure PSTN Fallback section, note that the command-line interface still uses the keyword rtr for configuring RTR probes, which are now actually the SAA probes.
Application of PSTN Fallback
The PSTN Fallback feature and enhancement provide the following benefits:
Automatically re-routes calls when the data network is congested at the time of the call setup.
Enables the service provider to give a reasonable guarantee about the quality of the conversation to its Voice over IP (VoIP) users at the time of call admission.
Provides delay, jitter, and packet loss information for the configured IP addresses.
Caches call values from previous calls. New calls do not have to wait for probe results before they are admitted.
Enables a user-configurable cause code display that indicates the type of call rejection.
Restrictions for PSTN Fallback
The PSTN Fallback feature has the following restrictions:
When detecting network congestion, the PSTN fallback feature does nothing to the existing call. It affects only subsequent calls.
Only a single ICPIF/delay-loss value is allowed per system.
A small additional call setup delay can be expected for the first call to a new IP destination.
Caution
Configuring callfallbackactive in a gateway creates an SAA jitter probe against other (target) gateways to which the calls are sent. In order for the call fallback active to work properly, the target gateways must have the rtrresponder command (in Cisco IOS releases prior to 12.3(14)T) or the ipslamonitorresponder command (in Cisco IOS Release 12.3(14)T or later) in their configurations. If one of these commands is not included in the configuration of each target gateway, calls to the target gateway will fail.
Specifies the treatment of the jitter-probe transmission. Default: 2.
Specifies the differentiated services code point (dscp) packet of the jitter-probe transmission.
Note
The callfallbackjitter-probeprecedence command is mutually exclusive with the callfallbackjitter-probedscp command. Only one of these command can be enabled on the router. Usually, the callfallbackjitter-probeprecedence command is enabled.
When the callfallbackjitter-probedscp command is configured, the precedence value is replaced by the DSCP value. To disable DSCP and restore the default jitter probe precedence value, use the nocallfallbackjitter-probedscpcommand.
Router(config)# call fallback threshold delay 100 loss 150
Example:
or
Example:
Router(config)# call fallback threshold icpif 100
Specifies fallback threshold to use packet delay and loss values. No defaults.
Note
The amount of delay set by the callfallbackthresholddelayloss command should not be more than half the amount of the time-to-wait value set by the callfallbackwait-timeout command; otherwise the threshold delay will not work correctly. Because the default value of the callfallbackwait-timeout command is set to 300 milliseconds, you can configure a delay of up to 150 milliseconds for the callfallbackthresholddelayloss command. If you want to configure a higher threshold, the time-to-wait delay has to be increased from its default (300 milliseconds) using the callfallbackwait-timeout command.
Specifies fallback threshold to use the Calculated Planning Impairment Factor (ICPIF) threshold for network traffic.
Configuring Call Fallback Wait-Timeout
To configure the call fallback wait-timeout parameters, use the following commands:
SUMMARY STEPS
1.enable
2.configureterminal
3.callfallbackwait-timeoutmilliseconds
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
callfallbackwait-timeoutmilliseconds
Example:
Router(config)# call fallback wait-timeout 200
Configures the waiting timeout interval for a response to a probe in milliseconds. Default: 300 milliseconds.
Note
The time-to-wait period set by the callfallbackwait-timeout command should always be greater than or equal to twice the amount of the threshold delay time set by the callfallbackthresholddelayloss command; otherwise the probe will fail.
The delay configured by the callfallbackthresholddelayloss command corresponds to a one-way delay, whereas the time-to-wait period configured by the callfallbackwait-timeout command corresponds to a round-trip delay. The threshold delay time should be set at half the value of the time-to-wait value.
Configuring VoIP Alternate Path Fallback SNMP Trap
The VoIP Alternate Path Fallback SNMP Trap feature adds a Simple Network Management Protocol (SNMP) trap generation capability. This feature is built on top of the fallback subsystem to provide an SNMP notification trap when the fallback subsystem redirects or rejects a call because a network condition has failed to meet the configured threshold. The SNMP trap provides VoIP management status MIB information without flooding management systems with unnecessary messages about call status by triggering only when a call has been redirected to the public switched telephone network (PSTN) or the alternative IP port. A call can be rejected because of a network problem such as loss of WAN connection, delay, packet loss, or jitter. This feature supports only VoIP signaling protocol with H.323 in this release.
This feature has to be configured on the originating gateway and the terminating gateway. To configure the SNMP trap parameters, use the following commands:
SUMMARY STEPS
1.enable
2.configureterminal
3.callfallbackactive
4.snmp-serverenabletrapsvoicefallback
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
callfallbackactive
Example:
Router(config)# call fallback active
Enables the PSTN fallback feature to alternate dial peers in case of network congestion.
Configure the rtrresponder command on the terminating voice gateway. If the rtrresponder is enabled on the terminating gateway, the terminating gateway responds to the probe request when the originating gateway sends an Response Time Report (RTR) probe to the terminating gateway to check the network conditions.
Configuring Call Fallback Map Parameters
The callfallbackmap command option provides a target network summary/consolidation mode. For example, if there are four individual voice gateway routers connected together on a remote LAN via a separate LAN-to-WAN access router, the map option allows a single probe to be sent to the single remote WAN access router (instead of having to maintain separate probes for each of the four voice gateway routers’ IP addresses). Because the remote access and voice gateway routers are connected together on the same remote LAN, the probes to the access router returns similar results to probes to the individual voice gateway routers.
To configure call fallback map parameters, use the following commands.
Specifies the call fallback router to keep a cache table (by IP addresses) of distances for several destination peers sitting behind the router.
map--Fallback map. Range is from 1 to 16. There is no default.
targetip-address--Target IP address.
ip-address1ip-address2...ip-address7--Lists the IP addresses that are kept in the cache table. The maximum number of IP addresses is seven.
Specifies the call fallback router to keep a cache table (by subnet addresses) of distances for several destination peers sitting behind the router.
Configuring ICMP Pings to Monitor IP Destinations
This capability is enabled to monitor the IP destinations in a VoIP network, which may not support RTR. This monitoring is referred to as ICMP pinging. Based on the RTR or ICMP pinging, results change the operational state of the dial-peer. The configurations described in this section also provide support for monitoring the following session targets configured under a VoIP dial-peer:
DNS
IP version 4
SIP-server
enum
To configure call-fallback monitor probes to ping IP destinations, complete one of the following tasks:
To configure dial-peer parameters to use ICMP pings to monitor IP destinations, complete this task. This configuration applies only to VoIP dial peers.
SUMMARY STEPS
1.enable
2.configureterminal
3.dial-peervoicetagvoip
4.callfallback[icmp-ping|rtr]
5.monitorprobe{icmp-ping|rtr} [ipaddress]
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
dial-peervoicetagvoip
Example:
Router(config)# dial-peer voice 10 voip
Enters dial peer configuration mode, specifies the method of voice encapsulation, and defines a particular dial peer:
tag--Digits that define a particular dial peer. Range is from 1 to 2147483647.
Step 4
callfallback[icmp-ping|rtr]
Example:
Router(config-dial-peer)# call fallback icmp-ping
Configures dial-peer parameters for pings to IP destinations:
icmp-ping--Uses ICMP pings to monitor the IP destinations.
rtr--Uses RTR probes to monitor the session target and update the status of the dial peer. RTR probes are the default.
Note
If this callfallbackicmp-ping command is not entered, the callfallbackactive command in global configuration is used for measurements. If this callfallbackicmp-ping command is entered, these values override the global configuration.
One of these two commands must be in effect before the monitorprobeicmp-pingcommand can be used. If neither of callfallback commands is in effect, the monitorprobeicmp-ping command will not work properly.
Step 5
monitorprobe{icmp-ping|rtr} [ipaddress]
Example:
Router(config-dial-peer)# monitor probe icmp-ping
Enables dial-peer status changes based on the result of the probe:
icmp-ping--Uses ICMP ping as the method for the probe.
rtr--Uses RTR as the method for the probe.
ipaddress--IP address of the destination to be probed. If no IP address is specified, the IP address is read from the session target.
Global Configuration
To configure global parameters to use ICMP pings to monitor IP destinations, complete this task.
Configures global parameters for pings to IP destinations:
icmp-ping--Uses ICMP pings to monitor the IP destinations.
rtr--Uses RTR probes to monitor the IP destinations. RTR probes are the default.
Note
The callfallbackactiveicmp-ping command must be entered before the callfallbackicmp-ping command can be used. If you do not enter this command first, the callfallbackicmpping command will not work properly.
The show commands in this section can be used to display statistics and configuration parameters to verify the operation of the PSTN Callback feature:
showrunning-config--Displays the contents of the currently running configuration file to see if the new feature is configured.
showcallhistoryvoice--Displays the call history table for voice calls and verify call fallback, call delay, and call loss parameters.
showcallfallbackcache--Displays the current Calculated Planning Impairment Factor (ICPIF) estimates for all IP addresses in the call fallback cache.
showcallfallbackconfig--Displays the current configuration.
showcallfallbackstats--Displays the call fallback statistics.
Monitoring and Maintaining PSTN Fallback
Use the following commands to monitor and maintain the PSTN Fallback feature:
clearcallfallbackcache--Clears the current ICPIF estimates for all IP addresses in the cache.
clearcallfallbackstats--Clears the call fallback statistics.
debugcallfallbackdetail--Displays details of VoIP call fallback.
debugcallfallbackprobes--Displays details of voice fallback probes.
testcallfallbackprobeip-address--Tests a probe to a particular IP address and displays the ICPIF SAA values.
debugsnmppackets--Displays information about every Simple Network Management Protocol (SNMP) packet sent or received by the router.
What To Do Next
The Configuring ICMP Pings to Monitor IP Destinations describes the mechanism whereby a dial-peer becomes temporarily disabled because of poor SAA/RTR probe results (for example, ICPIF, jitter, or loss), or because of failure of the ICMP ping test. When this occurs, the normal alternate dial-peer selection process (hunting) is triggered to search for an alternate dial-peer that represents an alternate route.
The global configuration voicehunt command controls whether hunting (continue to look or "hunt" for an alternate dial-peer match) occurs, based on the specific cause code that describes why the initial dial-peer path failed. Hunting is usually appropriate if the cause code indicates network congestion, but usually inappropriate if the failure cause code indicates that the called user is actually busy. Even if an alternate path is taken to reach the called user, and if the user is actually busy, the user will be busy regardless of which path is used.
For more information about the voicehunt command, see the
Cisco IOS Voice Command Reference
.