Understanding SIP�Part I: History and Architecture

Reflecting the IETF's pragmatic development mind-set, and built on other well-known protocols such as HTTP and SMTP, SIP is viewed by many as fundamentally simpler than H.323.

By Mark A. Miller | Posted May 17, 2005
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

The four previous tutorials in this series considered the H.323 standard, developed the International Telecommunications Union–Telecommunications Standard Sector (ITU-T) to support multimedia communication (H.323 Part I, Part II, Part III, Part IV). With this tutorial, we begin a similar study of the Session Initiation Protocol (SIP), supported by the Internet Engineering Task Force (IETF). In this tutorial, we will consider the history and architecture of SIP, as well as some of the related Internet protocols that have influenced the SIP design.

As we have seen, the ITU-T and the IETF frequently approach networking architectures and protocol design from different perspectives. The ITU-T, being an international standards body affiliated with the United Nations, considers consensus and peacekeeping to be high on its priority list, and as a result, the standards it produces go through a number of iterations and drafts, and it can take years to produce a final, agreed-upon result. In contrast, the IETF is much more pragmatic, believing in the often-quoted concept of "rough consensus and running code," meaning that everyone may not agree on all the fine points, but nevertheless keep moving towards a functional system or protocol.

In most cases, IETF standards development cycles are also quite a bit shorter than those of the ITU-T. This is due in part to the fact that the IETF holds open forums three times a year. These spring, summer, and fall meetings are scheduled at various locations around the world and are open to any interested parties (see http://www.ietf.org/meetings/meetings.html for details). Various IETF working groups gather at these meetings and hash out the technical details regarding their current system development. If some unresolved issues remain at the end of the meeting, they continue to be studied, and are then reconsidered at the next meeting just a few months away. In short, the IETF takes a very pragmatic approach to system architectures and protocol design that could perhaps be summarized by: 'Let's agree on something that looks promising, give it a try, and get back together in a few months to review the results.'

This pragmatic approach is clearly reflected in the architecture of the Session Initiation Protocol, or SIP as it is commonly known. The SIP architecture begins by building upon two other Internet application protocols, the Simple Mail Transfer Protocol (SMTP), which is defined in RFC 2821, and specifies the format for electronic mail messages, and the Hypertext Transfer Protocol (HTTP), which is defined in RFC 2616, and specifies the format for web-based multimedia communication. In addition, SIP uses functions defined by the Real Time Transport Protocol/Real Time Control Protocol (RTP/RTCP), defined in RFC 3550, which specifies the formats for multimedia packets over Internet Protocol (IP) networks, and the Session Description Protocol (SDP), defined in RFC 2327, which specifies the characteristics and parameters of a multimedia session. Thus, SIP builds upon other IETF-developed protocols, much like H.323 builds upon other ITU-T protocols such as H.225.0 and H.245. In addition, it runs on top of other IETF-defined transport protocols, such as the Transport Control Protocol (TCP), the User Datagram Protocol (UDP) and the Internet Protocol (IP).

The SIP architecture defines two main devices: clients and servers. A client is described in RFC 3261 as a network element that sends SIP requests and receives SIP responses. A client may or may not interact with a human user. Similarly, the server is a network element that receives requests in order to service them, and then responds to those requests.

Digging deeper, we find several examples of clients:

  • User Agent Client: a logical function that creates a request, and then uses the client functionality to send that request.
  • Proxy: an intermediary device that acts as both a client and a server, and which makes requests on behalf of other clients.

Note that the Proxy requires both client and server functionality.

We also find several examples of servers noted in RFC 3261:

  • User Agent Server: the logical function that generates a response to a SIP request.
  • Redirect Server: a server that redirects a client to contact another server to complete its request.
  • Registrar: a server that accepts REGISTER requests, and then places that information into the location service.

Thus, the foundation of well-known and extensively implemented Internet protocols, such as HTTP, plus the client/server architecture, provides SIP with a degree of simplicity that many feel is superior to the complexities found in H.323.

Our next tutorial will examine the operation of these SIP constructs in greater detail.

Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved


Author's Biography
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter