Introduction to SDP Issues Content • • • • • • • • Background Goals SDP Primer RTP Primer Use cases “New” Functionalities in SDP Multiple RTP Streams in SDP Decision February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 2 Background • New applications and usages – WebRTC / RTCWEB – Telepresence / CLUE • • • • Existing advanced applications Group communication Multiple media Transport optimization – Re-use transport ports – Media bandwidth adaptation February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 3 Goals • Understand the diverse usages • Understand considerations • Can’t delay choice: – Market will pick if we fail • Achieve sufficient understanding – TO PICK a DIRECTION – Issues will remain to resolve February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 4 SDP Primer SDP Primer • Media Block – m-line and all subsequent lines until next m-line – All lines between two m-lines are local to the Media Block – Describes mainly what sender of SDP is prepared to receive, and how • Send direction properties do exist, e.g. for sendonly, but their exact meaning in SDP Offer/Answer are somewhat case-by-case – There are no inherent priority specified among Media Blocks – Multiple Media Blocks in SDP are not automatically alternatives • E.g. one audio and one video Media Block are typically simultaneous – Order of Media Blocks must be kept between SDP Offer and Answer – Used to be roughly equivalent to an RTP Session, but no longer is • Media Type – m=<media type>… e.g. audio/video/application February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 6 SDP Primer (continued) • Port – m=<media type> <port> …, e.g. 49852 – Where SDP sender is listening for this media – Set to 0: Disable entire Media Block (cannot remove it) • Protocol – m=<media type> <port> <protocol> …, e.g. RTP/AVP – Cannot be changed between SDP Offer and Answer • Many exist; [S]RTP/[S]AVP[F], currently 8 combinations • Negotiation addressed by SDP CapNeg (RFC 5939) February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 7 SDP Primer (continued) • Format – m=<media type> <port> <protocol> <format list>, e.g. 8 0 101 99 – Describes packet formats understood by receiver • Media receiver must be prepared to receive packets in any of the Offered formats at any time after sending the SDP – <format list> is sorted in priority order with highest priority first • Order, and thus priority, can change between SDP Offer and Answer – SDP Answer removes unsupported formats and may add new ones – For RTP, <format list> is a set of RTP Payload Type numbers • a=rtpmap:<format> <codec/sampling> maps format to codec type • a=fmtp:<format> <codec parameters> further details codec usage • Recommended to keep same mapping in SDP Answer as in Offer February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 8 RTP Primer • “RTP Session” – All endpoints that can see each other’s SSRC (SSRC space) • Explicit in RTP packets • Implicit in reporting by RTCP packets • “RTP Media Stream” – The sequence of all packets with the same SSRC in an RTP Session • “RTP Payload Type” – – – – – Identifies packet content format Used in a single direction between sender & receiver Meaning established through RTP-external signaling, e.g. SDP May change per RTP packet, also within a single RTP Media Stream Not recommended to use more than one RTP Payload Type valid for the same RTP TimeStamp within an RTP Media Stream February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 9 “Encoding” • In this presentation defined as: “One encoded representation of a single Media Source” • Includes related “protection streams” such as Retransmission and Forward Error Correction • One Media Source can have several Encodings • Can have dependencies to other Encodings, such as for Scalable or Layered encodings February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 10 What is Media Stream? • Not the WebRTC Term MediaStream • What is meant with a Media Stream? – SSRC, single RTP stream – Single Encoding of a media source One or More SSRCs (also e.g. protection streams) – Single Media Source Multiple Encodings Even more SSRCs • We must be clear when discussing – Please be explicit in what you mean February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 11 WebRTC in SDP One Encoding of a MediaStreamTrack source can in its simplest form be a single SSRC <Session-wide part> <Media Block 1> <SSRC-specific attributes> <Format-specific attributes> <Media Block 2> <Media Block 3> One MediaStream typically contain MST from multiple Media Blocks … <Media Block n> A PeerConnection uses the SDP to describe its MS and MST February 5-7, 2013 One Encoding specification can be re-used by several MediaStreamTrack sources Bundling Media Blocks on same transport necessitates making some Media Block-local attributes global, or at least aligned, across all bundled Media Blocks RTCWEB / MMUSIC / W3C WebRTC Interim 12 Use Cases One or more per PerConnection A Sources WebRTC Track MediaStream One or more per transport PeerConnection B Sources One or more per MediaStream Same MS can be transported by multiple PC Sources are represented as encodings February 5-7, 2013 C Sources RTCWEB / MMUSIC / W3C WebRTC Interim Same source can be used in multiple Tracks Same source can have multiple encodings 14 CLUE • Multiple simultaneous – – – – – Endpoints; conference is the typical use case Sources; cameras, microphones Presentations; displays, speakers Media types; audio, video Encodings; representations of media • SIP/SDP + CLUE specific signaling protocol – Media source specific information for CLUE • Grouping – Scenes, from related sources – Alternative scene representations February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 15 “New” Functionalities in SDP Multiple Sources • Signaling RTP session with multiple sources of same media type – sent from a single endpoint – received by a single endpoint February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 17 Transport Aggregation • Multiple protocols on same transport (UDP port) – STUN – DTLS-SRTP – DTLS/SCTP – (S)RTP • Multiple media types in same RTP session February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 18 Simulcast and Scalability • Multiple encodings of a single media source – Independent: Simulcast – Dependent: Scalable (or layered) encoding February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 19 Multiple RTP Streams in SDP A Fundamental Issue SINGLE vs MULTIPLE SOURCES PER SDP m- line • SINGLE SOURCE (SSRC) m=audio <SSRC #1> m=audio <SSRC #2> • MULTIPLE SOURCES (SSRCs) m=audio <SSRC #1> <SSRC #2> February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 21 RTP Session Usage • WebRTC – Multiple media sources – Multiple encodings likely per media source – All RTP streams (SSRCs) in a PeerConnection as • one RTP session or • one RTP session per Media Type – Two Endpoints per Peer Connection • CLUE – Multiple media sources – Multiple encoding per media source intended to be supported – One or More RTP session (undecided) • Multiple end point can be visible, even for unicast transport February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 22 RTP Session Usage • Layered Multicast – Multiple RTP sessions each on its own multicast address – Receiver decided how many simultaneous session it joins – Same media sources can be present in all RTP sessions February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 23 Implicit SSRCs • Roach argues that you must signal all Media Streams • This is not necessary and sometimes not possible – Applications may not know number of sources and their SSRC numbers – Implicit or bound in RTP when existing, e.g. RTP retransmission • One to one mapping with source stream • Can benefit from explicit binding in signaling or RTCP – Other Signaling Protocols than SDP • CLUE is likely to become an example – Use only SDP to establish transport and RTP session structure – Info of the media streams a provider sends goes into “CLUE” protocol – Implicit by Application Knowledge • MBONED RAT application – RTP streams for end points are injected – Meta data provided in RTCP – Using common session configurations February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 24 Information Structures • RTP Session level – – – – – – – – – Which RTP streams share session Which transport flows are used by session Security mechanism RTP profile The payload types RTP header extensions Aggregate Bandwidths RTCP Bandwidths Possible media directions February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 25 Information Structures • Payload Type specific – The payload configuration (a=fmtp information) • Codec parameters • Packing – RTP/RTCP extensions associated with PT e.g. • Full Intra Refresh, etc. [RFC 5104] • RTP header extensions – Payload specific bandwidth restrictions • draft-westerlund-mmusic-sdp-bw-attribute February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 26 Information Structures • RTP Stream (SSRC) Specific information – Meta information and bindings to application – Which payload types it can use – Bandwidth restrictions – Grouping with other related SSRCs – Enabled or Paused? February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 27 LEGACY INTERWORKING • There are legacy applications with single source per m- line, and there are legacy applications with multiple sources per m- line. • Single source: – Typical VoIP networks – IMS • Multiple sources: – Video Conferencing • (Standards based but proprietary) • Some will need to interwork with new functionality February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 28 Transport Aggregation • Separate Protocols – STUN, DTLS, RTP, etc. – Signaling to understand intention and agree • Handling RTP sessions – Signal which RTP sessions an application will use – Some applications will want one, other many February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 29 Consistency Issues • Required to have consistency across m= lines – For example all PT=97 in an RTP Session must be identical • Consistency will be an issue for all information that is duplicated February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 30 MULTIPLE SSRC per m= Line • PROS – Possible for multiple sources to share 5-tuple (without BUNDLE) – Possible for multiple sources to share RTP session (without BUNDLE) – Possible for multiple sources to share m- line “wide” properties (PTs, SDP attributes, etc) • Smaller SDP size – Offer/Answer does not, for a given m- line, require equal number of sources in offer and associated answer February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 31 MULTIPLE SSRC per m= Line • CONS – Not possible to specify which payload types a source use • The PT / format list applies to the whole m= line – Mechanism needed in order to specify source specific SDP property values (SPD attributes etc) • Base framework in RFC 5576 – SDP SSRC attribute • Requires specification for each SDP property type for which there is a need to specify a source specific value February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 32 Summary • Required to select a direction • Some legacy will be affected if forced to interface – Can be worked around after determining endpoint capabilities • Independent of choice there will be work required to define interpretations and new mechanism to achieve desired functionality February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 33 Decision