introduction to sdp issues. content background goals sdp primer rtp primer use cases “new”...

Introduction to SDP Issues

RTCWEB / MMUSIC / W3C WebRTC Interim

Content

• Background• Goals• SDP Primer• RTP Primer• Use cases• “New” Functionalities in SDP• Multiple RTP Streams in SDP• Decision

February 5-7, 2013 2

RTCWEB / MMUSIC / W3C WebRTC InterimFebruary 5-7, 2013 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


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

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


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)


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


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


“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


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


WebRTC in SDP<Session-wide part>

<Media Block 1><SSRC-specific attributes><Format-specific attributes>

<Media Block 2>

<Media Block 3>

…

<Media Block n>

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

Use Cases


BSources

WebRTC

ASources

CSources

PeerConnectionMediaStreamTrack

PeerC

onne

ctio

n

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


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

“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


Transport Aggregation

• Multiple protocols on same transport(UDP port)– STUN– DTLS-SRTP– DTLS/SCTP– (S)RTP

• Multiple media types in same RTP session


Simulcast and Scalability

• Multiple encodings of a single media source– Independent: Simulcast– Dependent: Scalable (or layered) encoding

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>


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


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


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


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



• 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



• 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?


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


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


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


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


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


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

Decision

introduction to sdp issues. content background goals sdp primer rtp primer use cases “new”...

Documents

sdp primer slide

sdp primer media block

sender of sdp

sdp sender

rtp media stream slide

rtp primer rtp session

sdp issues

sdp decision