The Future of VoIP

Last week I traveled down to DuPont to the Intel campus to attend the CIPTUG Tech Forum. It really was a great event run and hosted by the NW chapter of CIPTUG. Seeing as I am no longer the president of the NW chapter I can’t take any credit for the day which is a pity because it was very successful single day event.

One interesting question that was asked during the ask the experts panel was, “what’s the future of the hard phone?” Of course seeing as this was a Cisco conference the answer was hard phones aren’t going away and why would they want one of the largest revenue drivers in the company to go any where. With VoIP hard phone sales driving switch and router upgrades it makes perfect sense to keep that momentum going.

I kind of agree that there will be hard phone requirements but only to an extent. I think the form factor of the phone will change as we move more mobile and dedicated desk space is less common to more cellular services ( that one is kind of obvious, I know). Even though a few companies have tried to bring back virtual workers back into the office I think the trend is more in the other direction. Of course information workers have slightly different work profile than that of other workers so how these other cross section of workers take up different form factors for business purposes may be more influential than just information workers alone. The person cutting your sandwich at Subway or a factory worker still has a use for a business phone of some description even if it is very seldom. So making all our assumptions based on information workers can be a false one.

The Senior Voice Architect where I used to work pushed the idea of mobile VoIP was the direction and that eventually we wouldn’t need carrier voice service. I am not sure how fast we will get there but AT&T’s recent change of heart on iphone VoIP applications over their wireless network certainly pushes the bounds on what the industry able to do. Whether voice quality will be good enough with the use of 3G when uptake increases we will see but it certainly heading in the right direction to see my former co-workers vision come true. Maybe AT&T just doesn’t see this as a threat yet and they have certainly made no guarantees on quality to date which may be the reason why they have allowed it to happen. “Poor quality, put people off early adoption, keep the cellular revenue rolling in, keep searching for new hosted markets to fill the gap when it finally happens in the advent of G4 or other cellular bandwidth break through”. I am just guessing here but they are the thoughts that come to my mind anyway.

So whether you want to believe it or not cellular VoIP is just around the corner in a big way and moving in on us fast. Lets just hope its well thought out before it explodes on enterprises everywhere.

Finally there was also plenty of talk about CUCiMOC while I was at Intel (this is still at the top of my blog hit list notching around 40% of all hits) but I will leave that subject for another post. The interest is there but I think it’s for all the wrong reasons.

Using MTP’s for interop for CUCM to OCS

I have been on the path of interop for Office communications Server and Cisco Unified Communication Manager for some time. Lots of experimenting, successes and some failures. Microsoft even used some of the documentation I have written to pass on to some of their customers. But one thing that never really gets talked about is the best way to use and deploy Media termination points in the Cisco environment for this interop story. With this post I am going to try and shed some light on some of the best ways to make best use of MTP’s for interop.

What are MTP’s, how do I configure them and what’s the best combination to ensure I get the best bang for my buck?

Media Termination Point (MTP)

MTP’s are a required option on the CUCM (h323 or SIP) trunk/gateway that connects to your OCS environment whether you are doing direct connect or through a gateway with H323 as the trunking protocol. They form an important part of the interop environment for different reasons depending on what protocols you are using. In the case of H323 its required for extended services (hold, transfer etc) and SIP its for compliance with RFC 2833. As an example of the first with H323, nearly all functions will work without MTP’s except ad-hoc conferencing from a Cisco IP Phone that has a Communicator user as the first participant. The communicator user is dropped due to the conference going on hold as the first step in the process.

Depending on the version of CUCM you are using it can make a difference as to your choices whether you are using some intermediate gateway to interop between the two environments. If you’re like a lot of companies and are stalled on CUCM 4.X you may have chosen not to do direct trunking between the two environments.

Cisco link to more information on MTP configuration and use:

Software MTP’s CUCM Server

One thing I haven’t mentioned so far is locating MTPS on the CUCM subscribers. This is a great idea for a single site with limited users, low traffic volumes and the easiest option. MTP’s are much less resource intensive than other CUCM services like transcoding and conferencing. This can have its limitations though such as not being able to locate the MTP’s locally and if your subscriber is heavily loaded it may cause some issues with call quality as the RTP stream will pass through the server.

CUCM 4.x Enhanced MTP’s (on a Cisco ISR)

CUCM 4.x can have some limitations with SIP, so H323 is a safe option and with the IP-IP GW it works pretty well (depending on IOS on your gateway version of course). I have settled on the IOS version 12.4.22yb4 currently while running MTPS onboard the router in software(this uses the router CPU). You can run MTP’s in DSP hardware on an ISR but I believe this to be a waste of resources unless your router is under significant load. DSP’s are very costly and can significantly increase the cost of router hardware. My advice is save these resources for transcoding or conferencing for which DSP’s are a requirement in your Cisco environment. The MTP configuration is below for an IOS router. Take note that although you can name your MTP anything you want there is a 15 character limit. In my case I have called it MTPOCSRouter1. The name must be unique for registration in CUCM. Whats also important is that you have the priority of the of your CUCM subscribers that same as the preference of you dial peers. I have seen one way audio occurrence because this wasn’t set correctly.

sccp local FastEthernet0/0
sccp ccm XX.XX.XX.XX identifier 1 version 4.1
sccp ccm XX.XX.XX.XX identifier 2 version 4.1
sccp ccm group 1
description SCCP CCM group
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 101 register MTPOCSRouter1
dspfarm profile 101 mtp
codec g711ulaw
maximum sessions software 200
associate application SCCP

Below is a diagram to show the full configuration. MTP’s located on the ISR router as well as traffic to the OCS environment passing through the ISR working as an IP-IP GW. This is for a single site like a datacenter where call volumes may be high and you need redundancy. You can also apply the same logic to a branch where you may also have a ISR located for local PSTN access for your Cisco deployment. Placing a mediation server and MTP local will stop tromboning calls across the WAN which is what would happen is both the mediation server and MTP’s where located in a central site and a OC user at a remote site calling a Cisco user at the same remote site. So not much point having one without the other.

In the diagram it shows the MTP as separate entities bound to just one trunk. You could have pooled the MTP resources in to one media resource group but what this could lead to is media traffic having to flow through two device before reaching the medaiton server. Not a desired behaviour and has no benefit. Best bet is to only allow the MTP’s on each gateway only be used for that gateway. One to one if you would like to consider that way.

Although not shown in the first diagram the MTP’s are controlled using Skinny similar to the Cisco IP phone. Skinny is a Cisco propritiory protocol.

CUCM 5.x,6.x and 7.x

The use of MTPs looks somewhat different as you do not have RTP flows having to transition through the ISR for any other reason than the MTP’s themselves. The ISR is now removed from the call signaling flow and the MTP’s are pooled together as a single resource rather than for just one connection.

MTP’s are an unfortunate evil in the interop story between these two infrastructures. If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem but since most Cisco deployments have a mix of control protocols (SCCP, H323 and MGCP) they are a requirement.

Message to UC Marketers and Sales

Dear Marketing and Sales for UC vendors everywhere,

I am writing today in a bid to help you avoid misnomers with your customers, although they don’t complain about it to your face they are in fact saying it to each other. Below are some of the ones I have encountered that later made me question the value of a product or person:

-Over use of the word “Unified”. Placing unified in front of every product you sell is not going to help you sell more stuff. The screw that holds the server rack in place is not a “Unified mounting device”.

-Distracting us with a competitors supposed downfalls because your own product is lacking in a product presentation. The fact is that your market research on your competitors product is more than likely incorrect or over exaggerated to the point it is never actually deployed the way you say it is, is just annoying.

-Use of the term “Best of Breed”. Unless you are selling me a horse this term is meaningless. Unless your product fits nicely in my environment and meets my cost expectations based on ROI the likely hood I will deploy because it is best of breed is zero. This term has passed its due date.

-Learning a new dial plan or product is not a reason not to go with the competitor’s product. We are IT pro’s and learning new systems and products is our job. If I didn’t want to learn new stuff I would be a bikini barrister (now that would be a sight).

-Don’t tell me, “Upgrading the OS or application on 50 servers is easy”. I have heard a similar sentence from a consultant who was lucky to be able to walk out of the room alive after he said it. In large enterprise environments where there is a different group controlling every piece of the collective IT environment anything beyond changing settings in an application can be considered time consuming and challenging. Application packaging and bundling for deployment can help a great deal but nowhere near close to easy.

So here ends my advice. Continue on in your endeavors but don’t say you haven’t been warned next time you use one of these on a customer.


Big Day for Technology Announcements, sort of

If you haven’t already heard the news, Cisco is out to buy video giant Tandberg for an estimated 3 billion dollars. Sounds like a good move for Cisco. Obviously, Tandberg offers Cisco some new market areas to enter and completes their video portfolio but part of me thinks this limits choice. So will Avaya buy Polycom to keep up with the Jones’s, who knows.

Second news is the release of the XMPP gateway by the OCS team. This is great step forward as XMPP gains more momentum. Certainly a smart move.

Third is the arrival of my Microsoft MVP award notice via email. The news just doesn’t stop coming.