As the networks of today move towards a converged future new protocols are constantly being developed to deal with the greater demand that is constantly being expected of them. In the area of Internet Protocol Telephony (IPTel), specifically Voice over Internet Protocol (VoIP), new technologies are being developed to meet the demands these new networks are generating, as well as make up for the shortcomings of older technologies that are currently being used.
One such demand realized by these new networks is the ability of the signaling protocol to establish a session between two end users whose locations change. Additionally, the ability to conduct voice communications over devices other than the traditional telephone compounds the issue of locating users in the fact that a given call may be received on multiple types of devices. Other factors can include establishing a session with multiple users, inviting new users into an existing session, and establishing the parameters of any given session.
Session Initiation Protocol (SIP), is an open standard that has been developed to address these and other demands placed on signaling protocols by not only voice, but all forms of multimedia transmission over data networks.
What is SIP?
Developed by the Internet Engineering Task Force (IETF) and described in RFC 3261, SIP is an application layer out-of-band signaling protocol designed to establish, modify, and tear down sessions between two or more endpoints for multimedia applications. SIP is based on a client server model and is designed with the mobility of uses in mind, laying out the framework to enable users to remain reachable even while moving about. SIP can also convey the abilities of participants to one another allowing the guidelines of a session to be negotiated. SIP has been designed with a few key ideas in mind:
Services and features are provided end-to-end whenever possible
Extensions and new features must be generally applicable, and not applicable only to a specific set of session types.
Simplicity is key.
Reuse of existing IP protocols and architectures, and integrating with other IP applications, is crucial.
(IETF SIP Charter, 2002)
SIP is designed purely as a signalling protocol. SIP alone will not enable multimedia commications to take place between two parties. Other protocols such as the Session Description Protocol (SDP), the Real-time Transport Protocol (RTP), and the Media Gateway Control Protocol (MEGACO) are needed to complete the package.
As with any signaling protocol, the major underlying component is addressing. SIP addressing takes a familiar form resembling that of email addresses, and is referred to as a SIP URL. A SIP URL may look something like:
Or any combination thereof. With this close resemblance to existing email addresses, SIP will be able to use the existing DNS infrastructure to assist in locating users to establish a call. The format of the SIP URL also allows for addresses to be embedded into web pages enabling 'Click to Talk' transactions to occur (similar to email's mailto:user@domain style links).
The SIP protocol calls for two major entities to exist: User Agents and network servers. Each of these groups may come in more than one types.
A User Agent is defined as any end system through which a user may communicate through. Examples include PC's and telephones. A User Agent is usually present in both a client and a server form. The User Agent Client (UAC) is responsible for making requests to a network server, while the User Agent Server (UAS) receives incoming call requests.
As with the User Agents, there is again two types of Network Servers: proxy servers and redirect servers. A SIP proxy server accepts client requests and forwards them either to another intermediary proxy server or to the UAS of the receiving party. A SIP redirect server does not forward client requests but instead refers the requesting client to another server (proxy or redirect) better suited to handle the request.
The actual operation of SIP is relatively simple. There are only two types of SIP messages: Request and Response, each having a small number of subtypes. As implied by the names of the messages, Request messages are from a client to a server asking for service, and a Response messages are from a server to a client in response to a Request. There are six types each of Request and Response messages. These types are listed in the table below.
Request Types Response Types
Cancel Client Error
Options Server Error
Register Global Error
The transmission of SIP messages over the wire take place in plain text, and are of a format comparable to the Hyper Text Transfer Protocol (HTTP). The SIP protocol is designed to use the ISO 10464 character set (Unicode). A sample Invite message may have headers that look something like the following:
INVITE sip:email@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:firstname.lastname@example.org>
From: Alice <sip:email@example.com>;tag=1928301774
CSeq: 314159 INVITE
(RFC 3261, 2002, p. 14)
This is exactly how the headers would be transmitted on the wire.
Competition to SIP
SIP, being a very new protocol, must overcome a couple older, more mature protocols already deployed in the marketplace. A comparison of SIP to all these protocols is beyond the scope of this paper, however a brief look at H.323, the currently dominating signaling protocol, compared to SIP is presented below.
H.323 is an older set of protocols that was designed by the International Telecommunications Union (ITU) for multimedia communications across the Internet. While H.323 has enjoyed a wide install base, it does have a few limiting characteristics. Most notably of these is the complexity of the H.323 protocols. H.323 uses a binary encoding in which to transmit its messages called Abstract Syntax Notation One (ASN.1) making it more difficult to parse when compared to the textual format of SIP.
Another drawback to H.323 is the gross complexity with which it is implemented. “H.323 describes hundreds of elements, while SIP has only 37 headers, each with a small number of values and parameters”(Fingal and Gustavsson, 1999, p. 27). This simpler format used by SIP can make troubleshooting and debugging far easier than with H.323.
Perhaps one of the most appealing attributes of SIP when compared to H.323 is SIP's ability to “fork”, that is, to have a single invite request cause the 'phone' in multiple locations to ring. This feature adds to SIP's ability to keeps users in contact even while on the move between multiple locations.
Challenges to SIP
Even though SIP is a new protocol (or perhaps because of it) there are many challenges it must overcome in order to become dominant in today's IPTel market.
The first hurdle is the adoption by equipment manufactures to incorporate SIP into their products. SIP will never enjoy widespread deployment if there is no equipment that supports it.
SIP must also prove its value, not just on paper, but also in practice. There must be a compelling reason for networks to either a) utilize SIP in new installations, or b) migrate to SIP from an existing installation. This is a natural obstacle that must be overcome by any new technology, and will be determined by time alone.
A newcomer to the IPTel playing field, SIP is designed as the signaling protocol of the future for multimedia communications. Drafted by the IETF, and released as an open standard, SIP promises to improve upon the existing signaling standards already in use, while simplifying operations.
SIP is designed with multimedia in mind, advancing the technologies that already exist in today's marketplace. SIP has all the potential to become a dominant standard, but faces many obstacles in order to achieve that goal.
Alcatel. (2002). Session Initiation Protocol (SIP). Alcatel Executive
Brief, Alcatel Internetworking.
Fingal, F. & Gustavsson, P. (1999). A SIP of IP-telephony. Master's
thesis, Department of Communication Systems, Lund Institute of
Technology, Lund University and Sigma Exallon Systems AB,
Greenfield, D. (2000). Inside the Session Initiation Protocol. Network
Magazine. Retreived March 19, 2004, from Network magazine
Internet Engineering Task Force. (2004, February 12). SIP
Charter. Retreived March 19, 2004, from the IETF Web site: http://www.ietf.org/html.charters/sip-charter.html
Radvision. (2001). SIP: Protocol Overview. White Paper, Radvision.
Rosenberg, J., Dynamicsoft, Schulzrinne, H., Columbia U, Camarillo,
G., Ericsson, et al. (2002). Request for Comments: 3261.
Retreived March 19, 2004, from IETF Web site: http://www.ietf.org/rfc/rfc3261.txt