4.1 The Session Description Protocol Overview
4.1.1 MEDIA INFORMATION
In general, there is a lot of information carried in a session description and the media information is essential for our implementation. It includes:
The type of media (video, audio, etc).
The transport protocol (RTP/UDP/IP, H.320, etc).
The format of the media (H.261 video, MPEG video, etc).
For an IP multicast session, the following information is also conveyed:
Multicast address for media.
Transport Port for media.
This address and port are the destination address and destination port of the multicast stream, whether being sent, received, or both.
For an IP unicast session, the following information is conveyed:
Remote address for media.
Transport port for contact address.
The semantics of the address and the port depend on the media and transport protocol defined. By default, this is the remote address and remote port to which data is sent, and the remote address and local port on which to receive data. However, some media may define to use these to establish a control channel for the actual media flow.
4.1.2 AN SDP DESCRIPTION STRUCTURE
An SDP session description consists of a number of lines of text of the form:
<type>=<value>
Where <type> is always exactly one character and is case- significant, and <value> is a structured text string whose format depends on <type>. It also will be case-significant unless a specific field defines otherwise.Whitespace is not permitted either side of the ‘=’ sign. In general <value> is either a number of fields delimited by a single space character or a free format string.
An announcement consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a ‘v=’ line and continues to the first media-level section. The media description starts with a ‘m=’ line and continues to the next media description or end of the whole session description.
The permitted type fields in a SDP session are shown in Table 4. Some lines are obligatory and others are optional (marked with a “*”) but all of them must exactly appear in the order given here.
SESSION DESCRIPTION
TYPE DESCRIPTION
v
P
ROTOCOL VERSIONo
O
WNER/
CREATOR AND SESSION IDENTIFIERs
S
ESSION NAME i*S
ESSION INFORMATION u*URI
OF DESCRIPTION e*E
MAIL ADDRESS p*P
HONE NUMBER c*C
ONNECTION INFORMATION(**)
b*B
ANDWIDTH INFORMATIONz*
T
IME ZONE ADJUSTMENTSk*
E
NCRYPTION KEYa*
Z
ERO OR MORE SESSION ATTRIBUTE LINES(**) NOT REQUIRED IF INCLUDED IN ALL MEDIA
TIME DESCRIPTION
TYPE DESCRIPTION
t
T
IME THE SESSION IS ACTIVEr*
Z
ERO OR MORE REPEAT TIMESMEDIA DESCRIPTION
TYPE DESCRIPTION
m
M
EDIA ANDT
RANSPORT ADDRESSi*
M
EDIA TITLEc*
C
ONNECTION INFORMATION(**)
b*
B
ANDWIDTH INFORMATIONk*
E
NCRYPTION KEYa*
Z
ERO OR MORE SESSION ATTRIBUTE LINESSDP parsers must ignore any announcement that contains a <type> letter that it does not understand. The attribute mechanism is the primary means for extending SDP and tailoring it to particular applications or media. Some attributes have a defined meaning but others may be added on an application, media or session specific basis. A session directory must ignore any attribute that it does not recognize.
4.2 A SDP Session Example
In order to clarify the concepts presented previously, next we will introduce an SDP session example, see Figure 10. Some fields are mandatory and others are suggested depending on the application. The most relevant ones such as protocol version, origin, session name, time, connection data and media announcement are described in detail.
Figure 10. SDP Session Example
4.2.1 PROTOCOL VERSION
The ‘v=’ field gives the version of the Session Description Protocol. There is no minor version number.
In the example: v=0
4.2.2 ORIGIN
The ‘o=’ field gives the originator of the session (their username and the address of the user's host) plus a session id and session version number.
In the example: o=queca 2890844526 2890842807 IN IP4 130.233.154.68
The general field structure is:
o=<username> <session id> <version> <network type> <address type><address>
EXAMPLE
v=0
o=queca 2890844526 2890842807 IN IP4 130.233.154.68 s=ICW SIP
i=A session for voice transmission using SIP u=http://www.hut.fi/staff/Queca/sdp.03.ps [email protected] (Queca Espigares) c=IN IP4 130.233.154.68 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31
<username> is the user's login on the originating host, or it is ‘-‘ if the
originating host does not support the concept of user ids. <username> must not contain spaces.
<session id> is a numeric string such that the tuple of <username>, <session id>,
<network type>, <address type> and <address> form a globally unique identifier for the session.
The method of <session id> allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) timestamp be used to ensure uniqueness [31].
<version> is a version number for this announcement. It is needed for
proxy announcements to detect which of several announcements for the same session is the most recent. Again its usage is up to the creating tool, so long as <version> is increased when a modification is made to the session data. For this reason, it is recommended that an NTP timestamp is used.
<network type> is a text string giving the type of network. Initially ‘IN’
is defined to have the meaning ‘Internet’.
<address type> is a text string giving the type of the address that
follows. Initially ‘IP4’ and ‘IP6’ are defined.
<address> is the globally unique address of the machine from which the
session was created. For an address type of IP4, this is either the fully qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully qualified domain name of the machine, or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address may be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful.
In general, the ‘o=’ field serves as a globally unique identifier for this version of this session description, and the subfields excepting the version taken together identify the session irrespective of any modifications.
4.2.3 SESSION NAME
The ‘s=’ field is the session name. There must be one and only one ‘s=’ field per session description, and it must contain ISO 10646 characters.
In the example: s=ICW SIP
4.2.4 CONNECTION DATA
The general field structure is:
c=<network type> <address type> <connection address>
A session announcement must contain one ‘c=’ field in each media description or a ‘c=’ field at the session-level. It may contain a session-level ‘c=’ field and one additional ‘c=’ field per media description, in which case the per-media values override the session-level settings for the relevant media.
<network type> is a text string giving the type of network. Initially ‘IN’ is
defined to have the meaning ‘Internet’.
<address type> allows SDP to be used for sessions that are not IP based.
Currently only IP4 is defined.
<connection address> is the third sub-field. For IP4 addresses, the connection
address is defined as follows:
If the session is not multicast, then the connection address contains the fully qualified domain name or the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields.