Network Operations

1. SDP Deep Dive Bill Efthimiou APAN33 SIP workshop February 2012 Network Operations

2. Agenda • Overview • Protocol Structure • Media Negotiation 2 2

3. Overview • 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. 3

4. Overview - why bother with SDP? • 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. 4 4

5. NAPT – SIP REGISTER SIP REGISTER message across a NAPT firewall

6. NAPT – SIP INVITE SIP INVITE message across a NAPT firewall

7. Protocol Structure • Similar to SIP, SDP is a text based protocol. • An SDP session description is denoted by the message body content media type “application/sdp”. 7

8. Protocol Structure • 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: • <type>=<value> • where <type> MUST be exactly one case-significant character and <value> is structured text whose format depends on <type>. 8

9. Protocol Structure (cont-2) • In general, <value> 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. 9

10. Protocol Structure (cont-3) • 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 • e=j.doe@example.com (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 10

11. Protocol Structure (cont-5) 11

12. Media Negotiation (Offer/Answer Model) • 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. 12

13. Media Negotiation (Offer- example) 13

14. Media Negotiation (Answer- example) 14

15. Thank you Questions ?