Information About Survivability for Hosted and Cloud Services
Advantages of Using CUBE Survivability Feature
The survivability feature on CUBE addresses the following issues by providing local fallback or registration synchronization:
When a WAN link or registrar server comes up, it waits until each SIP phone sends the REGISTER message to the server, so that outside phones can reach that phone.
If the phone register timer setting is too large, the outside phone waits that much time to reach that phone, after a link flap.
If the phone register timer setting is too small, it floods the WAN link.
When the WAN link or registrar server is down, you cannot make any local calls.
CUBE does not need to configure credentials, as the phones trigger registration. Although CUBE receives REGISTER messages for each phone every 5 minutes; for example, it throttles and sends REGISTER messages every 1 hour to the registrar server, avoiding high WAN bandwidth usage. This addresses the issues 1, 2, and 3.
In normal operation when the WAN link or registrar server is up, the phone’s primary server URL is the registrar server (E2E) registration.
"OPTIONS ping" is used to monitor the registrar server link status. When the detected link is down, CUBE replies with a 500 message and when the phone receives this message, it sends the REGISTER message to CUBE, which is the secondary server (P2P registration). CUBE replies with a 200 OK message to P2P registration when the link is down. The dial-peer keeps the dynamic registrar session target and the local call does not fail. This addresses issue 4.
If you configure the phones to send REGISTER messages every 1 hour (to help alleviate the WAN link), the CUBE uses the credentials that were configured to respond to registrar server authentication challenge. This addresses issue 3.
When the WAN link or registration server is down (detected by OPTIONS ping), the CUBE keeps the registration database of the SIP phones that were previously registered successfully, and it does not send REGISTER messages out; CUBE replies with a 200 OK message and dial-peer keeps the dynamic registrar session target. The local call does not fail, addressing issue 4.
When the registrar link is up after a link flap, the CUBE sends REGISTER message for each phone that was earlier successfully registered to the registrar server. This is throttled to avoid bulk REGISTER messages flooding WAN link and the registrar. This addresses issues 1 and 2.
Registration Through Alias Mapping
The following illustration shows how a phone (with alias mapping) registers to the service provider through CUBE.
The addresses-of-record (AOR) sent in the REGISTER is an alias which is mapped to an extension and (or) phone number by the service provider. The service provider returns the mapping details in the 200 OK response sent to the REGISTER. CUBE has the ability to cache the alias mapping details in its call routing database. When a call is made from the phone, the Request-URI of the INVITE contains the dialed number (short extension or phone number).
If WAN is up, CUBE always routes the INVITE sent from the phone to the service provider without looking up at the alias mapping cache.
If WAN or the service provider is down, that is, in survivability mode, CUBE routes the INVITE locally by looking up at the alias mapping cache.
Alias Mapping—Supported Methods
When the service provider returns the mapping details in the 200 OK message of the REGISTER in the following predefined format:
The short extension or phone number is embedded in the AOR of the REGISTER. For example, AOR is alice10000189_1111 and the short extension is 1111.
An inbound sip profile can be applied to the REGISTER which extracts the extension part from the AOR and adds an X-CISCO-EXTENSION header.
CUBE when WAN is UP
The following illustration provides an example as to how a typical phone makes a call to another local phone registered in the same server when WAN or the registrar server is up in a typical hosted deployment. The circled numbers in the image indicate the numerical order in which the sequence occurs.
The call flow scenario is as follows: Phone A initiates a call to the Phone B registered to the same server.
Phone A sends an initial INVITE request to Phone B to participate in a call session through CUBE.
CUBE sends this INVITE to the service provider.
The service provider in turn sends the INVITE to CUBE. Since the WAN link is up, the service provider maps details of the user from the register server and provides details of the user, for example, alias of the user, short extension number, and phone number.
CUBE sends INVITE with all the above mentioned information to Phone B.
Phone B sends a 200 OK response to CUBE for the received INVITE.
CUBE sends a 200 OK answer to the service provider.
The service provider responds to CUBE with a 200 OK answer.
A final 200 OK response is sent to Phone A by CUBE and the call is established between Phone A and Phone B.
Example: Normal Mode (WAN is Up in P2P Mode)
CUBE# show sip-ua registration passthrough status CallId DirectoryNum peer mode In-Exp reg-I Out-Exp survival ======= ========= ===== ==== ======== ==== ==== ========= 21 NCPhone1006 1 p2p 135 /144 1 144 normal ================================================================================
Example: Normal Mode (WAN is Up in E2E Mode)
CUBE# show sip-ua registration passthrough status CallId DirectoryNum peer mode In-Exp reg-I Out-Exp survival ======= =========== ==== ===== ===== ===== ======= ======== 14574 NCPhone1006 301 e2e 117 /120 -- 120 normal =================================================================================
CUBE Survivability When WAN Is Down
In survivability mode, CUBE provides end-to end telephony services when access to the centralized servers is interrupted because of a WAN outage or other factors, like the server being down.
The following illustration shows how a call is established between two endpoints when WAN link is down during survivability by directly dialing into an extension.
Earlier, when WAN was down, User A could only contact User B using either the alias or the user-id of User B, and not using their extensions or phone numbers.
Now, in the event the WAN link or registration server is down, when a local call is made, INVITE is sent to CUBE. CUBE maps the details of the user like the extension number and phone-number stored during registration. Local phones can now be reached on their short extensions or phone numbers by similar phones that are subscribed to the server through the same CUBE.
It is possible to register multiple contacts for a single AOR; however, if multiple contacts are registered for a single subscriber, the CUBE uses only the topmost registered contact to deliver the call to that subscriber. For this reason, multiple contacts are not supported.
A few phone models, such as, Cisco IP Phone 7800 Series with Multiplatform Firmware and Cisco IP Phone 8800 Series with Multiplatform Firmware, sends register request to primary registrar only and do not send secondary REGISTER request to the secondary registrar (CUBE) in E2E mode when primary registrar could not be reached. In such scenarios, phone service goes down after it receives 500 response from CUBE for REGISTER request toward primary registrar.
To avoid phones getting into such error condition, CUBE checks for the response from the primary registrar side. When CUBE receives request timeout on WAN side or responses other than 200, 4XX, and 3XX from primary registrar, survivability will be enabled.
To enable survivability on such phones, refer Configuring Survivability for Phones Sending Single Register Request.
Survivability Support for Public Switched Telephone Network Access When WAN Is Down
If WAN link going down or registrar service unavailable, you can access the phones in the Public Switched Telephone Network (PSTN) through FXO or PRI cards that are configured on Cisco Unified Border Element.
Survivability support for Public Switched Telephone Network (PSTN) access is supported only for CUBE running on Cisco 4000 Series Integrated Services Router.
Example: Survivability Mode in P2P (regsync mode) when WAN is Down
CUBE# show sip-ua registration passthrough status CallId DirectoryNum peer mode In-Exp reg-I Out-Exp survival ======= ========= ============ ===== ========= ===== ======= ======== 38 NCPhone1008 1 p2p 3595 /3600 1 3600 regsync ==============================================================================
Example: Survivability Mode in E2E (local fallback mode) when WAN is Down
CUBE# show sip-ua registration passthrough status CallId DirectoryNum peer mode In-Exp reg-I Out-Exp survival ======= ============ ====== ==== ======= ===== ======= ======== 70 NCPhone1006 1 e2e 35 /70 -- 0 locfall ========================================================================= CallId DirectoryNum peer mode In-Exp reg-I Out-Exp survival ======= ============ ====== ==== ======= ===== ======= ======== 513 NCPhone1008 1 e2e 40 /70 -- 0 locfall