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