Unified communications (UC) professionals have long trumpeted Session Initiation Protocol (SIP) as the linchpin to a future of true interoperability, a flexible standard with unlimited scalability that allows for seamless integration of voice, video and instant messaging. The reality of the SIP interoperability story has been slightly less than utopian, however, as UC vendors continue to offer solutions based on their own unique -- and not necessarily interoperable -- interpretations of the protocol, which can lead to further headaches for end users.
In this video, Senior Site Editor Rivka Little speaks with Marty Parker, principal consultant at UniComm Consulting, about obstacles to the higher level of SIP interoperability promised in the past, including why UC vendors produce their own individual flavors of SIP, the role that SIP gateways play in bolstering connectivity when products won't work together, and what it will take for vendors to provide real interoperability.
Continuing to explore a "world of continued variety," Parker also discusses why enterprises use different voice and video codecs for separate communications purposes, and emphasizes the importance of carefully considering specific use cases prior to making an investment in video technologies.
About the speaker: Marty Parker is the co-founder of UniComm Consulting, an independent consulting firm providing strategy, planning and implementation support for enterprises in all industry segments. Parker is also the co-founder of UCStrategies.com, a leading forum for UC information and dialogue. He is committed to the advancement of UC to produce new benefits and efficiencies in enterprise communications, and to stimulate and justify innovation in the business communications industry.
More on SIP interoperability and integration challenges
- Note to users: Vendors may be SIP-compliant, but that doesn't guarantee true SIP interoperability
- Ask the Expert: Is SIP necessary for a fully functioning UC solution?
- Where SIP interoperability is lacking, open APIs can aid UC integration
Read the full transcript from this video below:
SIP interoperability and video codec challenges: Can the pieces fit?
Rivka Little: Hello. I am Rivka Little, with Search Unified Communications, and I am here with Marty Parker, Principle Consultant at Unicom Consulting. Thank you for joining us.
Marty Parker: Thank you. My pleasure. I am glad to be here.
Rivka Little: SIP is publicized as being the way of standardized way of interoperability, but there are different flavors of SIP, if I am correct. I wonder why this happens, and is there a method making for making these flavors work together?
Marty Parker: First, let us talk about the position of Session Initiation Protocol, or SIP, in the marketplace. It is relatively new, so most people who use Session Initiation Protocol, or SIP, in their company are installing gateways today, so you can buy a SIP to TDM, or SIP to T1 gateway, those are very common. If I am going to put a new, say IPPBX that is based on SIP into my enterprise, and I got ten locations, I might put the new PBX in one location, but then I have to connect up to the other nine until I migrate them over, so during that time I am going to use gateways. One of the reasons people do not worry too much about standardization right now is that there are so many great gateways out there: You go Anykey, All Your Codes, Dialogic, and companies like that -- economical plug and play, a SIP socket on one side, a T1 on the other, and we are done. It is practical. The second thing that happens is that session initiation protocol, similar to XML, the markup language for interchanging data, is an open protocol, and each vendor can customize it; the same was true in T1 Telephony with Cusick. Our Cusick standard allowed Manufacturer Specific Information, MSI, to be in each one, so they did not all work together. What you see today is a growing agreement on a set of standard things that SIP can do. Sometimes around telephony that is, I can pick up a call, hang up a call, transfer a call, hold a call, those things, are pretty well agreed, so that will work. Also at the signaling level, the ability to use SIP to say, change a call state or to pass information about a call, caller ID, that happens outside the voice channel. That is pretty standard.
The media streams, however, are dependent on what protocol you are using to encode the media; even there, SIP does not ensure you got a standard. What we see happening is that each vendor within their own world is using SIP for efficiency, absolutely. So you see some wonderful SIP-based phones, SIP-based products -- it makes the configuration much more efficient. Each vendor will build their own solution until the customer says, and we are consultants working with the end customers so we see this happen, the customer says, 'That is fine, but notice in the RFP it says that your brand X has to work with my existing installed Y.’ That is where either a gateway, or if you have two new brands, like a SIP system from company X and a SIP system from company Y, the customer will say, ‘You two have to get together and make these work.’ The good news is SIP is flexible enough for that to happen. Each time a customer says that to the two vendors, the two vendors will take that and put it in their product list, and they will call it a standard, so the standard for interoperability will grow. Today, it still is, I would say, the vendors are using SIP for efficiency, and the customers are forcing them to work together. I think about five years from now you may say, 'Great. Everything that was ever imagined in traditional telephony is being done by SIP,’ because the people want to keep moving forward, and all sorts of exciting new things are starting to happen. For example, SIP is working with mobile devices. You can go find on the web SIP clients for BlackBerry, iPhones, and so forth, so this mobile device becomes a telephone on a SIP system; it is a cool thing which was hard to do before. I think SIP is exciting, like you say. It is going to open up a lot of doors, but for the interim time, there is going to be a lot of intermediate appliances like gateways, and there will be a progression of the vendors working together to add the modules to interoperate.
Rivka Little: Under the pressure of users?
Marty Parker: Under the pressure of customers, right.
Rivka Little: There are still disparate video codecs. How do you work around that, and is there a solution coming down the pike?
Marty Parker: I think that it will be just like telephony. Why would it not be? In telephony, T1 looked like the standard: 64 kilobit time division multiplex T1 standard, but inside T1, people had codecs and compression/decompression modules to get more than one voice channel on a single T1 link; we saw that. When we got to IP Telephony, Voice Over IP, we saw different codecs: G7-11, G7-29, where you could choose one that would be an 8 kilobit sampling rate or a 64 kilobit sampling rate, depending on how much you wanted to trade off cost versus voice quality. Some companies actually would use more than one different standard in their company, maybe a higher compression, lower bit rate for their internal conversations and the less compressed, higher bit rate for customer conversation, so it allows you to basically use what you need; the family sedan versus limo for your guest; you have different things. The same thing is true for different video codecs, so we are going to see.
The best example I can give you is the difference between mobility video, desktop video, and telepresence. What you expect from those three is so different. You are not going to have one codec that does all three of those, and we will come back to the same conversation that we have had with telephony, and we just had about SIP, is that we will find gateways that will exist between these worlds. A company's telepresence world will be on a very high bandwidth environment: lots of bits, lots of image, really high definition, but if they want a product expert to join from their desktop, there will have to be a piece of software that converts back and forth. It does not have to be a physical gateway, does not have to be in a rack, but it will be a piece of software, a module, that will act as a codec, translator, or multi-point conferencing unit. An MCU will often do that work or it will have this MCU can deal with these five codecs, and I can take desktop in and put telepresence out, or vise versa. I think we are going to see, for good business reasons, a world of continued variety.
Rivka Little: In the short term, if I am investing in a video system, though, what am I looking for? Do I have to be sure that these gateways already exist, or what do I do?
Marty Parker: I think in the short term, actually in any term, let us talk about use cases. The thing we do with our clients in unified communications is look at use cases. Almost every company can be defined by, surprisingly, as few as five or six use cases. I was with a major investment bank over in Manhattan yesterday; they run their whole 70,000-person company on five use cases, so you are in one of those five categories. Some of those use cases do not even have a phone on the desk; in fact, they do not even have a desk because these are investment bankers who are out in the field, and the other people are in a call center. You imagine that is a certain type of equipment, too. You got these five categories, or six or seven, that is about the five to seven that will define a company. We have a healthcare client where the in-patient care providers, the nurses, medical assistants, and physicians, their use case goes through a mobile device. If I take those use cases then I can say, 'What is the video content of the use case? Am I going to need to be providing video to a mobile device? Great. That is a certain type of video.’ I may have, on the other hand, medical researchers who are doing intensive examinations with peers around the world of digital scans; they are going to want the equivalent of telepresence -- not so they can see each other, but so they can see all the little images, down to the bit-level. They want to see that image down to the pixel. We are going to say the use case will tell us how much video quality, how much video bandwidth, and what kind of a device the user needs. Since we only have five use cases, and within those five use cases, maybe a person has two different video requirements, but most likely it is one. They might have maybe one when they are mobile and one when they are at their desk, too. Then you can say, 'Alright. Now I get a defined set'.
Your question is, ‘How do I deal with this, with the vendors?’ Let us say I am going to go to Polycom, Cisco or Tandler, and basically say, ‘You are going to do my room high-definition video. Microsoft or IBM, you are going to do my desktop.’ So what I would do with the vendors is say 'I am going to set up a lab, and you two guys are going to go into the lab. You can come out when you show me these things work.' It is a condition of the purchaser. If you do not ask that at the time you are buying, it is a little bit more trouble; then you might have to pay a systems integrator to come and set up the lab and do the demo and show you. Some of the top system integrators will have those labs set up in their offices so you can go over to their office and see Microsoft Link working with a Polycom HD Video. You want to see it work before you start putting it in the racks and paying all the money. I think pilot testing or lab demonstrations, just like we have done in the past with other technologies ranging from telecom, to data, to applications -- it is going that the customer expects a proof of concept, pilot, or lab test before they purchase.
Rivka Little: Thank you so much for joining us, Marty. I really appreciate it.
Marty Parker: You are welcome.