SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

CHANNEL BY TOPICS


QUICK LINKS




 
IMS Magazine logo
Aug/Sept 2008 | Volume 3/Number 4
Featured Articles

Flavors of SIP and IMS

By Richard "Zippy" Grigonis
The original title of this article differed by one word – it was to be 'Flavors' of SIP in IMS, but Seamus Hourihan of session border control maker Acme Packet immediately assured me that, "Theoretically speaking, there are not really 'Flavors of SIP in IMS' as defined by any single architecture group – 3GPP, ETSI , MSF, PC, and so forth. However, many service providers are not implementing IMS as defined by the architecture spec: SIP UDP versus SIP TCP transport, for example. And even if two vendors are implementing the same spec, things don't necessarily work until we fix things up."

Flavors of SIP

Hourihan, Vice President of Marketing and Product Management at Acme Packet , also says, "SIP is not really a single protocol. From a messaging perspective, there are various messages that are used to set up SIP, from an INVITE message to things such as RINGING, CANCELs, BYEs, ACKs and those are fairly standard. But then you get into things such as REFERs, which are messages to refer a call from one party to another or one place to another. There are new message types or new 'parameters' if you will, that come with IMS, such as the concept ofidentity, and PRACK, which are used to reserve network resources or bandwidth end-to-end. The problem with some of these things is that they significantly increase the number of messages required to set up a call."

"So, for example, in practice, take the things specified by IMS as defined by 3GPP," says Hourihan. "If you use PRACK, and you're roaming on an access network – your 'visited' network – and you go to a home network or a transit network, I can show you call flows that show how a simple SIP call that in one network might require 7 messages to set up a call and tear it down, in another might take 250 or more messages. The issue here is that we're trying to be very 'elegant' about ensuring that we have bandwidth for this 'one more call' all the way to the destination. The problem is that this approach can increase the number of messages so significantly that that it imposes a major performance burden on all of the elements involved. Those critical elements are session border controllers, softswitches, and in the IMS world CSCF [Call Session Control Function] elements involved in serving, interrogating and those types of things. Consequently, the number of subscribers or callers that can be supported becomes much diminished."

"Then you have other options within SIP," says Hourihan. "The transport protocol is one area. You may be familiar with UDP [User Datagram Protocol], TCP [Transport Control Protocol] and SCTP [Stream Control Transport Protocol]. Each of these are options for transporting SIP at Layer 4 in network. Most of the deployments today use UDP. Why? Basically, because it's very simple and lightweight. It poses the least burden on signaling elements in terms of processing performance required. It is, however, connectionless, which means that if you lose a packet you probably won't be able to accept that call. TCP and SCTP are connection-oriented and so there's greater reliability. Many SIP endpoint devices today don't support TCP, especially SIP-based media gateways are a good example. Not all softswitches may support it. TCP is being specified by the SIPconnect standard for connecting enterprises with SIP trunks. TCP has been embraced by Microsoft in terms of OCS implementations. But again, much of the world today operates with UDP. Consequently, if you want to bridge networks, you need a product such as a session border controller from Acme Packet to be able to translate SIP UDP in on one side to SIP TCP on the other side."

"There are standards in the world that mandate SCTP," says Hourihan. "in the U.K., regulated peering requires SCTP between operators. Again, this is some of the complexity that we all must deal with."

"The next area is encryption protocols," says Hourihan. "Again, there a wide range of choices. Relative to IMS, on the access/subscriber side, IMS 3GPP would specify IPsec as the encryption protocol for both signaling and media from a tunnel perspective. CableLabs PacketCable specifies TLS [Transport Layer Security], similar to SSL [Secure Sockets Layer] in the web world. You can use IPsec, not in 'tunnel mode', which handles both signaling and media, but in 'transport mode' which just handles signaling. Sometimes this is associated with TLS. You can also use SRTP [Secure Real-Time Transport Protocol] for the media. But consider that most of world's traffic today is not encrypted. Many endpoints don't support encryption. So a lot of the media gateways that connect traffic to the PSTN don't' support any encryption protocols and consequently need session border controllers in front of them to basically translate encrypted traffic to unencrypted traffic. Many of the media servers are in a similar situation."




"There's a lot of desire by service providers today to basically keep their core infrastructure," says Hourihan. "In IMS it would be the CSCF elements, media gateways, media servers, and the applications environment, all connected with basic SIP-over-UDP. Why? Because it's very simple. It has low overhead, which means you can support more subscribers and thus generate more dollars for your Capex."

"When talking about SIP flavors, you can even delve into such esoteric areas as response codes or error messages," says Hourihan. "For example, if the server is overloaded, or not everybody is consistent in terms of how they react to a problem, some people might issue a 404 message – these response messages you see on the web – however, different SIP elements, for the same type of problem, will generate different response codes. If the responses are being generated into another network, they sometimes need to be translated from one error code to another to evoke the proper behavior of the other elements in that network." As for IMS, says Hourihan, "IMS assumes that every endpoint – IP phone, soft client, mobile handset, and so forth – can register itself for service with a SIP Registrar. The problem that poses relates to supporting enterprises. An IP PBX aggregates a number of endpoint IP phones for which it provides initial call control. There's a need to augment the capabilities of those elements with the ability to do what we call aggregate registrations for those devices. The same problem could apply to a residential household environment, where you have some type of residential gateway that may be aggregating four wireline phones or even a wireless phone or a femtocell application, where you have multiple subscribers connecting to one residential gateway-type product. It needs to generate individual registrations for each of those four endpoints. Again, many of these residential gateways are an IAD [Integrated Access Device] and don't have that capability."

"People focus on SIP," says Hourihan, "but other things can be involved in setting up a call. These are completely optional in the context of SIP. One area is codecs. Most but not all IP phones today support G.711. And none of the wireless phones will support G.711. Why? Because the wireless world has its own codecs: GSM-AMR, EVRC and others developed to optimize bandwidth use in the radio access network that has lots of bandwidth issues today in terms of 2G and 3G, quite frankly, on the upstream side. This is the one area about which I'm least optimistic in terms of creating a single 'world' that works. As an example, Microsoft in their genius has invented two new codecs, MSRT Audio [Microsoft Real-Time Audio] a speech codec designed for real-time two-way VoIP applications, and a real-time video codec, both of which are proprietary to Microsoft and are the basis of their standard default codecs in an OCS environment. They're very good codecs but the problem is, despite what Microsoft thinks, the world isn't all Microsoft."

"Then there's H.323, believe it or not," says Hourihan. "As recently as 2007, many large enterprise PBXs were still using H.323 on the trunk side. These must be interworked to an all-SIP world."

Flavors of IMS

Chad Hart , Senior Product Marketing Manager at Empirix (one of the world's great providers of voice testing and monitoring solutions), says, "What's more interesting is that, with such various technologies and codecs, you actually have different 'flavors' – there's definitely different interpretations of how to build an IMS-like network. There used to be a lot of differences. The 3GPP2 had its own set of specs with its own differences. There was ETSI TISPAN with its own set of specs. And there was a bunch of other groups out there such as the MultiService Forum and ATIS and even OMA that had their own architectures. Over the last three of four years there has been a lot of convergence and coordination among allthese groups to minimize the number of differences."

"A number of things have happened," says Hart. "First, the ETSI TISPAN group that was working on the core infrastructure of IMS had its efforts rolled into the 3GPP. It's now one group that does all of that. The CableLabs group more or less took the IMS architecture and reused as much of it as possible – there still are some differences in their architecture. Cable has good robust policy and bandwidth control schemes, which are new to wireless and DSL networks. So, whereas CableLabs decided to stick with its existing policy and resource control infrastructure, ETSI TISPAN decided to take its own approach. How they do things like that boils down to the fact that cable operators are building on a cable network and IMSwas really initially designed for a wireless network, and then adapted to DSL-type and other networks. Groups such as the OMA coordinated with the 3GPP and realized that a lot of their standards for things such as push-to-talk and presence, are a fit within the IMS architecture."

"The MultiService Forum for the most part has adopted the IMS architecture," says Hart, "although there are some differences and they're probably a little more specific in some areas, and the way they break out some of the border control aspects of IMS is a little different than the names that you'd normally encounter in IMS. At the end of the day, however, the actual devices and vendors and people involved in actually buildingIMS products are premised all the same but, depending on which reference you're talking about, some things have a slightly different name, and there may be some differences. It becomes a headache if you're a product manager or developer trying to figure out which reference refers to what. When you get into the actual details of specifications, there are in fact some differences that need to be worked out. Even so, there is a lot more harmonization than ever before, at least at the higher levels of the IMS architecture."

"In the mobile world, some of the components behave differently," says Hart. "The mobile world uses a compressed version of SIP. They use SigComp [Signaling Compression] which is a solution for compressing messages generated by application protocols such as SIP. There's no reason to compress SIP headers in the wireline world, since there's plenty of bandwidth. In a wireless network, however, because there's so much latency there is in fact an advantage to do compression."

Just for the Taste of It

Both SIP and IMS have their respective "flavorings", but they are becoming increasingly similar and subtle – an expected process as technologies in different operating environments slowly converge as they come into standard usage.

And Yours Truly even managed to get through this article without making a "tastes like chicken" joke.

Richard Grigonis is Executive Editor of TMC's IP Communications Group.

Companie's Mentioned in this Article:

Acme Packet
www.acmepacket.com

CableLabs
www.cablelabs.com

Empirix
www.empirix.com

Microsoft
www.microsoft.comq

IMS Magazine Table of Contents









Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2020 Technology Marketing Corporation. All rights reserved | Privacy Policy