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!

It's official I'm CCNP Voice certified

It's been a rough year of study.  Granted I didn't study hard every day since I do this for a living but it's still been some dedication to get to where I am now.  After ten years in the business I'm finally certified at the NP Voice level.  For all of you aspiring engineers, you have it a little bit better as you won't need CCNA Data anymore to obtain a CCNA Collaboration (the new voice track).  that comes at the expense of you need to know more stuff and missing out on the data side is going to hinder you which is why I would still recommend having a CCNA so you at least know what a gateway and switch are. 

With all of that aside, I feel that the exams were mostly difficult but not impossible.  CIPT2 was the hardest one to pass despite me failing CIPT1.  I think it's more of where you are in your career and what you mess with on a daily basis that defines what topics are hard.  For instance, SAF and CCD are hardly ever used, in fact SAF is being phased out as it is no longer developed from the discussions that I have read.  ILS is going to be taking its place however, so don't think you are skipping by on something.

I think the biggest topics you really need to understand are the dial-plans and the media resources between CIPT1, CIPT2, and TVOICE.  If you arn't familiar with these aspects you will surely fail as they are the meat and potatoes of the Call Manager.  CVOICE and the gateways are equally important but with the new tracks out, they are starting to take a backseat as the focus is on GUI driven objects and understand how they work.  My biggest issue with this is, new engineers won't know how to configure a gateway for SIP, H.323, or MGCP.  I know T1s are going the way of the dinosaur but that doesn't mean you can skip on that information, especially if you are in a MGCP environment.

TVOICE this week

Well, I am here at last.  The final exam and I will be taking it this week then I am CCNP Voice certified.  Once that is complete and the new 300 exams come out for CIPTV2, I will be getting that exam knocked out as well to convert the NP Voice over to NP Collaboration.  It's been ten years since I started in the industry and it's strange that I just now decided to get these exams done.  It's been a long road and while not the end, there is still a nice little vacation spot for me knowing I completed a milestone.  I will continue to post relevant data here on voice as that is my career but I will also be veering off into other adventures too.  I may go CCNA Wireless then obtain my CCNP Wireless as that is another hot industry. 

Things have been slow lately.  I have had time to study (which is good), but also come across some relatively different things while working on internal company stuff for our telepresence and voice upgrades.  I think the biggest thing is licensing and how much of a pain in the butt it is to deal with at times.  We are in the process of getting new equipment and licenses and the TMS is one of those things that I will be rebuilding from scratch.  Yes, I could technically export the SQL database, in fact I already have but decided I would rather build it from the ground up since this server is something I need to deploy to customers.

I know TMS and understand it fairly well, but from a design perspective and installing/configuring from scratch, well not so much.  Our biggest issue right now is the TMS is on a physical Windows Server 2003 box.  That box is EOS/EOL and has been for a long time.  The new one will be virtualized and thus we just need to convert the licenses from hardware to software and then bring it up.  I don't think it will be very hard but I may record the entire process for those that would like to see it from beginning to end. 

CIPT2 Cleared

     Well I took my CIPT2 exam yesterday and cleared it, just barely.  That exam was much harder than CIPT1 and covered less material.  I think the thing about CIPT2 is SAF and CCD is big.  Even though I have never used and will likely never use SAF and CCD, especially since it is no longer being developed, it is on the test.  Globalized dial plans are fairly simple and straight forward and understanding TEHO should be second nature to anyone in the VoIP business.

With all that being said here is a list of things you really need to be on the top of your game on.

1. CCD/SAF configuration and theory.
2. Multisite dial-plans and how to normalize/globalize the numbers inbound and outbound.
3. Media Resources played a small role for me on my exam.
4. Dial-plans...did I say dial-plans?  Please make sure you understand every aspect of a dial-plan.
5. CAC both gatekeeper based and local to CUCM as well as the bandwidth for common codecs to include your layer 2 and layer 3 portions.
6. Mobility and how logging in one location can be different than another based on criteria such as location and subnet.  This is a key portion to understand.

     I know most of that is the blueprint on Cisco's site but it really gets detailed.  I kept hitting diagram after diagram on scenarios which took some considerable time.  The problem is, the screen is not big and you can't fit everything on one page which makes you click between the different diagrams and configurations.  This can get a bit irritating since you have to keep bouncing around so the more you know and are comfortable with the material the better.

     That being said, I feel that CIPT2 would be great for a design engineer in a multi-site environment or someone supporting that style deployment.  I have almost never dealt with intercluster trunks as everything is centralized to keep things simple.  Even when I worked at Cisco and we had over 3000 telepresence endpoints alone across the globe, we were centralized.  Sure we might have had a CUCM elsewhere within the cluster but the bandwidth was so highspeed that it was under the 80ms required for database replication.

     CBT Nuggets did a pretty good job at preparing me for the small things I didn't already know.  Some of the stuff was incredibly easy since I do this for a living while the other stuff like CCD/SAF with the appropriate trunking was a bit more difficult.