AARNet Copyright 2011 Overview 3 RFC 4566. When initiating
multimedia sessions, there is a requirement to convey media
details; transport addresses, and other session description
metadata to the participants. The purpose of SDP is to provide a
structure to convey information about media streams in multimedia
sessions to allow the recipients of a session description to
participate in the session. SDP is purely a format for session
description. SDP must be used in conjuction with other protocols
such as SIP. SIP carries SDP information within the SIP message
body.
Slide 4
AARNet Copyright 2011 Overview - why bother with SDP? 4 4 Why
is it important for us to understand SDP? To understand the media
negotiation mechanism. Because of media (codec) interoperability.
An understanding of SDP helps us understand interoperability issues
and often where and what to look for when troubleshooting. When
negotiating video codecs the process gets a little more
complicated. To understand common NAT Traversal issues with
multimedia signalling.
Slide 5
AARNet Copyright 2011 NAPT SIP REGISTER SIP REGISTER message
across a NAPT firewall
Slide 6
AARNet Copyright 2011 NAPT SIP INVITE SIP INVITE message across
a NAPT firewall
Slide 7
AARNet Copyright 2011 Protocol Structure 7 Similar to SIP, SDP
is a text based protocol. An SDP session description is denoted by
the message body content media type application/sdp.
Slide 8
AARNet Copyright 2011 Protocol Structure 8 Similar to SIP, SDP
is a text based protocol. An SDP session description is denoted by
the message body content media type application/sdp. An SDP session
description consists of a number of lines of text of the form: =
where MUST be exactly one case-significant character and is
structured text whose format depends on.
Slide 9
AARNet Copyright 2011 Protocol Structure (cont-2) 9 In general,
is either a number of fields delimited by a single space character
or a free format string, and is case-sensitive unless a specific
field defines otherwise. SDP consists of a session- level section
followed by zero or more media-level sections. The session-level
section continues until the first occurrence of the media
description field (m=). Each subsequent occurrence of the media
description field marks the beginning of data related to another
media stream in the session. Generally, session-level values are
the default for all media unless overridden by an equivalent
media-level value.
Slide 10
AARNet Copyright 2011 Protocol Structure (cont-3) 10 Some lines
in each description are REQUIED and some are OPTIONAL. Ordering of
Fields: Session description v= (protocol version) o= (originator
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=* (zero or more bandwidth information lines) One or more time
descriptions ("t=" and "r=" lines; see below) z=* (time zone
adjustments) k=* (encryption key) a=* (zero or more session
attribute lines) Zero or more media descriptions Time description
t= (time the session is active) r=* (zero or more repeat times)
Media description, if present m= (media name and transport address)
i=* (media title) c=* (connection information -- optional if
included at session level) b=* (zero or more bandwidth information
lines) k=* (encryption key) a=* (zero or more media attribute
lines) The attribute mechanism a= is the primary means for
extending SDP and tailoring it to particular applications or media.
An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN
IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description
protocol u=http://www.example.com/seminars/sdp.pdf
[email protected] (Jane Doe) c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video
51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
AARNet Copyright 2011 Media Negotiation (Offer/Answer Model) 12
SDP lacks the negotiation process to enable signalling endpoints to
reach agreement. RFC 3264: SIP using SDP in an Answer/Offer
mechanism. RFC 4317 SDP Offer/Answer examples. The initiator of the
session offers a selection of multimedia formats to be used in the
session. The receiver of the offer either rejects the offer, or
selects those media formats that have been offered and which the
responder is willing/able to accept. The offer will contain zero or
more media streams. The answerer will respond with one or more
media streams or reject the offer.
Slide 13
AARNet Copyright 2011 Media Negotiation (Offer- example)
13
Slide 14
AARNet Copyright 2011 Media Negotiation (Answer- example)
14