In this article we will look at some severe problems related to using Unified CME (telephony-service) as a method of providing SCCP device support whilst the UCM cluster is unavailable to branch phones.

 

In the example we will use, the following configuration has been used on the SRST gateway:
Read Full Entry »

This is the second in a 10 part series of blogs covering one of the most difficult and important topics on the CCIE Voice blueprint- Survivable Remote Site Telephony.

 

H323 gateways and UCM communicate with each other as part of a peer to peer relationship- both the H323 gateway and UCM have enough intelligence to operate independently of the other. In the case of the gateway, this intelligence resides in the dial-peer. Therefore, when a branch site loses connectivity to UCM and is in SRST, there is no action required for the H323 gateway (and PSTN connectivity) to survive.

 

MGCP is a client/server protocol. The gateway is an unintelligent device and can only operate when registered to UCM. The MGCP gateway does not use dial-peers, all intelligent routing decisions are made by the UCM. Therefore when a branch site is in SRST, some intervention is required for the MGCP gateway to operate otherwise the PSTN connections present on the gateway are not going to be in service.

 

Strictly speaking, survivable remote site telephony is a term that is used to describe phones (both SCCP and SIP) registering to an IOS gateway when connectivity to the UCM cluster is lost. The term that is used to describe an MGCP gateway “becoming independent” is fallback. Do not confuse this term with switchover and switchback. Switchover is a term that is used to describe a MGCP gateway losing it’s registration to the primary UCM and registering to the secondary UCM. Switchback is when connectivity and availability to the primary UCM has been restored and the gateway registers back to the primary UCM.

 

More information about fallback now. It is very simple to configure as shown below:

 

controller E1 0/0/0
pri-group timeslots 1-4,16 service mgcp
!
interface Serial0/0/0:15
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
isdn bind-l3 ccm-manager
!
ccm-manager fallback-mgcp <<<<<<<<<<<<<<<
ccm-manager redundant-host 10.10.210.10
ccm-manager mgcp
!
mgcp
mgcp call-agent 10.10.210.11 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode out-of-band

 

You can verify if fallback is configured as shown below:

SiteC-RTR#sh ccm-manager
MGCP Domain Name: SiteC-RTR
Priority        Status                   Host
============================================================
Primary         Registered               10.10.210.11
First Backup    Backup Ready             10.10.210.10
Second Backup   None
----------------------------------------8<----------------------------------------------
MGCP Fallback mode:             Enabled/OFF
----------------------------------------8<----------------------------------------------

 

In this case fallback is configured but not active (Enabled/Off). If we bring the site into SRST then we should see the fallback mode change to ON. Let’s make the UCM Pub and Sub unavailable:

 

SiteC-RTR(config)#ip route 10.10.210.10 255.255.255.255 null0
SiteC-RTR(config)#ip route 10.10.210.11 255.255.255.255 null0
!
SiteC-RTR#sh ccm
MGCP Domain Name: SiteC-RTR
Priority        Status                   Host
============================================================
Primary         Down                     10.10.210.11
First Backup    Down                     10.10.210.10
Second Backup   None
----------------------------------------8<----------------------------------------------
MGCP Fallback mode:             Enabled/ON
----------------------------------------8<----------------------------------------------

 

So fallback is now enabled and on but what does all this mean? How does the MGCP gateway operate when UCM is not available?

 

The answer is the MGCP gateway reverts to using dial-peers (which would now need to be configured). These dial-peers do not interfere with “normal operations” since they are only ever going to be active when UCM is not available.

 

The ccm-manager fallback-mgcp command actually invokes a script when the connectivity to both the UCM’s is lost. The script looks something like this:

 

interface Serial0/0/0:15 ! or 23 in the case  of T1 PRI
shut
no isdn bind-l3 ccm-manager
no shut

 

Using the above commands the PRI is no longer trying to use the MGCP application and the Layer 3 isdn Q931 messages are no longer “bckhauled” to the UCM. Instead the IOS gateway  will revert to dial-peers for call control.

 

It is very important that you do not save your configuration whilst fallback is active. This is because you will be saving the IOS configuration which has the “isdn bind-l3 ccm-manager” command removed (which is ultimately what fallback is) and consequently the gateway will never register back to the UCM. This is very dangerous!

 

When connectivity to the UCM cluster has been restored, the gateway is taken out of fallback- all this means is the following commands are added to the gateway:

 

interface Serial0/0/0:15 ! or 23 in the case  of T1 PRI
shut
isdn bind-l3 ccm-manager
no shut

 

Let’s now restore connectivity back to the UCM cluster and see what happens:

SiteC-RTR(config)#no ip route 10.10.210.10 255.255.255.255 null0
SiteC-RTR(config)#no ip route 10.10.210.11 255.255.255.255 null0

After a few seconds we see the PRI D channel and B channels go down:

.Mar  2 21:30:06.073: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/0/0:15, TEI 0 changed to down
.Mar  2 21:30:08.065: %LINK-5-CHANGED: Interface Serial0/0/0:15, changed state to administratively down
.Mar  2 21:30:12.489: %LINK-3-UPDOWN: Interface Serial0/0/0:15, changed state to up
.Mar  2 21:30:12.489: %LINK-3-UPDOWN: Interface Serial0/0/0:0, changed state to down
.Mar  2 21:30:12.489: %LINK-3-UPDOWN: Interface Serial0/0/0:1, changed state to down
.Mar  2 21:30:12.489: %LINK-3-UPDOWN: Interface Serial0/0/0:2, changed state to down
.Mar  2 21:30:12.489: %LINK-3-UPDOWN: Interface Serial0/0/0:3, changed state to down

 

Behind the scenes the “isdn bind-l3 ccm-manager” is re-entered back into the D channel CLI. After a couple more seconds you see the D channel come back up.

 

.Mar  2 21:30:14.949: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/0/0:15, TEI 0 changed to up

 

Verify that normal operations have been restored.

SiteC-RTR#sh ccm-manager
MGCP Domain Name: SiteC-RTR
Priority        Status                   Host
============================================================
Primary         Registered               10.10.210.11
First Backup    Backup Ready             10.10.210.10
Second Backup   None
----------------------------------------8<----------------------------------------------
MGCP Fallback mode:             Enabled/OFF
----------------------------------------8<----------------------------------------------

 

That’s it for now- next time we’ll talk about some of the most severe bugs that you might have to deal with in this IOS release. Until then!

 

Vik Malhi, CCIE#13890

Instructor at IPexpert Inc

http://www.ipexpert.com/

Facebook: http://www.facebook.com/VikMalhi

 

This is the first in a 10 part series of blogs covering one of the most difficult and important topics on the CCIE Voice blueprint- Survivable Remote Site Telephony (SRST).

 

Before you begin the configuration you must consider which SRST mechanism you are going to use. As a reminder of the choices, please take a quick look at this previously published article.

 

Call-manager-fallback is the quickest and easiest of the four options- however there is very limited feature support.
Read Full Entry »

Viazones (special zones that CUBE- and only CUBE- register to) have always been one of the most misunderstood topics when discussing gatekeeper/gateways.

In a nutshell- Invia is always checked (for ARQ and for LRQ) before outvia but outvia is used more often.

Let’s look at an example. Imagine that we have UCM and CME each registered in their own independent local zone and also a third remote Backbone zone defined on another gatekeeper. Extension 4XXX is routed to the CME and international calls (numbers beginning with 011) are routed to the backbone zone.
Read Full Entry »

IPexpert and Unified FX are pleased to announce the availability of PhoneView version 2, PhoneView has already set the standard for endpoint management and now raises the bar with the latest release.

Experience the most powerful remote phone technology possible with multiple phones visible and controllable in a single application/window, all updating in real-time and responding instantly to your commands. Not only is this the best application for CCIE Voice study, it’s used by thousands of Cisco Voice Engineers globally including several systems with 10,000+ phones.
Read Full Entry »