Q. What is Cisco® Unified Survivable Remote Site Telephony (SRST) and Cisco Unified Enhanced SRST (E-SRST)?
A. In a centralized Cisco Unified Communications Manager environment, when IP phones lose connectivity to Cisco Unified Communications Manager because the WAN is down or the application is unreachable, IP phones in remote branch offices or teleworker homes lose call-processing capabilities. The SRST feature provides basic IP telephony backup services so that IP phones can fall back to the local router at the remote site when connectivity is lost. SRST takes advantage of existing Cisco IOS® Software features to provide basic telephony services such as off-net calls to 911, calls within a remote site, or calls between sites through the public switched telephone network (PSTN). The application is ideal for enterprises for cost-effective deployment of IP telephony in their remote locations.
E-SRST combines all the benefits of SRST, but also includes the following:
• Enhanced user experience in failover mode by maintaining phone displays and providing full call-control features
• Easy to use GUI interface to provision, monitor, report, and troubleshoot remote sites
• Automatic synchronization with Cisco Unified Communications Manager for additions, deletions, and modifications of users and phones
• Calling-rule restrictions continued in failover mode
Q. Is special hardware required?
A. For Cisco Unified SRST, no additional hardware is required. Cisco Unified E-SRST is enabled through Cisco Unified SRST and the Cisco Unified Messaging Gateway.
Q. Is there anything that Cisco Unified SRST supports that Cisco Unified E-SRST does not?
A. Cisco Unified E-SRST supports all the functions of SRST and more, but not does support Cisco Unified Communications Manager Business Edition or Session Initiation Protocol (SIP) phones today.
Q. What features does E-SRST support that SRST does not?
A. E-SRST supports the following features:
• Automatic provisioning: Integrated with Cisco Unified Communications Manager, Cisco Unified E-SRST offers automatic provisioning of branch-office routers with the aid of the Cisco Unified Messaging Gateway. Cisco Unified E-SRST supports centralized Cisco Unified Communications Manager deployments and requires branch-office sites to be provisioned in Survivable Remote Site Telephony mode (Cisco Unified CME-as-SRST).
• Automatic synchronization with the central site: The Cisco Unified Messaging Gateway synchronizes the configuration from the central site to the branch office on a schedule without manual intervention. The synchronization also can be triggered manually on a temporary basis. Branch-office site adds, moves, and changes are handled centrally on the Cisco Unified Messaging Gateway.
• Consistent device layout: The consistent design of the phones results in better user experiences during service outages. Phone displays and basic functions including extensions, soft-key templates, phone types, etc. are carried over in survivable mode.
• Full call-control features during failover: The Cisco Unified Messaging Gateway synchronizes the system behavior for the following features (in addition to the features listed for Cisco Unified SRST):
– Call-forward no-answer, call-forward all, and call-forward busy
– Time-of-day routing
– Calling route restrictions for both incoming and outgoing directions
– Hunt groups
– Call park and call pickup
Q. What is the latest version of Cisco Unified SRST? What is the latest reliable SRST release?
A. For latest features, use Cisco Unified SRST and E-SRST 8.6 (Cisco IOS Software Release 15.1(4)M). Cisco tests all software extensively to ensure highest levels of reliability. As an extra precaution for customers, Cisco generally recommends a version that also has been well-proven in the field. Version 7.1 (Cisco IOS Software Release 15.0(1)M4 is the current recommended release for Cisco Unified SRST unless you need newer features.
Q. Where can I get the SRST files and SRST and Cisco IOS Software versions and supported features?
A. The SRST function is part of the Cisco IOS Software itself. Multiple Cisco IOS Software packages that support SRST are available. Visit the Cisco IOS Software feature navigator to choose the right Cisco IOS Software image for your router and the functions you need: http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp.
Cisco Unified SRST routers do not need phone software files because all the phones load their software directly from the Cisco Unified Communications Manager. You need extra files on your SRST router only if you want to use the music-on-hold (MOH) file that Cisco provides and the H.450 call-transfer application. These files are available at: http://www.cisco.com/pcgi-bin/tablebuild.pl/ip-key (look for srst-3.3 zip).
Q. Which Cisco IOS Software feature set do I need to run SRST on the Cisco Integrated Services Routers (ISRs)?
A. The Cisco IOS Software image requirement is based on the platform that runs the SRST feature. On the Cisco 1861 Integrated Services Router, and Cisco 2800 Series Integrated Services Router platforms, SRST requires a minimum of a Cisco IOS IP VOICE image. The new SRST platform - the Cisco 880 Series Integrated Services Router - supports only a single feature set with Advanced IP services software. (Please refer to the next question for new SRST platform information.)
Q. Which Cisco IOS Technology Package do I need to run SRST and E-SRST on the Cisco Integrated Services Routers Generation 2 (ISR G2) routers?
A. The Unified Communications (UC) Technology Package is required to enable SRST and E-SRST on the ISR G2 routers. All ISR G2 routers (Cisco 2900 and 3900 Series ISRs) are shipped with a universal IOS image. A UC technology license pack needs to be installed on the router to provision SRST and E-SRST.
Q. If I am upgrading my Cisco Integrated Services Router (ISR) from Generation 1 (G1) to Generation 2 (G2), can I reuse my existing SRST licenses?
A. No. New licenses are needed.
Q. What is new on Cisco Unified SRST 8.5?
A. Cisco Unified SRST 8.5 and later versions support the Forced Authorization Code (FAC) on SRST. SRST 8.5 also introduces improved deployment flexibility with support for SSL VPN client on Cisco Unified IP Phones (Skinny Client Control Protocol [SCCP]). Support for normalized +E.164 dialing is also introduced in Version 8.5.
Q. What is new on Cisco Unified SRST 7.1?
A. Cisco Unified SRST 7.1 and later versions enable the configuration for the differentiated services code point (DSCP) values for media packets and signaling packets on the system level. SRST 7.1 also introduces the voice translation rules and profiles allowing the administrator to manipulate the calling numbers, called numbers, or redirected called numbers for a voice call. SRST 7.1 uses the translation rule to implement the +E.164 format.
Q. What is new on Cisco Unified SRST 7.0?
A. We can break this question into three categories: new features, new phone types, and new platforms. With Release 7.0, SRST can support up to eight active calls, both incoming and outgoing, on a single button; SRST modifies the transfer digit-collection process to make it consistent with Cisco Unified Communications Manager; SRST 7.0 adds Cisco Unified IP Conference Station 7937G support, and two new platforms - the Cisco 880 SRST Integrated Services Router and Cisco 1861 Integrated Services Routers - are introduced into the SRST product line to fit small branch-office and teleworker deployments.
Q. What platforms support Cisco Unified SRST and E-SRST?
A. Cisco Unified SRST and Unified E-SRST are available on the Cisco 880, 2800, 2900, 3800, and 3900 Series and the Cisco 1861 Integrated Services Routers.
Q. What is the difference between SRST and Cisco Unified Communications Manager Express (CME) in SRST fallback mode?
A. Both Cisco Unified SRST and Cisco Unified Communications Manager Express in SRST fallback mode provide survivability at remote sites when the WAN link between the central site and the remote site fails. Table 1 compares the two.
Table 1. Comparison of Cisco Unified SRST and Cisco Unified Communications Manager Express in SRST Fallback Mode
Cisco Unified Communications Manager Express in SRST Fallback Mode
Cisco Unified SRST
• SRST fallback was first supported with Cisco CallManager Express 4.0 with Cisco IOS Software 12.4(9)T.
• IP phones re-home to Cisco Unified Communications Manager Express if the Cisco Unified Communications Manager fails. Cisco Unified Communications Manager Express in SRST mode allows IP phones to access some advanced Cisco Unified Communications Manager Express telephony features not supported in traditional SRST.
• Up to 450 phones are supported.
• SRST fallback does not support Cisco VG248 48-Port Analog Phone Gateway registration during fallback.
• The alias command is not supported.
• Cisco Unity® unified messaging at remote sites (Distributed Exchange or Domino) is supported.
• SRST fallback supports features such as pickup groups, hunt groups, basic automatic call distributor (BACD), call park, soft-key templates, and paging.
• Cisco IP Communicator 2.0 is supported with Cisco Unified Video Advantage 2.0 on the same computer.
• Secure voice is not supported in SRST mode.
• More complex configuration is required.
• Digital signal processor (DSP)-based hardware conferencing is supported.
• E-911 is supported with per-phone emergency-response-location (ERL) assignment for IP phones (Cisco Unified Communications Manager Express 4.1 only).
• SRST fallback has been supported since Cisco Unified SRST 2.0 with Cisco IOS Software 12.2(8)T5.
• IP phones re-home to the SRST router if Cisco Unified Communications Manager fails. SRST allows IP phones to have basic telephony features.
• Up to 1500 phones are supported.
• Cisco VG248 registration is supported during fallback mode.
• The alias command is supported.
• Features such as pickup groups, hunt groups, call park, and BACD are not supported.
• Cisco IP Communicator 2.0 with Cisco Unified Video Advantage 2.0 on the same computer is not supported.
• Secure voice during SRST fallback is supported.
• SRST fallback service requires a simple, one-time configuration.
• Per-phone ERL assignment for E-911 is not supported (this new feature is supported in Cisco Unified SRST 4.1).
Q. Where can I find information about router platforms, the maximum number of phones or virtual ports, and recommended memory requirements for SRST?
Q. Do I need to buy a license in order to use Cisco Unified SRST and Unified E-SRST?
A. Yes, you need to buy a separate feature license to run SRST in a production network. You can either buy the SRST feature license individually and a supported router to run the SRST feature or buy the integrated services router SRST bundles that come with the SRST feature license included.
Note: These bundles are available now, but availability can change over time. Visit http://www.cisco.com for information about the latest available bundles.
Q. What version of Cisco Unified Communications Manager does Cisco Unified SRST and Cisco Unified E-SRST support?
A. All versions of Cisco Unified SRST work with all versions of Cisco Unified Communications Manager. It is not the Cisco Unified Communications Manager version that affects the support, but the phone load or firmware version (associated with the Cisco Unified Communications Manager release).
Cisco Unified E-SRST supports the same versions of Cisco Unified Communications Manager as SRST.
Q. Which IP phones or phone loads are supported and tested with Cisco Unified SRST and Unified E-SRST?
A. This feature supports up to eight active calls, both incoming and outgoing, on a single button. Eight incoming calls to an octo-line directory number ring simultaneously. After an incoming call is answered, the ringing stops and the remaining seven incoming calls hear a call-waiting tone.
After an incoming call on an octo-line directory number is answered, the answering phone is in the connected state. Other phones that share the directory number are in the remote Multiline state. A subsequent incoming call sends the call-waiting tone to the phone connected to the call, and sends the ringing tone to the other phones that are in the remote Multiline state. All phones sharing the directory number can pick up any of the incoming unanswered calls.
When multiple incoming calls ring on an octo-line directory number that is shared among multiple phones, the ringing tone stops on the phone that answers the call, and the call-waiting tone is heard for other unanswered calls. The multiple instances of the ringing calls are displayed on other ephones sharing the directory number. After a connected call on an octo-line directory number is put on hold, any phone that shares this directory number can pick up the held call. If a phone is in the process of transferring a call or creating a conference, other phones that share the octo-line directory number cannot "steal" the call.
Q. Can you explain consultative transfer?
A. Before Cisco Unified SRST 7.0, the consultative transfer feature played a dial tone and collected dialed digits until the digits matched the pattern for consultative transfer, blind transfer, or PSTN transfer blocking. The after-hours blocking criteria were applied after the consultative transfer digit collection and pattern matching.
The new feature modifies the transfer digit-collection process to make it consistent with Cisco Unified Communications Manager. This feature is supported only if the transfer-system full-consult command (default) is specified in call-manager-fallback configuration mode and an idle line or channel is available for seizing, digit collection, and dialing.
The new enhancement, by default, collects the transfer digits from the new call leg. You also can configure the system to collect the transfer digits from the original call leg.
Q. Can you explain the E-911 feature support in Cisco Unified SRST?
A. With Enhanced 911, the location of a caller is identified by the emergency workers at the Public Safety Answering Point (PSAP) using a database called the Automatic Location Identifier (ALI) database. Businesses generally have a few special numbers called Emergency Line Identification Numbers (ELINs) registered with the ALI database. The total number of registered numbers is determined by local laws, depending upon the geographic area of the business.
With the E-911 for SRST feature, the calling number sent in outgoing emergency calls is replaced by an ELIN so that emergency workers can identify the caller's location. The E-911 feature also allows emergency operators to call back to connect to the last caller who called the emergency services.
Q. How much does E-911 for SRST support cost?
A. There is no charge for E-911 for SRST support on the Cisco Unified SRST router, but there could be charges for the PSTN trunks to connect to the E-911 network.
To deploy E-911 for SRST support, you need to buy only the right Cisco IOS Software image and SRST feature licenses for the number of phones you have along with the right modules for the PSTN trunk for E-911 connectivity.
Q. What PSTN trunks do I need for E-911 for SRST support?
A. E-911 for SRST is supported for Centralized Automated Message Accounting (CAMA) and ISDN Primary Rate Interface (PRI) trunks.
Q. With the support for the E-911 feature in SRST, do I still need Cisco Emergency Responder?
A. Yes. E-911 for SRST works only in the fallback mode. During normal operation, when the WAN link is up, you need to use Cisco Emergency Responder, which works with Cisco Unified Communications Manager.
Q. With the E-911 for SRST feature, can I support all the Cisco Emergency Responder features in the fallback mode?
A. Both Cisco Emergency Responder and E-911 for SRST support location tracking of a phone based on the IP address subnet that is assigned to each phone.
The Cisco Emergency Responder using the Cisco Discovery Protocol also provides automatic location tracking for phones based on the switch port that the phone is plugged into. The E-911 for SRST feature does not support per-phone ERL assignment to an individual SCCP or SIP phone.
Q. What types of phones and fallback modes are supported with the E-911 for SRST feature?
A. E-911 is supported for SCCP, SIP, and analog phones. It is supported in the SIP, Media Gateway Control Protocol (MGCP), and H.323 fallback modes.
SRST Fallback Support
Q. What if the WAN link fails when an IP phone in the branch office is calling another IP phone or analog phone in the same branch office? Because the IP phone is under the supervision of the central-site Cisco Unified Communications Manager, what happens to the call?
A. When the WAN link fails, the existing calls between IP phones are maintained until either side hangs up. Any call legs that involve H.323 (that is, calls using analog phones not configured for SCCP control and H.323 gateways; for example, the Cisco VG224 Analog Phone Gateway) may get dropped within 3 minutes of the WAN failure unless the no h225 timeout keepalive command is configured. Also, the IP phones that are in an active call at the time of the fallback are not re-homed to the SRST router for the duration of the call, and thus cannot receive new calls from other phones within the same branch office until they do register with the router.
Q. Active calls on SRST-enabled H.323 gateways and analog phones are preserved for about 3 minutes before they are dropped. Why 3 minutes?
A. H.245 TCP keepalives associated with the H.323 call leg are sent once every minute. The calls are dropped after the H.245 TCP keepalive timer expires. When TCP keepalives are sent out without receiving four acknowledgments in sequence (a process that takes up to 5 minutes), the call leg including the Real-Time Transport Protocol (RTP) voice path is dropped. The time actually varies and it also depends on phone type. The following observations were noted in the lab when calls were made from one branch office to another and then the Cisco Unified Communications Manager link was shut down for longer than 10 minutes:
• Active calls from IP phone to IP phone last for the duration of the conversation
• Active calls from IP phone to the PSTN last about 3 minutes before the call is cut off
• This duration addresses a vast majority of typical voice conversations
• Calls are dropped after four H.225 keepalives expire on the gateway (timer is configurable with Cisco CallManager 4.01 and later and all versions of Cisco Unified Communications Manager)
• Cisco Unified Communications Manager resets active calls when the Cisco Unified Communications Manager WAN is restored
• IP phones cannot start placing new calls until they are registered to the Cisco Unified SRST router
Q. Is there any way to keep the calls for H.323 gateways or analog phones for longer than 3 minutes after the WAN link fails?
A. Yes, with Cisco Unified SRST 3.2 and later, if you use the H.323 VoIP Call Preservation for WAN Link Failures feature, the router does not automatically terminate calls. With this feature you can preserve existing H.323 calls at the remote site if an outage occurs by disabling the H.225 keepalive timer with the no h225 timeout keepalive command.
Q. Are other enhancements available with H.323 VoIP Call Preservation for WAN Link Failures?
A. In Cisco Unified SRST 4.0, the support for H.323 call preservation was enhanced to address some of the rare scenarios in which the call preservation did not work. Support was also added for dealing with WAN instability when the WAN link breaks and restores multiple times within a short period of time.
Observations During Cisco Unified Communications Manager WAN Outage
Q. How can I tell if phones are in SRST mode?
A. When phones are in SRST mode, depending on the configuration, you will see either "CM Fallback Service Operating" or a custom message on the phone display.
Q. How long does it take for IP phones to fall back to the Cisco Unified SRST router?
A. You get an "instant" failover if and only if:
• Failover occurs when the phones have a hot standby TCP socket already open to the failover device (SRST or the second Cisco Unified Communications Manager).
• Failover occurs when the TCP connection is explicitly closed by a TCP FIN, RST, or Internet Control Message Protocol (ICMP) host unreachable, so that the phone is not replying until it times out: The phone sends station keepalive messages to its primary and backup Cisco Unified Communications Manager servers. The phone knows the TCP connection of its backup server is up because of the keepalive messages, and attempts registration when needed. The following fields are recommended default values (though configurable):
– StationKeepAliveInterval: 30 seconds
– Station2ndKeepAliveInterval: 180 seconds
Following are the three scenarios of failovers:
• Failover occurs when the Cisco Unified Communications Manager server to which the phone is registered stops working: If the active Cisco Unified Communications Manager is manually stopped, the failover is immediate because the Cisco Unified Communications Manager closes its TCP connections, causing the phone to register with its designated standby (or backup) server immediately.
• Failover occurs when the Cisco Unified Communications Manager process locks up: This scenario is the worst scenario; if it occurs, failover could potentially take 90 seconds because the phone makes three station keepalive attempts spaced 30 seconds apart as default (30 seconds is configurable on the Cisco Unified Communications Manager, however).
• Failover occurs when a TCP failure occurs: TCP failure could be the result of a router or switch going down, or the server itself going into complete failure mode. As soon as the phone sends its first station keepalive message after the TCP connection is down, it sends TCP retries for approximately 20 to 25 seconds. After that, the phone attempts registration with its designated standby (or backup) server.
IP Phone in a Remote Site to IP Phone at Headquarters
Q. If an IP phone in a remote site is in a session with an extension at headquarters and the WAN link fails, what will happen?
A. If the call media is going over the WAN link that failed, then the call is terminated. If the call media is going over the PSTN, the call can be maintained until either party hangs up the phone, using the No Timeout for Call Preservation feature support introduced in Cisco Unified SRST 3.2.
IP Phone in One Remote Site to IP Phone in Another Remote Site
Q. When the WAN link is down, will the IP phones at other locations or other remote sites within the same Cisco Unified Communications Manager still be able to make calls to the site with the failed WAN link?
A. When the WAN link is down, IP phones at other remote sites cannot know if the failed site is in SRST mode, and will receive fast-busy signals when trying to call phones at the SRST site. You have to use the PSTN to reach phones at the SRST site. You can configure Cisco Unified Communications Manager to route calls through the PSTN when the WAN link is down, but Cisco Unified Communications Manager cannot differentiate whether the failure at the remote site was caused by loss of WAN connectivity or a failure on the IP phone.
IP Phone at Headquarters to IP Phone in a Remote Site
Q. What will happen when the IP phones at a central site try to call a remote site when the WAN link to that office is down?
A. When the WAN link fails, the Cisco Unified Communications Manager detects that the IP phones at the remote site are unreachable based on loss of the keepalive signals from the IP phones. Users attempting to call these phones receive a busy or fast-busy signal by default.
With Cisco Unified CallManager 4.2 and all versions of Cisco Unified Communications Manager, you can use the Call Forward Unregistered feature to forward calls to the remote site using the PSTN as an alternate route. With this feature, calls to unregistered destinations can be forwarded to an alternate destination. During WAN failure cases, the remote-site phones become unregistered and the Call Forward Unregistered feature converts the remote-site extensions dialed at the headquarters to a full E.164 number and routes these calls over the PSTN.
Analog Phone in the Branch Office to IP Phone Through the PSTN
Q. When a call is placed within the same branch office during a WAN link failure (the call is in progress and the WAN link recovers), will the central-site Cisco Unified Communications Manager try to take control of the existing call?
A. The existing call is maintained by the SRST-enabled router unless the user terminates it; after that the IP phone "re-homes" back to the Cisco Unified Communications Manager.
Q. Several branch offices are in a metropolitan (metro) area connected through gigabit LAN connections and a centralized Cisco Unified Communications Manager model is used; the SRST-enabled routers have no WAN connections, and the only connections of the routers in branch offices are Ethernet and foreign-exchange-office (FXO) interfaces for 911 and off-net dialing. If a gigabit LAN link fails, will the SRST feature work?
A. Yes, it will. The key in having the phones switched to register with an SRST router is a loss of keepalive packets from the Cisco Unified Communications Manager. When the phones miss three keepalive packets, they register with the local router - the SRST router - which is the default router.
Q. Do I need to configure a MAC address for SRST mode?
A. You do not need to configure a MAC address if the IP phones are already configured by Cisco Unified Communications Manager. When the connection to the Cisco Unified Communications Manager is down, or after the IP phones miss three keepalive packet exchanges with the Cisco Unified Communications Manager, IP phones register with the SRST router and also provide the SRST router with all related configuration that is contained in their memory.
Q. Are both the Cisco Unified Communications Manager Express and SRST functions included in the code, even if I am using just SRST? Does it cost the same for license fees for both functions?
A. Although both functions are in the code base, you can activate only one of the functions at any given time. If you turn on SRST, you will not be able to activate Cisco Unified Communications Manager Express.
Q. If I can conduct WAN calls, what happens when the WAN goes down?
A. In the SRST mode, the phones register with the local router, which provides the call processing. Calls from the site then use the PSTN for access. The phone display indicates that you are in a "Cisco Unified Communications Manager Fallback Service Operating" mode, and you may have to dial the full phone number instead of just an extension number.
Video Support for SRST
Q. What video features does Cisco Unified SRST support?
A. The Cisco Unified SRST router supports video calls between local SCCP endpoints as well as video calls between local SCCP endpoints and a remote terminal running H.320.
Before the video support was available with Cisco Unified SRST, the Cisco Unified IP Phones needed to be reconfigured for audio only when the SRST fallback mode activated. Starting with Cisco Unified SRST 4.0, this reconfiguration is no longer needed.
Q. What phones can I use for video calls with Cisco Unified SRST?
A. Cisco Unified SRST supports Cisco Unified Video Advantage and the Cisco Unified IP Phone 7985G for video calls.
With Cisco Unified SRST 4.0, Cisco Unified IP Phone 7985G models could support audio-only calls during the SRST fallback period. Starting with Cisco Unified SRST 4.1, Cisco Unified IP Phone 7985G models support both audio and video calls during this period.
Cisco Unified IP Phone 8900 and 9900 Series phones support native video. The video on these phones will work with Cisco Unified Communications Manager, but it is disabled in SRST mode.
Q. What is Fax Passthrough using SCCP and analog-telephone-adapter support?
A. Cisco Unified SRST 4.0 supports Fax Passthrough using Cisco VG224 Voice Gateways and analog telephone adaptors using the SCCP protocol. With this feature G.711 media is used between the Cisco Unified Communications Manager Express and the Cisco VG224 or analog telephone adaptor and the fax tones are passed in band between the Cisco Unified Communications Manager Express router and the Cisco VG224 or analog telephone adaptor.
Q. Explain the Secure SRST feature support in Cisco IOS Software routers?
A. Cisco routers can function in Secure SRST mode, which activates when the WAN link or Cisco Unified Communications Manager is not available. The Secure SRST feature is a software feature added to Cisco IOS Software advipservicesk9 and adventerprisek9 images to provide secure calls for IP phones in SRST mode with authentication and encryption support for both signaling and media transmission. Signaling encryption is done with transparent LAN services (TLS) for call setup information, media encryption keys, dual-tone-multifrequency (DTMF) tones, and personal identification numbers (PINs), etc. Media encryption uses Secure Real-Time Transport Protocol (SRTP) to protect voice conversations.
Secure phones connect to port x+443 (default 2443), where x is the TCP port set in the IP source-address command under call-manager-fallback configuration mode.
You can tell if the call is secure by checking to see if a secure lock icon shows on the IP phone display. When the WAN link or Cisco Unified Communications Manager is restored, Cisco Unified Communications Manager resumes secure call-handling capabilities.
Q. Which Cisco IOS Software images and Cisco Unified Communications Manager versions support Secure SRST?
A. Secure SRST is supported in Cisco IOS Software Release 12.3(14)T and later and with Cisco CallManager 4.1(2) and 4.2 and all versions of Cisco Unified Communications Manager.
Q. What are the supported Cisco IOS Software router platforms and network modules for Secure SRST?
A. Secure SRST is supported on the Cisco 2600XM, Cisco 2691 Multiservice Platform, Cisco 3725 and 3745 Multiservice Access Routers, Cisco 2801, 2811, 2821, 2851, 3825, and 3845 Integrated Services Routers, and the Cisco VG224 Analog Voice Gateway.
The SRST router needs digital signal processors (DSPs) for calls between the PSTN or analog phones and IP phones and for transcoding between different codecs. For Secure SRST, only the DSPs present on modules with the following part numbers are supported on Cisco ISRs:
For Secure SRST, DSPs present on modules with the following part numbers are supported on Cisco ISR G2 routers:
Q. Which Cisco IP Phones does Secure SRST support?
Q. Is there any performance effect on a Cisco Unified SRST router running the Secure SRST feature?
A. SRTP Media Encryption has minimal effect on the number of calls unless it is deployed with the G.711 codec. However, TLS is CPU- and memory-intensive for supporting SRST phone registration, and the number of concurrent secure calls supported is less than the number for nonsecure calls.
Q. What is the music-on-hold (MOH) live-feed support?
A. The moh-live command provides live-feed MOH streams from an audio device connected to an ear & mouth (E&M) or FXO port to Cisco IP Phones in SRST mode. If you use an FXO port for a live feed, the port must be supplied with an external third-party adapter to provide a battery feed. Music from a live feed is obtained from a fixed source and is continuously fed into the MOH playout buffer instead of being read from a flash memory file. Live-feed MOH can also be multicast to Cisco IP Phones.
Q. What kind of external third-party adapter can I use for MOH live feed off an FXO port?
A. Cisco recommends part number ST-TC1 from RDL because it has been tested in the lab. Refer to the following URL for more information: http://www.rdlnet.com.
Search the web for "ST-TC1 telephone system coupler" for a local supplier.
Q. What is the SIP SRST feature?
A. The SIP SRST feature is meant for SIP IP phones. A SIP SRST router provides a backup SIP proxy or redirector when network connectivity to the SIP core network (where SIP proxy or SIP redirect servers reside) is down. This feature provides SIP call processing with the master SIP proxy located at the central site, and local backup on the SRST router during WAN outage provides backup for telephony services, including off-net calls to 911 services, etc. SIP SRST is a SIP redirector in Cisco IOS Software. The SIP IP phone attempts to send an INVITE to the address configured as proxy backup after seven failed INVITES or retries (configurable) to the primary SIP proxy.
Please note that E-SRST does not support SIP phones.
Q. What features does SIP SRST support?
A. SIP SRST supports the following features:
• Local SIP phone-to-SIP phone calls if main proxy is unavailable
• Local SIP phone-to-PSTN calls
• Class of Restrictions (COR) on local SIP phones to outgoing PSTN calls to block 1-900 calls
• A method for servicing calls to a telephony number pattern that is unavailable or unreachable when the main proxy is not reachable
Note: SIP SRST support is available only for Cisco IP Phones and is only available for SRST. E-SRST does not support SIP phones at this time.
Q. What is a SIP redirect server in Cisco IOS Software?
A. It is a SIP registrar that enables SIP registrar functions on the gateway to accept incoming SIP REGISTER messages and then auto create voice-over-IP (VoIP) dial peers; it is also an IP-to-IP redirect server for local SIP-to-SIP phone calls.
Q. What is the SIP Gateway Enhancement feature?
A. When SIP is used for on-net calls to integrate with SIP networks, the SIP Gateway Enhancement feature provides the following:
• Lighting of the MWI upon receiving NOTIFY message
• Support for 300 multiple choices to SIP security parameter index (SPI)
Note: SCCP IP phones cannot do in-band digit relay or support RFC 2833, and the Cisco Unity system working in SIP mode cannot do the full SIP SUBSCRIBE/NOTIFY for MWI.
Q. Can I use multiple SRST routers to support more phones?
A. Yes, with Cisco CallManager 3.3(2), in which restriction of running the SRST feature on a default gateway was removed, you can run multiple routers as SRST routers to support more phones than the supported limit on each router. However, please be aware of the call-transfer and call-forwarding limitation if you are not running Cisco Unified SRST 2.0 or later on both routers. And also note that you need to carefully plan and configure dial peers and dial plans for call transfer and call forwarding to work properly.
Q. Can I have my PSTN links on one router or gateway and IP phones on another router, with an Ethernet connection between the two?
A. Yes, with Cisco Unified SRST 2.1 and later.
Q. What does the voicemail command do in SRST?
A. The voicemail command in call-manager-fallback mode is used to configure the telephone number that is speed-dialed when the message button on a Cisco IP Phone is pressed. The same voicemail telephone number is configured for all Cisco IP Phones connected to the router. For example:
The number 914085252222 is called when the Cisco IP Phone Messages button is pressed to retrieve messages.
Q. What is the support for voicemail integration with the Cisco Unity server through analog or DTMF?
A. SRST uses the same in-band analog or DTMF voicemail integration method that Cisco Unified Communications Manager Express uses to allow call-forward busy, call-forward no-answer, or call-forward all to the Cisco Unity server through analog or DTMF through the PSTN. An incoming call can be forwarded to the Cisco Unity voicemail server when call-forward busy, call-forward no-answer, or call-forward all is configured in the SRST router. However, MWI integration is not yet supported in SRST. You can rely on the "Missed calls" shown on the phone display to check for your voicemail. Note that FXO hairpin forwarded calls to voicemail must have disconnect supervision from the central office.
Q. Is there survivable voicemail for centralized Cisco Unity Connection deployments?
A. Yes, but it is not enabled through SRST or E-SRST. The product is called Cisco Unified Survivable Remote Site Voicemail (SRSV). Information about SRSV is available at http://wwwin.cisco.com/artg/products/srsv/.
Q. What is the localization support for SRST routers?
Q. Is there a way to maintain call detail records (CDRs) during SRST mode and synchronize records with Cisco Unified Communications Manager records?
A. The SRST router provides CDRs in two formats - syslog and RADIUS. In both formats, you need an external server to collect the CDR records from the SRST router.
Cisco Unified Communications Manager is not designed to process the CDR records generated by the router during fallback. Calls that are placed through the PSTN receive billing information only by the PSTN billing system. You can use CiscoWorks Voice Manager to export the call-history log to a file that can then be processed in CDR format. CDR records can also be logged onto a syslog or a RADIUS server.
Q. Can I run the MGCP Gateway Fallback feature with SRST on the same router?
A. Yes, MGCP and SRST can coexist on the same router. With the MGCP Gateway Fallback and SRST features running on the same router, both IP and analog phones can fall back to the SRST router when the WAN link to the Cisco Unified Communications Manager is down. Without the MGCP Gateway Fallback feature, FXO or PRI ports working under MGCP control from Cisco Unified Communications Manager are not available during fallback.
Q. If MGCP is enabled in a router with SRST active, will SRST and reliability, availability, and serviceability (RAS), admissions request (ARQ), and admission confirmation (ACF) gatekeeper services work?
A. Yes, the H.323 peer functions work for RAS, ARQ, and ACF; IP phones need to fail over to gatekeepers, and gatekeepers become the call-processing agent only for H.323.
Q. Is it possible to redirect a call to an external switchboard number through the PSTN when a call comes into the MGCP voice gateway running SRST but the extension is not registered on the router?
A. SRST does not provide any explicit functions to perform this redirection, but you can do it by using the normal Cisco IOS Software voice dial-peer and translation rule mechanisms. You can build a basic-telephone-service dial peer to match the direct-inward-dialing (DID) number you want to capture and then add a translation rule to prefix the PSTN access code, etc. The SRST alias command lets you redirect calls to unregistered IP phones only in SRST mode. During MGCP operation, the basic-telephone-service dial peers are not used. If you do not know in advance whether or not the DID number will be resolved to a SRST phone and you want the call to go to the SRST phone if it does register, set the basic-telephone-service dial peer to preference 9 so that the SRST phone autogenerated dial peer (preference 0) is selected first if it exists.
Q. Does SRST support call forwarding on busy, all, and ring no answer (RNA)?
A. Yes, SRST supports these features using a global command call-forward. Call forwarding on busy, all, and RNA are not supported on a phone-by-phone basis. You can also use the alias command to allow calls destined for unregistered extensions to go to a designated extension.
Q. What call-transfer support does SRST offer?
A. Call transfer is supported when an incoming call is over the following interfaces and switch types:
• FXO and foreign-exchange-station (FXS) loopstart (analog)
• FXO and FXS groundstart (analog)
• basic-net3 and primary-net5 switch types
• Voice over Frame Relay (VoFR), voice over ATM (VoATM), and VoIP for Cisco gateway to Cisco gateway
• E&M (analog) and DID (analog)
• T1 channel associated signaling (CAS) with FXO or FXS groundstart signaling
• T1 CAS with E&M signaling
• All PRI and Basic Rate Interface (BRI) switch types
PSTN and ISDN BRI and PRI
Q. Are ISDN BRI and PRI supported in Cisco Unified SRST?
A. Yes, ISDN BRI and PRI interfaces are supported with Cisco Unified SRST.
Q. What switch types are supported on PRI and BRI interfaces?
A. All switch types are supported for PRI and BRI interfaces in Cisco Unified SRST 2.0 and later.
Q. Can I use FXO ports in addition to T1 CAS ports for circuit connectivity to the PSTN with SRST?
A. Yes, you can mix and match different types of voice network modules.
Q. How many FXO ports can I assign for PSTN failover?
A. All the FXO ports on the router are available for PSTN failover.
Q. Are the commands default-destination and alias the same?
A. Both commands are global commands in call-manager-fallback mode. The default-destination command can forward incoming calls from FXO ports with an unknown or unroutable called number to an extension. If a default destination number is set, calls arriving on an FXO port are routed to the default destination number that is provided. If a default destination number is not set, the calls arriving on an FXO port receive a (secondary) dial tone.
The alias command is more general and flexible, and removes any dependency on the FXO automatic private-line-automatic-ringdown (PLAR) mechanism that is associated with the existing default-destination command. Also note that the default-destination command does not work with the connection-plar command. For example:
2600-srst(config-cm-fallback)# alias 1 50 to 5001
Calls to numbers in the 5000-5099 range that are not otherwise explicitly resolved to a specific extension are routed to the phone with extension 5001. This feature supports configurations in which only a subset of phones are supported in the call-manager-fallback mode. Phone calls intended for phones that are not given fallback service can then be redirected to the specified extension.
Q. When both default-destination and connection-plar are configured on the SRST router, the call will not go to the default destination. Will default-destination override connection-plar?
A. When both commands are configured, the incoming call does not ring the extension number configured as default-destination. The default-destination command does not override the connection-plar command; you need to use the alias command.
Other Features Supported with SRST
Q. What codecs are supported in SRST?
A. SRST supports G.711 mu-law and G.729 on IP phones. You can specify the codec type in the dial-peer configuration on a Cisco Unified SRST router. G.711 mu-law is the default codec for local IP phone-to-IP phone calls and for IP phone-to-analog phone calls connected to the basic-telephone-service interfaces on the SRST router. G.729 is used by default for on-net calls through VoIP dial peers. SRST supports G.711 mu-law, a-law, G.729, and G.723.1.
Q. How do I configure a Cisco Unified SRST router to forward Dynamic Host Configuration Protocol (DHCP) requests to a DHCP server?
A. You should configure the SRST router as a DHCP relay agent to forward DHCP and BOOTP requests across the network or WAN. You should add the command ip helper-address ip_address_of_dhcp_server under the router interface configuration portion and make sure that the service dhcp command is configured. Please note that the service dhcp command is configured by default and it is not shown in the show running-config command configuration. If it is explicitly turned off by using the no service dhcp command, you need to reenable it with service dhcp configured on the router.
Q. What will happen if the number of IP phones in the office exceeds the limit supported by the router?
A. The router rejects any phones trying to register after the limit is reached and does not service the phones.
Q. Is there a way to designate which phones get to register with the SRST router?
A. There are many ways to designate phones for registration. The easiest way is to configure different device pools on Cisco Unified Communications Manager - one for phones that you want to register to the SRST router after the fallback and a different one for phones that you do not want to register to the SRST router.
Q. When the number of IP phones in a branch office exceeds the maximum limit of supported phones, can I have two SRST routers in the same branch office?
A. Yes, you can group IP phones into different VLANs or subnets and allow each group to register with one of the SRST routers. However, if connections between both SRST routers are VoIP connections, call transfer may be a problem on H.323 endpoints because of the lack of H.450 support prior to Cisco Unified SRST 2.1 versions because Cisco Unified SRST 2.0 or previous versions have added a special code to allow call transfer between H.323 endpoints to work. Cisco Unified SRST 2.1 and later allow call transfer and call forward to work in this scenario provided that all the routers involved understand and support H.450. With dual-line support added to Cisco Unified SRST 3.0, consultative transfer becomes available starting with Cisco IOS Software Release 12.3(14)T.
Q. What does dialplan-pattern do in SRST?
A. The dialplan-pattern command creates a global prefix that you can use to expand the abbreviated extension numbers (automatically obtained from the Cisco IP Phones) to expand into fully qualified E.164 numbers. The dialplan-pattern command is also required to register the Cisco IP Phone lines with a gatekeeper. The extension-length keyword enables the system to convert a full E.164 telephone number back to an extension number for the purposes of caller ID display, received, and missed call lists.
For example, a company uses extension number range 5000-5099 across several sites, with only the extensions 5000-5009 present on the local router. An incoming call from 5044 arrives from the company's internal ISDN network, and this call includes the calling number as 4083335044 in its full E.164 format.
Q. What does the enhanced dial-plan pattern command do?
A. Cisco Unified SRST 2.1 added the new keyword extension-pattern to allow additional manipulation of the IP phone abbreviated extension number prefix digits. With this enhancement, the leading digits of extension-pattern are stripped off and replaced by the corresponding leading digits of dialplan-pattern. This process avoids a DID number such as 408-550-0001, resulting in a leading-0 4-digit extension number 0001.
Q. Does Cisco Unified SRST support Extension Mobility?
A. Cisco Unified SRST routers do not support Extension Mobility. IP phones rely on the support from Cisco Unified Communications Manager for Extension Mobility support. When in SRST mode, IP phones fall back to the SRST router with whatever profile it contains (extension#... etc.).
Q. Is interactive voice response (IVR) Automated Attendant supported on SRST?
A. Yes. IVR Automated Attendant is supported for Cisco Unified SRST 2.0 and later versions. The sample script has added a routine to set up a call to the pilot number of the IP IVR on the Cisco Unified Communications Manager site, and if the call fails the script continues running on the local SRST router.
Q. How does it work?
A. When an incoming call to the IVR Automated-Attendant pilot number arrives on the router, the router tries to set up a call leg to reach the Cisco Unified Communications Manager pilot number or IP IVR number. If Cisco Unified Communications Manager is up and the IP IVR port is available, the call succeeds and the calling party hears the prompts played by the IP IVR. However, if the WAN or Cisco Unified Communications Manager is down or the IP IVR port is busy, the call setup fails, and the calling party hears the prompts played by the SRST router. Note that the calling party must dial the IVR Automated-Attendant number of the SRST router because dialing the Cisco Unified Communications Manager pilot number (IP IVR number) does not invoke the IVR Automated-Attendant feature on the SRST router.
Q. Can I dial a different phone number to make a call by using an IVR Automated-Attendant script on the SRST router?
A. No, in order to invoke the IVR Automated-Attendant feature on the SRST router, you need to call the IVR Automated-Attendant pilot number. Calling other numbers will not invoke the IVR Automated-Attendant feature.
Q. What features were supported by earlier versions of SRST and E-SRST?