It is worthwhile to spend some time studying what SDP session descrip-tions look like because they appear in many SIP messages. SDP session descriptions are text-based, as opposed to a binary encoding such as ASN.1.
An SDP session description consists of a set of lines of text of the form:
Type = value
The type field is always one character long and the format of the value field depends on which type it applies. An SDP description contains session-level information and media-session-level information. The session-session-level informa-tion applies to the whole session. It can be, for instance, the originator of the session or the session name. The media-level information applies to a par-ticular media stream. It can be, for instance, the codec used for encoding the audio stream or the port number where the video stream is headed.
An SDP session description begins with the session-level information and the media-level information, if any is present, comes after. The session-level section always starts off with v0, where vis the type and 0 is the value. This line indicates that the protocol version is zero (SDP version 0).
Ensuing lines, up until the first media-level section or the end of the session description as the case may be, provide information about the whole ses-sion.
Media-level sections begin with an mline. The lines below it, until the next mline occurs or until the end of the session description, provide infor-mation about that particular media stream. The following is an example of an SDP session description:
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112 s=SIP seminar
i=A Seminar on the Session Initiation Protocol u=http://www.cs.columbia.edu/sip
e=bob@university.edu c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly
m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000
In this example, the session-level section consists of the first nine lines, from v0 to arecvonly, and has three media-level sections: one audio stream and two video streams. The oline indicates the creator of the session (in this case, Bob) and the IP address of his site. The sline contains the name of the session and the iline contains general information about the session. The uline provides a Uniform Resource Locator(URL) where more information about the topic of the session can be retrieved. The eline con-tains the e-mail address of the contact person for this session. The multicast address where the session can be received is described in the cline and the tline indicates when the session is active. The last line of the session-level section, the a line, indicates that this is not an interactive session; it’s
receive only. The format of the mlines is especially important. An m line begins with the media type. In the previous example, the media types are audio for the first media stream and video for the second and the third.
m=<media type> <port number> <transport protocol> <media formats>
The port number indicates where the media can be received. The trans-port protocol field usually takes the value of RTP/AVP, but can take another value if a protocol other than RTP is used. RTP/AVP refers to the audio/video profile for RTP; in this example, encoded audio and video are transported using RTP over UDP.
The media format depends on the type of media transported. For audio, it’s the codec being used. In this example, a value of zero means that the audio is encoded in a single channel using PCM -law and sampled at 8 kHz.
The artpmap lines convey information, such as the clock rate or num-ber of channels, about the media formats used. In the second media stream of this example, the media format number 31 is referred to as H.261 and it uses a clock rate of 90 KHz.
Table 3-1 contains all the types defined by SDP and their meaning.
Extending SDP The media attribute lines, the alines, provide a means to extend SDP. When an application needs a feature missing in SDP, it can add an aline containing it. For example, if the creator of a multicast ses-sion wanted the receivers to play the audio at a certain volume, he or she could define a new media attribute and add it at the end of the media-level section.
m=audio 49170 RTP/AVP 0 a=volume:8
Applications that understand this new aline will play the audio at vol-ume 8. When an application finds an aline that it doesn’t understand, it simply ignores the line and proceeds as if no line had been encountered. The application that failed to understand our new avolume line could still receive media properly, although it would not be able to play back at the proper volume.
For those of you particularly interested in this topic, the IETF is already evaluating some proposed extensions in the form of new alines that will provide QoS when SIP and SDP are used together [draft-manyfolks].