July 2004

Wireless VoIP - SIP Support

BY RICHARD WATSON

What do Cisco, Nortel, 3Com, Avaya, Siemens, Alcatel, Mitel, and a host of other VoIP vendors have in common? They all support Session Initiation Protocol (SIP). In a market traditionally dominated by proprietary solutions, adoption of a �standard� has become the norm, driven by customer demand for inter-vendor interoperability and expanded functionality. SIP promises a new era of expanded multimedia connectivity beyond simple VoIP in order to provide a virtual ubiquitous system for person-to-person communications. In this article, we take a look at some of SIP�s strengths and challenges and attempt to answer some key questions, particularly whether SIP is ready for prime time, how SIP fits into the enterprise and whether SIP is ready for wireless.

SIP Status
One of the appealing aspects of SIP is its simplicity of design and flexibility to accommodate enhancements. This contrasts with early standards like ITU H.323 or the host of proprietary solutions and is primarily due to its second- or third-generation genesis. The scope of potential implementation options for SIP is broader than any of the preceding technologies and SIP holds hope to become the backbone architecture for the future of VoIP. Its popularity is apparent through reading the journals and ads to see vendors offering a broad spectrum of SIP support today. ISPs, IP Centrex services, or CPE/PBX systems all offer some kind of SIP compatibility in today�s market. SIP is still evolving as a standard (or set of standards), with multiple IETF groups defining new functional components that fall under the SIP umbrella. SIP�s features such as presence identification, simpler integration with other multimedia functions, and application level authentication are just a few examples of the features that make SIP an appealing architecture on which to base new VoIP systems.

Even with such popularity, there are questions regarding where SIP fits within enterprise business context and whether there are any wireless implementation considerations that are unique to SIP.

Initial SIP solutions are capable of making basic phone calls � the minimal services offered by ISP and IP Centrex companies. Much like a standard wide-area cell phone product, a SIP-enabled phone usually offers basic telephony connectivity capabilities: make/receive calls, voice mail, and limited call control functionality. Many of today�s SIP products offer added supplementary service features like call transfer and conferencing, but this doesn�t fully address the needs of the enterprise user.

Attempting to address the enterprise market with a SIP solution raises the bar considerably for functional requirements. Current SIP products are typically modeled after a personal cell-phone with basic functionality and a single user profile, whereas enterprise solutions demand a multi-user approach (�shared� phones) and extended supplementary call features, like Hold, Do Not Disturb, Forward, Hunt-group, Call Waiting, and more, that are traditionally derived from the local PBX.

The Enterprise Challenge
The IETF has acknowledged that there are a lot of requirements placed on an enterprise or business solution and there are currently several Task Groups working to define how these extensions will be integrated into the overall SIP architecture. For example, SIP-T (RFC 3372) is chartered with defining the taxonomy of interfacing SIP and PSTN-SS7 systems, in order to simplify integration of a SIP solution into today�s business environment where there is still a content requirement for calling and being called from the PSTN. Other groups are investigating and defining extensions that will provide for richer, PBX-like supplementary telephony service sets in future SIP products. As SIP is already an evolving standard set, this may pose challenges with inter-vendor interoperability for such extensions as they appear in the market, particularly as vendors try to integrate SIP with a PBX system that has hundreds of features.

Besides the richer telephony services demanded by the enterprise, vendors attempting to address this market are faced with the common challenge of delivering value-added differentiation. Traditionally, this has been accomplished through proprietary desksets and proprietary call control protocols. This normally allows vendors to implement new, exclusive features in its solution and maintain product differentiation positioning. However, adoption of a standard like SIP sets customer expectations for inter-vendor compatibility that must be addressed. How will the PBX vendors respond? Most likely, they will adopt an �enhanced� SIP for their PBX supported devices. For example, SIP does not define a control element for any hardware specific components, a requirement necessary for supporting an �extended feature� desk set. Features like speed dial, multi-line and hard-wired call state indicators require implementation of control elements within (or in parallel to) the call control protocol. The result of implementing these �extensions� is the creation of new proprietary solutions, which can lock customers into a specific vendor. Through this approach, such solutions can implement SIP with expanded feature capability and still provide for inter-vendor Internet call capability � the best of both worlds. Will this give the enterprise customer the ability to freely mix vendor products? Not likely. Limited interoperability will most likely be provided through vendor gateways and proxies to connect with standard Internet-accessible SIP devices.

SIP-WiFi Challenges
Are there any wireless considerations that need addressing with a WiFi solution? Yes. While there are a number of reliable SIP solutions for hardwired network access, there are also several architecture considerations that are unique to SIP and are a challenge in a wireless implementation.

By design, SIP only sets up and tears down �sessions� and provides a minimal focus as to management of the active session. In a wireless implementation, one of the active parties may �disappear� from the network because of a unique wireless situation. Most typically, a user can walk �out of coverage� or the battery will die and the device will leave the network, terminating the flow of RTP traffic from that device. Such a condition becomes apparent to a live user on the other end and they hang up, but automated interfaces, such as voice mail and other IVR applications, do not recognize this and may fail to shut down the session and restore the resources for subsequent calls.

Elements of the SIP standard, such as �Session Timers� (Internet Draft: draft-ietf-sip-session-timer-12), allow one side of the pairing to control the length of the session. But this creates a non-symmetrical architecture where the call originator is managing the negotiated session timer state. If the call originator is the wireless device that goes out of network, there remains no active element managing the session. In such a case, the SIP proxy or UAS must rely on other mechanisms to properly terminate the session and release the allocated resources. If such resources are not available within a short period of time (say 30 seconds), any attempt at calling the �dangling� party might result in a busy signal or being routed to voice mail and the call being missed. Such cases can occur frequently in a WiFi implementation and it is a challenge to wireless SIP vendors to accommodate for such behavior in delivering a reliable solution.

DTMF signaling is another design element that has unique wireless ramifications. The SIP specification dictates that DTMF signaling, like all audio elements, be �in-band.� This means that any such signaling is intermixed with the audio UDP-RTP traffic. However, problems arise in that wireless, by its nature, is unreliable and there is a finite risk that such unreliable transmissions will fail. Such signaling failures appear to a user as unreliable command responses on picking up voice mail or confusing results on an IVR interaction. To ensure the reliability of such signaling, attention must be paid to provide a reliable implementation mechanism. Fortunately, the IETF has defined methods for doing just this. Redundancy, and therefore reliability, can be injected into the audio stream when SIP applications support RFC 2833 (RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals) and/or RFC 2198 (RTP Payload for Redundant Audio Data). By using these RFCs, DTMF signaling achieves the reliability necessary to experience consistent behavior with a WiFi phone. Therefore, when considering deploying a WiFi-SIP solution, it will be important to understand the level of RFC support that the selected vendor provides.

Who/What Is Driving The Market?
VoIP is everywhere � in the journals, newspapers, hotspots, and on desktops. The VoIP �war� has been won and the world is rushing to deploy this new technology. There are many call control protocols in the VoIP market, and, just like the various cars from automobile manufacturers, they all get you from point A to point B. The real issue is how fast and with what level of comfort amenities do they get you there. As with most technologies that are broadly adopted by the marketplace (enterprise, SoHo and consumer), there will be only a few survivors. These �survivors� will be the technologies that can be implemented at the lowest cost, with broadest industry adoption and highest inter-vendor compatibility. Today, the protocol winner appears to be SIP. The race has not yet finished, but much of the pack has already bet on SIP as the winner. For example, Microsoft has dumped H.323 (NetMeeting) for SIP as the peer-to-peer call control protocol running behind MSN Messenger.

Ultimately, what drives a market is end-user need. Today�s enterprise and individual professionals have a real need for constant contact with customers and associates in order to compete successfully. This need has driven the cellular phone business to dizzying heights and will propel WiFi-VoIP adoption in the hotspot and enterprise space. It appears that the winning protocol underlying these applications will be SIP because it currently promises the richest feature set at the lowest cost with the broadest vendor support.

Summary
So, can I get a WiFi-SIP phone today that is ready for prime time? Yes. Whether it is offered as an embedded handset or in a PDA form factor, there are several products on the market that are being deployed in the enterprise and at hotspots. However, if a requirement for mobile telephony is a key element in your business strategy, there remain several things to consider when looking at a WiFi-SIP solution.
� Does the solution meet your functional needs? Do you need simple cell phone-like service or rich PBX features? If this is an enterprise decision, draft an RFP and understand that the availability of more feature-rich solutions will lag behind the introduction of simple SIP devices.
� Does the solution assure interoperability with multiple SIP vendors/services? Am I locked into a single vendor or can I purchase from multiple vendors?
� Has the vendor addressed the unique wireless issues, such as session management and reliable DTMF?

SIP is still evolving as a technology and requires some attention when deploying a business solution today. A thoughtful approach to answering the above questions will result in the successful deployment of a WiFi-SIP solution.


Richard Watson is director of telephony product marketing for Symbol Technologies� Wireless Systems Division in San Jose, CA. Prior to taking on the marketing role for Symbol�s NetVision family of WiFi Telephony products, he managed the software engineering team for three years and was responsible for developing Symbol�s WiFi Telephony products. For more information, visit www.symbol.com.
 

If you are interested in purchasing reprints of this article (in either print or HTML format), please visit Reprint Management Services online or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.

[ Return To The July 2004 Table Of Contents ]