H.323 Call Preservation

Since getting my NP Voice I figured I would delve deeper into some of the topics.  I feel that it is a good idea to write about this stuff to keep it in my head as well as help others who are studying or just want a deeper understanding on technology.  I know H.323 is old as dirt and is slowly being buried but it is still prevalent in the US since some areas do not have SIP yet.  This makes the T1 still a necessary evil and thus H.323 gateways or MGCP to follow.

MGCP aside, H.323 is where I wanted to talk a bit this go around.  H.323 if you don't already know is dirt old.  It's on revision 2 since last decade and that allows the fast start setup by putting the H.245 inside the H.225 setup.  Granted when this is done, it's purely for call setup since all other aspects still need negotiated but at least the codec and RTP stream can get going faster without waiting for a bunch of replies. 

H.225 is your basic call setup.  It doesn't negotiate media in itself as it is pure layer 2.  H.245 is you media negotiation that happens and is where codecs and all other capabilities are agreed upon.  By putting the H.245 inside the H.225 you get one big message that contains everything needed to setup the call quickly, hence the name fast start.  If the other side doesn't respond within the next three messages then slow-start is assumed and the call can still proceed.  Both sides have to support fast-start in order for it to occur.  In CUCM, this doesn't happen natively, or at least it didn't.  I haven't checked in version 10 and 11 as everything for us is SIP or MGCP. 

I had a pause for a moment and decided to take a look at the newer version of CUCM out there to see if setting up a H.323 gateway still required a check box.



CUCM as of version 11 still requires you to check the inbound and outbound H.323 fast start.  Crazy really, this is a old technology and Cisco must still think that even today there are devices out there that use slow-start.  I would have thought that the box would be pre-checked today.  Now I know of course that there are slow-starts still out there but the majority of everything is fast-start from what I have experienced these days.  Not a big deal but now you know where to setup the CUCM side of things for fast-start.

So back to the call preservation since I kind of got off on a side tangent there.  I felt that it needed explained in order to fully understand what happens.  Basically, when an H.323 gateway gets a call setup, either from CUCM or elsewhere a logical channel is opened on the H.225 side.  If a WAN failure happens and CUCM dumps, the call can still go on if preservation is configured.  The reason you want to configure preservation is if CUCM comes back online during the call.  Since CUCM lost the TCP connection, it clears the socket and see that the phone is still connected.  CUCM at this point just ends the call because it thought the call was either over or something else happened.  If you enter the "call preserve" command, the gateway will ignore the call teardown request and keep the call active until either the media goes inactive or the call is finished.

Here is Cisco's SRND on the entire process:

 "Note that, after the media is preserved, the call is torn down later when either one of the parties hangs up or media inactivity is detected. In cases where there is a machine-generated media stream, such as music streaming from a media server, the media inactivity detection will not work and then the call might hang. Cisco Unified CM addresses such conditions by indicating to the gateway that such calls should not be preserved, but third-party devices or the Cisco Unified Border Element would not do this.

Flapping is defined for this feature as the repeated and temporary loss of IP connectivity, which can be caused by WAN or LAN failures. H.323 calls between a Cisco IOS gateway and Cisco Unified CM may be torn down when flapping occurs. When Unified CM detects that the TCP connection is lost, it clears the call and closes the TCP sockets used for the call by sending a TCP FIN, without sending an H.225.0 Release Complete or H.245 End Session message. This is called quiet clearing. The TCP FIN sent from Unified CM could reach the gateway if the network comes up for a short duration, and the gateway will tear down the call. Even if the TCP FIN does not reach the gateway, the TCP keepalives sent from the gateway could reach Unified CM when the network comes up. Unified CM will send TCP RST messages in response to the keepalives because it has already closed the TCP connection. The gateway will tear down H.323 calls if it receives the RST message.

Configuration of H.323 call preservation enhancements for WAN link failures involves configuring the call preserve command. If you are using Cisco Unified CM, you must enable the Allow Peer to Preserve H.323 Calls parameter from the Service Parameters window.

The call preserve command causes the gateway to ignore socket closure or socket errors on H.225.0 or H.245 connections for active calls, thus allowing the socket to be closed without tearing down calls using those connections."

So as you can see, the gateway does as told by CUCM since CUCM is there for call setup and teardown.  This is actually an ingenious design that I had not fully understood until I read the SRND.  Even with NP Voice, knowing the material isn't enough, you need to dig deeper and understand the inner workings of everything!