1 / 34

Introduction to SDP Issues

Introduction to SDP Issues. Content. Background Goals SDP Primer RTP Primer Use cases “New” Functionalities in SDP Multiple RTP Streams in SDP Decision. Background. New applications and usages WebRTC / RTCWEB Telepresence / CLUE Existing advanced applications Group communication

lori
Download Presentation

Introduction to SDP Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 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 RTCWEB / MMUSIC / W3C WebRTC Interim

  5. SDP Primer

  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 whatsender 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 RTCWEB / MMUSIC / W3C WebRTC Interim

  7. 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) RTCWEB / MMUSIC / W3C WebRTC Interim

  8. 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 mappingin SDP Answer as in Offer 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 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 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 RTCWEB / MMUSIC / W3C WebRTC Interim

  12. 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> … <Media Block n> One Encoding specification can be re-used by several MediaStreamTrack sources One MediaStream typically contain MST from multiple Media Blocks Bundling Media Blocks on same transport necessitates making some Media Block-local attributes global, or at least aligned, across all bundled Media Blocks A PeerConnection uses the SDP to describe its MS and MST RTCWEB / MMUSIC / W3C WebRTC Interim

  13. Use Cases

  14. PeerConnection MediaStream Track PeerConnection PeerConnection MS MS MST MST WebRTC One or more per PerConnection One or more per transport ASources BSources One or more per MediaStream Same MS can be transported by multiple PC Same source can be used in multiple Tracks CSources Sources are represented as encodings Same source can have multiple encodings 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 RTCWEB / MMUSIC / W3C WebRTC Interim

  16. “New” Functionalities in SDP

  17. Multiple Sources • Signaling RTP session with multiple sources of same media type • sent from a single endpoint • received by a single endpoint 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 RTCWEB / MMUSIC / W3C WebRTC Interim

  19. Simulcast and Scalability • Multiple encodings of a single media source • Independent: Simulcast • Dependent: Scalable (or layered) encoding RTCWEB / MMUSIC / W3C WebRTC Interim

  20. Multiple RTP Streams in SDP A Fundamental Issue

  21. 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> 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 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 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 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 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 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? 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 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 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 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 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 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 RTCWEB / MMUSIC / W3C WebRTC Interim

  34. Decision

More Related