Understanding SIP�Part IV: Describing the SIP Session

Tuesday Jun 7th 2005 by Mark A. Miller

In setting up a voice or video session, SIP transmits a detailed 'description' of the session using—you guessed it—a bevy of subsidiary protocols, such as SAP and SDP. Read all about it.

In the previous tutorials in our study of the Session Initiation Protocol (SIP), we considered the history and architecture of SIP, the capabilities of the protocol, and the message formats. In this tutorial, we will extend the discussion of the SIP messages to consider the role of the Session Description Protocol (SDP) in describing the parameters for those SIP messages.

SIP is an application protocol that initiates communication sessions on behalf of end users. The SIP architecture (defined in RFC 3261) builds upon two other Internet application protocols, the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP). In keeping with the objective of a consistent Internet Protocol-based architecture, we discovered similarities between HTTP addresses (Uniform Resource Locators or URLs), and SIP addresses, called SIP Uniform Resource Indicators, or SIP URIs. There are many forms of SIP URIs, however one form is quite similar to email addresses used with SMTP, such as sip:boomer@diginet.com.

Another element that SIP borrows from other protocols is the method by which sessions are described: Information that must be communicated between the two end parties at the beginning of the session. These two protocols are the Session Announcement Protocol (SAP), which is defined in RFC 2974, and the Session Description Protocol (SDP), which is defined in RFC 2327. In brief, SAP provides a mechanism to periodically advertise multimedia sessions, and to communicate relevant session information to prospective participants. It was developed in support of the Internet Multicast Backbone (Mbone), so that interested parties could be made aware of currently operating sessions.

SDP defines the format to describe a communications session, and as such, can be used with a number of transport protocols, such as SAP, SIP, HTTP, and others. RFC 2327 notes several key pieces of information that are provided by SDP:

  • Session Name and Purpose
  • Time(s) the session is active
  • The media comprising the session
  • How to receive those media (addresses, ports, formats, etc.)

Other information that may be optionally provided includes:

  • Bandwidth to be used by the conference
  • Contact information for the person responsible for the session

The SDP format includes a number of lines of text, of the form <type> = <value>, where the <type> defines a unique session parameter, and the <value> provides a specific value for that parameter. RFC 2327 defines the following values, with those marked with the asterisk (*) being optional. Note that there are three main parts to the description, detailing the Session, the Time, and the Media:

Session description
     v= (protocol version)
     o= (owner/creator and session identifier)
     s= (session name)
     i=* (session information)
     u=* (URI of description)
     e=* (email address)
     p=* (phone number)
     c=* (connection information - not required if included in all media)
     b=* (bandwidth information)

One or more time descriptions (see below)
     z=* (time zone adjustments)
     k=* (encryption key)
     a=* (zero or more session attribute lines)

Zero or more media descriptions (see below)

Time description
     t= (time the session is active)
     r=* (zero or more repeat times)

Media description
     m= (media name and transport address)
     i=* (media title)
     c=* (connection information - optional if included at session-level)
     b=* (bandwidth information)
     k=* (encryption key)
     a=* (zero or more media attribute lines)

Below is an example session description, taken from RFC 2327:

     o=mhandley 2890844526 2890842807 IN IP4
     s=SDP Seminar
     i=A Seminar on the session description protocol
     e=mjh@isi.edu (Mark Handley)
     c=IN IP4
     t=2873397496 2873404696
     m=audio 49170 RTP/AVP 0
     m=video 51372 RTP/AVP 31
     m=application 32416 udp wb

Note the two media descriptions (the lines beginning with m), which define an audio and a video profile. These profiles are described in the Real Time Protocol (RTP) specification, RFC 3550, section 13, and the companion document, RTP Profile for Audio and Video Conferences with Minimal Control, RFC 3551, section 6.

In our next tutorial, we will return to the SIP message formats, and discover how the SDP descriptor is embedded within SIP messages to convey session parameters between the parties, including those audio/video profiles.

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.
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved