1. Introduction to SDP Issues

2. 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

3. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 3 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

4. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 4 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

5. SDP Primer

6. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 6 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= … e.g. audio/video/application

7. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 7 SDP Primer (continued) Port – m= …, e.g. 49852 – Where SDP sender is listening for this media – Set to 0: Disable entire Media Block (cannot remove it) Protocol – m= …, 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)

8. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 8 SDP Primer (continued) Format – m=, 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 – 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, is a set of RTP Payload Type numbers a=rtpmap: maps format to codec type a=fmtp: further details codec usage Recommended to keep same mapping in SDP Answer as in Offer

9. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 9 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

10. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 10 “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

11. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 11 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

12. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 12 WebRTC in SDP … One Encoding of a MediaStreamTrack source can in its simplest form be a single SSRC One Encoding specification can be re-used by several MediaStreamTrack sources One MediaStream typically contain MST from multiple Media Blocks A PeerConnection uses the SDP to describe its MS and MST Bundling Media Blocks on same transport necessitates making some Media Block-local attributes global, or at least aligned, across all bundled Media Blocks

13. Use Cases

14. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 14 B Sources WebRTC A Sources C Sources PeerConnection MediaStream Track PeerConnection MS MST PeerConnection MS MST One or more per transport Sources are represented as encodings Same MS can be transported by multiple PC Same source can have multiple encodings One or more per PerConnection One or more per MediaStream Same source can be used in multiple Tracks

15. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 15 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

16. “New” Functionalities in SDP

17. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 17 Multiple Sources Signaling RTP session with multiple sources of same media type – sent from a single endpoint – received by a single endpoint

18. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 18 Transport Aggregation Multiple protocols on same transport (UDP port) – STUN – DTLS-SRTP – DTLS/SCTP – (S)RTP Multiple media types in same RTP session

19. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 19 Simulcast and Scalability Multiple encodings of a single media source – Independent: Simulcast – Dependent: Scalable (or layered) encoding

20. Multiple RTP Streams in SDP A Fundamental Issue

21. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 21 SINGLE vs MULTIPLE SOURCES PER SDP m- line SINGLE SOURCE (SSRC) m=audio m=audio MULTIPLE SOURCES (SSRCs) m=audio

22. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 22 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

23. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 23 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

24. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 24 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

25. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 25 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

26. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 26 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

27. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 27 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?

28. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 28 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

29. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 29 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

30. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 30 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

31. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 31 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

32. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 32 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

33. February 5-7, 2013 RTCWEB / MMUSIC / W3C WebRTC Interim 33 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

34. Decision