[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        A. B. Roach
Internet-Draft                                                   Mozilla
Intended status: Informational                                M. Thomson
Expires: November 08, 2013                                     Microsoft
                                                            May 07, 2013


              Using SDP with Large Numbers of Media Flows
                      draft-roach-rtcweb-plan-a-00

Abstract

   A recurrent theme in WebRTC has been the need to handle very large
   numbers of media flows.  Unfortunately, naive uses of SDP do not
   handle this case particularly well.  This document describes a modest
   set of extensions to SDP which allow it to cleanly handle arbitrary
   numbers of flows while still retaining a large degree of backward
   compatibility with existing and non-RTCWEB endpoints.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 08, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Roach & Thomson        Expires November 08, 2013                [Page 1]


Internet-Draft               SDP Many Flows                     May 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Syntax Conventions  . . . . . . . . . . . . . . . . . . . . .   5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Detailed Description  . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Bundle-Only M-Lines . . . . . . . . . . . . . . . . . . .   7
     6.2.  Flow Demultiplexing . . . . . . . . . . . . . . . . . . .  10
     6.3.  Indicating Simulcast Groups . . . . . . . . . . . . . . .  11
     6.4.  Identifying Flows . . . . . . . . . . . . . . . . . . . .  11
     6.5.  Compatibility with Non-RTCWEB uses  . . . . . . . . . . .  11
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Simple example with one audio and one video . . . . . . .  12
     7.2.  Multiple Videos . . . . . . . . . . . . . . . . . . . . .  15
     7.3.  Many Videos . . . . . . . . . . . . . . . . . . . . . . .  17
     7.4.  Multiple Videos with Simulcast  . . . . . . . . . . . . .  18
     7.5.  Video with Simulcast and RTX  . . . . . . . . . . . . . .  20
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   A recurrent theme in WebRTC has been the need to cleanly handle very
   large numbers of media flows.  For instance, a video conferencing
   application might have a main display plus thumbnails for 10 or more
   other speakers all displayed at the same time.  If each video source
   is encoded in multiple resolutions (e.g., simulcast or layered
   coding) and also has FEC or RTX, this could easily add up to 30 or
   more independent RTP flows.

   The standard way of encoding this information in SDP is to have each
   RTP flow (i.e., SSRC) appear on its own m-line.  For instance, the
   SDP for two cameras with audio from a device with a public IP address
   could look something like:

   v=0
   o=- 20518 0 IN IP4 203.0.113.1
   s=



Roach & Thomson        Expires November 08, 2013                [Page 2]


Internet-Draft               SDP Many Flows                     May 2013


   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7

   m=audio 54400 RTP/SAVPF 0 96
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host

   m=video 55400 RTP/SAVPF 97 98
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=candidate:0 1 UDP 2113667327 203.0.113.1 55400 typ host
   a=candidate:1 2 UDP 2113667326 203.0.113.1 55401 typ host

   m=video 56400 RTP/SAVPF 99 100
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:100 VP8/90000
   a=sendrecv
   a=candidate:0 1 UDP 2113667327 203.0.113.1 56400 typ host
   a=candidate:1 2 UDP 2113667326 203.0.113.1 56401 typ host


   Unfortunately, as the number of independent media sources starts to
   increase, the scaling properties of this approach become problematic.
   In particular, SDP currently requires that each m-line have its own
   transport parameters (port, ICE candidates, etc.), which can get
   expensive.  For instance, the [RFC5245] pacing algorithm requires
   that new STUN transactions be started no more frequently than 20 ms;
   with 30 RTP flows, which would add 600 ms of latency for candidate
   gathering alone.  Moreover, having 30 persistent flows might lead to
   excessive consumption of NAT binding resources.

   A related issue is the number of payload types.  Even multiple
   sources are multiplexed over the same transport flow they must
   somehow be demultiplexed.  Consider the case where we want to be able
   to transmit 32 video thumbnails (this is large, but not insane).  In
   the model described above, each of these flows would need its own
   m-line and its own set of codecs.  If each side supports three



Roach & Thomson        Expires November 08, 2013                [Page 3]


Internet-Draft               SDP Many Flows                     May 2013


   separate codecs (e.g., H.263, H.264, VP8, and VP9), then we have just
   consumed 128 payload types, which exceeds the available dynamic
   payload space.  This makes demuxing on payload type problematic in
   some cases.

   This document specifies a small number of modest extensions to SDP
   which are intended to reduce the transport impact of using a large
   number of flows.  The general design philosophy is to maintain the
   existing SDP negotiation model while simply reducing the consumption
   of network resources.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [RFC2119].

   This draft uses the API and terminology described in [webrtc-api].

   5-tuple: A collection of the following values: source IP address,
   source transport port, destination IP address, destination transport
   port and transport protocol.

   Transport-Flow: An transport 5 Tuple representing the UDP source and
   destination IP address and port over which RTP is flowing.

   PC-Track: A source of media (audio and/or video) that is contained in
   a PC-Stream.  A PC-Track represents content comprising one or more
   PC-Channels.

   m-line: An SDP [RFC4566] media description identifier that starts
   with an "m=" field and conveys the following values: media type,
   transport port, transport protocol and media format descriptions.

   Offer: An [RFC3264] SDP message generated by the participant who
   wishes to initiate a multimedia communication session.  An Offer
   describes the participant's capabilities for engaging in a multimedia
   session.

   Answer: An [RFC3264] SDP message generated by the participant in
   response to an Offer.  An Answer describes the participant's
   capabilities in continuing with the multimedia session with in the
   constraints of the Offer.

   This draft avoids using terms that implementors do not have a clear
   idea of exactly what they are - for example RTP Session.





Roach & Thomson        Expires November 08, 2013                [Page 4]


Internet-Draft               SDP Many Flows                     May 2013


3.  Syntax Conventions

   The SDP examples given in this document deviate from actual on-the-
   wire SDP notation in several ways.  This is done to facilitate
   readability and to conform to the restrictions imposed by the RFC
   formatting rules.  These deviations are as follows:

   o  Any line that is indented (compared to the initial line in the SDP
      block) is a continuation of the preceding line.  The line break
      and indent are to be interpreted as a single space character.

   o  Empty lines in any SDP example are inserted to make functional
      divisions in the SDP clearer, and are not actually part of the SDP
      syntax.

   o  Excepting the above two conventions, line endings are to be
      interpreted as <CR><LF> pairs (that is, an ASCII 13 followed by an
      ASCII 10).

   o  Any text starting with the string "//" to the end of the line is
      inserted for the benefit of the reader, and is not actually part
      of the SDP syntax.

4.  Requirements

   This document is intended to address the following requirements,
   based on those from [I-D.jennings-mmusic-media-req].

   1.   Support many media flows but minimize the number of transport
        flows.

              This requirement is partly satisfied by BUNDLE
              [I-D.ietf-mmusic-sdp-bundle-negotiation]; however, BUNDLE
              still requires a large number of ports and ICE candidates
              in the initial offer.  This can create serious latency
              issues, as described in Section 1.  The mechanisms in
              Section Section 6.1 of this document address those issues.

   3.   Be able to successfully negotiate media with both legacy SIP
        devices and new devices (whether SIP or RTCWEB) with a single
        offer/answer exchange.  If both endpoints support multiplexed
        media, then multiplexing should be negotiated.  Otherwise, non-
        multiplexed media should be used.

              The interaction of this mechanism with non-WEBRTC devices
              is described in Section 6.5.





Roach & Thomson        Expires November 08, 2013                [Page 5]


Internet-Draft               SDP Many Flows                     May 2013


   5.   Provide a mechanism for harmonizing flow parameters for
        different m-lines when they are multiplexed over the same
        transport.

              [I-D.nandakumar-mmusic-sdp-mux-attributes] documents the
              required procedures.

   7.   Allow different sources (e.g., cameras) to use different codecs.
        For example, if one camera had hardware encoders for VP8 while
        another had encoders for H.264, the device may wish to negotiate
        different codecs.

              This requirement is also already satisfied by existing SDP
              mechanisms; we simply need to preserve them.

   9.   Be able to independently set parameters such as resolution and
        bandwidth, independently for each PC-Track, preferably even when
        they are all multiplexed over the same transport flow.

              Section 6.2 of this document satisfies the multiplexing
              requirement and the normal SDP mechanisms are used for
              parameters.

   11.  Be able to identify the PC-Tracks with an identifier that is
        stable over the duration of the session.

              Section 6.2 of this document explains track
              identification.

   Note that this document does not attempt to address the issue of
   adding a stream with little or no chance of glare.  See
   [I-D.roach-rtcweb-glareless-add] for the description of a technique
   that can be applied to any SDP offer/answer session establishment
   protocol to eliminate mid-session glare.

5.  Overview

   This section provides an overview of the approach specified in this
   document.

   o  We retain the existing SDP model that the m-line is the basic unit
      of media negotiation/representation.  Each independent unit (i.e.,
      a specific encoding of a PC-Track) is represented on its own
      m-line.

   o  BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to
      multiplex multiple m-lines (and their corresponding media) onto
      the same set of transport flows.



Roach & Thomson        Expires November 08, 2013                [Page 6]


Internet-Draft               SDP Many Flows                     May 2013


   o  Both RTP payload type (PT) and SSRC are used to de-multiplex flows
      multiplexed via bundle.  This allows for many more flows to be
      bundled than the limited number of PTs available.

   o  In order to minimize the number of transport parameters that need
      to be allocated during the gathering phase, m-lines can be tagged
      as "bundle only".  Such m-lines in an offer will be ignored by
      legacy endpoints but can be negotiated by endpoints that support
      the mechanisms specified in this document.

6.  Detailed Description

6.1.  Bundle-Only M-Lines

   As discussed in Section 1, even with bundle, it is expensive to
   allocate ICE candidates for a large number of m-lines.  An offer can
   contain "bundle-only" m-lines which will be negotiated only by
   endpoints which implement this specification and ignored by other
   endpoints.

   In order to offer such an m-line, the offerer does two things:

   o  Sets the port in the m-line to 0.  This indicates to old endpoints
      that the m-line is not to be negotiated.

   o  Adds an a=bundle-only line.  This indicates to new endpoints that
      the m-line is to be negotiated if (and only if) bundling is used.

   An example offer that uses this feature looks like this:

   v=0
   o=- 20518 0 IN IP4 203.0.113.1
   s=
   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7

   m=audio 54400 RTP/SAVPF 0 96
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host



Roach & Thomson        Expires November 08, 2013                [Page 7]


Internet-Draft               SDP Many Flows                     May 2013


   m=video 0 RTP/SAVPF 97 98
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only

   m=video 0 RTP/SAVPF 99 100
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:100 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only


   An old endpoint simply rejects the bundle-only m-lines by responding
   with a 0 port.  (This isn't a normative statement, just a description
   of the way the older endpoints are expected to act.)

   v=0
   o=- 20518 0 IN IP4 203.0.113.1
   s=
   t=0 0
   c=IN IP4 203.0.113.2
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7

   m=audio 55400 RTP/SAVPF 0 96
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host
   a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host

   m=video 0 RTP/SAVPF 97 98
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv

   m=video 0 RTP/SAVPF 99 100
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1



Roach & Thomson        Expires November 08, 2013                [Page 8]


Internet-Draft               SDP Many Flows                     May 2013


   a=rtpmap:100 VP8/90000
   a=sendrecv


   A new endpoint accepts the m-lines (both bundle-only and regular) by
   offering m-lines with a valid port, though this port may be
   duplicated as specified in Section 6 of
   [I-D.ietf-mmusic-sdp-bundle-negotiation].  For instance:

   v=0
   o=- 20518 0 IN IP4 203.0.113.2
   s=
   t=0 0
   c=IN IP4 203.0.113.2
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7

   m=audio 55400 RTP/SAVPF 0 96
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host

   m=video 55400 RTP/SAVPF 97 98
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only

   m=video 55400 RTP/SAVPF 99 100
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:100 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only


   Endpoints MUST NOT accept bundle-only m-lines if they are not part of
   an accepted bundle group.





Roach & Thomson        Expires November 08, 2013                [Page 9]


Internet-Draft               SDP Many Flows                     May 2013


6.2.  Flow Demultiplexing

   As noted above, if a large number of m-lines are used and each codec
   in each m-line uses its own PT, it is possible to exceed the number
   of possible PT values.  This makes PT-only demultiplexing
   insufficient in some cases.

   Offerers conformant to this specification MUST do one of the
   following:

   o  Use non-overlapping PT values for each m-line in any given bundle
      group.

   o  Provide distinct a=ssrc attributes for each m-line which uses
      overlapping PT values with any other m-line.  [Technically, this
      is a general case of the previous point.]

   If the offerer uses overlapping PT values for any two m-lines in a
   given bundle group, the answerer MUST supply distinct a=ssrc
   attributes for those m-lines.

   Upon receipt of an RTP datagram on a port that is being used with
   multiplexing, implementors SHOULD follow a procedure equivalent to
   the following to demultiplex streams:

   o  If the SSRC in the received packet matches one that has been
      mapped to an m-line (e.g., via a=ssrc attributes), then the packet
      corresponds to that m-line.

   o  If the SSRC in the received packet does not matches one that has
      associated with an m-line, but the PT value appears on only one
      m-line, then the packet corresponds to the m-line containing that
      PT.

   o  Otherwise, discard the packet.

   Note that this approach means that if PT values overlap between two
   m-lines, then those m-lines cannot be demultiplexed prior to
   receiving the m-line-to-ssrc mapping (e.g., in the SDP answer).  For
   instance, if the offerer wants two m-lines to be rendered prior to
   receipt of the SDP answer, it can use non-overlapping PT values on
   those m-lines.









Roach & Thomson        Expires November 08, 2013               [Page 10]


Internet-Draft               SDP Many Flows                     May 2013


6.3.  Indicating Simulcast Groups

   Simulcast refers to taking a single capture (e.g., a camera), and
   encoding it multiple times at different resolutions and / or frame
   rates.  For example, a device with a single HD camera may send one
   version of the video at full HD resolution, and a second version
   encoded at a low resolution.  This would allow a video conferencing
   bridge to be able to send the high resolution copy to some
   destination and low resolution copy to other destinations without
   having to recode the video at the conference bridge.

   This document proposes that simulcast be done by defining a new SDP
   group [RFC5888] called SIMULCAST.  Any m-lines that are in the same
   SIMULCAST group are alternative encodings of the same media capture.

   One of the advantages of this approach is it works well with the many
   existing RTP definitions that have been done in the past as well as
   others that may be done in the future.

   The order of m-lines in a SIMULCAST group determines the relative
   size of the encoded streams.  Streams at lower quality appear before
   streams of higher quality.  The entity creating the session
   description can choose to order m-lines based on any quality criteria
   (resolution, framerate, sample rate), but they SHOULD choose an
   ordering that places streams with a lower average bitrate before
   higher bitrate streams.

   Providing an order to SIMULCAST groupings allows an intermediary
   (such as a Media Translator [RFC5117]) to be able to select an
   appropriate SIMULCAST layer without inspecting the media stream,
   which could otherwise require decrypting and possibly partially
   decoding media packets.

6.4.  Identifying Flows

   While this topic is largely out of scope for SDP, the SSRC value can
   be used as a flow identifier.  One minor caveat with this approach is
   the ability to deal with the SSRC collision resolution procedure
   described in section 8.2 of [RFC3550].  In the rare circumstances
   that such an SSRC change is required, then any party that has changed
   its SSRC needs to inform the remote participants of the updated
   mapping, e.g.  via a new SDP offer.  In WebRTC use cases, this would
   trigger an onrennegotiationneeded event.

6.5.  Compatibility with Non-RTCWEB uses

   Due to the fact that this approach re-uses existing SDP constructs
   for indicating parameters in a media section, it remains compatible



Roach & Thomson        Expires November 08, 2013               [Page 11]


Internet-Draft               SDP Many Flows                     May 2013


   with non-RTCWEB clients.  Of particular note is the handling of
   "bundle-only" media sections, described in Section 6.1.  Offers
   generated by an RTCWEB client and sent to a non-RTCWEB client will
   simply negotiate those media the RTCWEB client did not use the
   "bundle-only" extension with.  This allows RTCWEB clients to select
   which media streams are important for interoperability with non-
   RTCWEB clients (by not making them bundle-only), and which ones are
   not.  Offers generated by non-RTCWEB clients will simply omit any
   bundle-related attributes, and the RTCWEB client will be able to
   process the SDP otherwise identically to the SDP received from RTCWEB
   clients: each m-line represents a different media stream, and
   contains a description of that stream in a syntax identical to the
   syntax used between RTCWEB clients.

   With the bundle-only approach, only those streams that are "important
   for interoperability" will require allocation of ports and ICE
   exchanges.  By doing so, working with non-multiplexing clients is
   enabled without requiring excess resource allocation for those
   streams that are not critical for proper user experience.

   Aside from BUNDLE, the bundle-only mechanism, and the rules around
   port demultiplexing, this proposal requires no additional extensions
   to SDP or the offer/answer model.

7.  Examples

   In all of these examples, there are many lines that are wrapped due
   to column width limitation.  It should be understood these lines are
   not wrapped in the real SDP.

   The convention used for IP addresses in this drafts is that private
   IP behind a NAT come from 192.0.2.0/24, the public side of a NAT
   comes from 198.51.100.0/24 and the TURN servers have addresses from
   203.0.113.0/24.  Typically the offer has an IP ending in .1 and the
   answer has an IP ending in .2.

   The examples do not include all the parts of SDP that are used in
   RTCWeb (See [I-D.ietf-rtcweb-rtp-usage]) as that makes the example
   unwieldy to read but instead focuses on showing the parts that are
   key for the multiplexing.

7.1.  Simple example with one audio and one video

   The following SDP shows an offer that offers one audio stream and one
   video steam with both a STUN and TURN address.

   v=0
   o=- 20518 0 IN IP4 198.51.100.1



Roach & Thomson        Expires November 08, 2013               [Page 12]


Internet-Draft               SDP Many Flows                     May 2013


   s=
   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:074c6550
   a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068
   a=fingerprint:sha-1
           99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:07
   a=group:BUNDLE m1 m2

   m=audio 56600 RTP/SAVPF 0 109
   a=mid:m1
   a=rtpmap:0 PCMU/8000
   a=rtpmap:109 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
   a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
           192.0.2.1 rport 54401
   a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
           192.0.2.1 rport 54401

   m=video 56602 RTP/SAVPF 99 120
   a=mid:m2
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:120 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=candidate:3 1 UDP 2113667327 192.0.2.1 54402 typ host
   a=candidate:4 2 UDP 2113667326 192.0.2.1 54403 typ host
   a=candidate:3 1 UDP 694302207 198.51.100.1 55502 typ srflx raddr
           192.0.2.1 rport 54402
   a=candidate:4 2 UDP 169430220 198.51.100.1 55503 typ srflx raddr
           192.0.2.1 rport 54403
   a=candidate:3 1 UDP 73545215 203.0.113.1 56602 typ relay raddr
           192.0.2.1 rport 54402
   a=candidate:4 2 UDP 51989708 203.0.113.1 56603 typ relay raddr
           192.0.2.1 rport 54403


   The following shows and answer to the above offer from a device that
   does not support bundle or rtcp-mux.



Roach & Thomson        Expires November 08, 2013               [Page 13]


Internet-Draft               SDP Many Flows                     May 2013


   v=0
   o=- 16833 0 IN IP4 198.51.100.2
   s=
   t=0 0
   c=IN IP4 203.0.113.2
   a=ice-ufrag:c300d85b
   a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2
   a=fingerprint:sha-1
           91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03

   m=audio 60600 RTP/SAVPF 109
   a=rtpmap:109 opus/48000
   a=ptime:20
   a=sendrecv
   a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host
   a=candidate:1 2 UDP 2113667326 192.0.2.2 60401 typ host
   a=candidate:0 1 UDP 1694302207 198.51.100.2 60500 typ srflx raddr
           192.0.2.2 rport 60400
   a=candidate:1 2 UDP 1694302206 198.51.100.2 60501 typ srflx raddr
           192.0.2.2 rport 60401
   a=candidate:0 1 UDP 73545215 203.0.113.2 60600 typ relay raddr
           192.0.2.1 rport 60400
   a=candidate:1 2 UDP 51989708 203.0.113.2 60601 typ relay raddr
           192.0.2.1 rport 60401

   m=video 60602 RTP/SAVPF 99
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=sendrecv
   a=candidate:2 1 UDP 2113667327 192.0.2.2 60402 typ host
   a=candidate:3 2 UDP 2113667326 192.0.2.2 60403 typ host
   a=candidate:2 1 UDP 694302207 198.51.100.2 60502 typ srflx raddr
           192.0.2.2 rport 60402
   a=candidate:3 2 UDP 169430220 198.51.100.2 60503 typ srflx raddr
           192.0.2.2 rport 60403
   a=candidate:2 1 UDP 73545215 203.0.113.2 60602 typ relay raddr
           192.0.2.2 rport 60402
   a=candidate:3 2 UDP 51989708 203.0.113.2 60603 typ relay raddr
           192.0.2.2 rport 60403


   The following shows and answer to the above offer from a device that
   does support bundle.

   v=0
   o=- 16833 0 IN IP4 198.51.100.2
   s=
   t=0 0



Roach & Thomson        Expires November 08, 2013               [Page 14]


Internet-Draft               SDP Many Flows                     May 2013


   c=IN IP4 203.0.113.2
   a=ice-ufrag:c300d85b
   a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2
   a=fingerprint:sha-1
           91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03

   m=audio 60600 RTP/SAVPF 109
   a=rtpmap:109 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host
   a=candidate:0 1 UDP 1694302207 198.51.100.2 60500 typ srflx raddr
           192.0.2.2 rport 60400
   a=candidate:0 1 UDP 73545215 203.0.113.2  60600 typ relay raddr
           192.0.2.1 rport 60400

   m=video 60600 RTP/SAVPF 99
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=sendrecv
   a=rtcp-mux
   a=candidate:3 1 UDP 2113667327 192.0.2.2 60400 typ host
   a=candidate:3 1 UDP 694302207 198.51.100.2 60500 typ srflx raddr
           192.0.2.2 rport 60400
   a=candidate:3 1 UDP 73545215 203.0.113.2  60600 typ relay raddr
           192.0.2.2 rport 60400


7.2.  Multiple Videos

   Simple example showing an offer with one audio stream and two video
   streams.

   v=0
   o=- 20518 0 IN IP4 198.51.100.1
   s=
   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
   a=group:BUNDLE m1 m2 m3

   m=audio 56600 RTP/SAVPF 0 96
   a=mid:m1
   a=rtpmap:0 PCMU/8000



Roach & Thomson        Expires November 08, 2013               [Page 15]


Internet-Draft               SDP Many Flows                     May 2013


   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
   a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
           192.0.2.1 rport 54401
   a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
           192.0.2.1 rport 54401

   m=video 56602 RTP/SAVPF 97 98
   a=mid:m2
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=candidate:2 1 UDP 2113667327 192.0.2.1 54402 typ host
   a=candidate:3 2 UDP 2113667326 192.0.2.1 54403 typ host
   a=candidate:2 1 UDP 694302207 198.51.100.1 55502 typ srflx raddr
           192.0.2.1 rport 54402
   a=candidate:3 2 UDP 169430220 198.51.100.1 55503 typ srflx raddr
           192.0.2.1 rport 54403
   a=candidate:2 1 UDP 73545215 203.0.113.1 56602 typ relay raddr
           192.0.2.1 rport 54402
   a=candidate:3 2 UDP 51989708 203.0.113.1 56603 typ relay raddr
           192.0.2.1 rport 54403
   a=ssrc:11111 cname:45:5f:fe:cb:81:e9

   m=video 56604 RTP/SAVPF 99 100
   a=mid:m3
   a=rtpmap:99 H264/90000
   a=fmtp:99 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:100 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=candidate:4 1 UDP 2113667327 192.0.2.1 54404 typ host
   a=candidate:5 2 UDP 2113667326 192.0.2.1 54405 typ host
   a=candidate:4 1 UDP 694302207 198.51.100.1 55504 typ srflx raddr
           192.0.2.1 rport 54404
   a=candidate:5 2 UDP 169430220 198.51.100.1 55505 typ srflx raddr
           192.0.2.1 rport 54405
   a=candidate:4 1 UDP 73545215 203.0.113.1 56604 typ relay raddr



Roach & Thomson        Expires November 08, 2013               [Page 16]


Internet-Draft               SDP Many Flows                     May 2013


           192.0.2.1 rport 54404
   a=candidate:5 2 UDP 51989708 203.0.113.1 56605 typ relay raddr
           192.0.2.1 rport 54405
   a=ssrc:22222 cname:45:5f:fe:cb:81:e9


7.3.  Many Videos

   This section adds three video streams and one audio.  The video
   streams are sent in such a way that they they are only accepted if
   the far side supports bundle using the "bundle only" approach
   described in Section 6.1.  The video streams also use the same
   payload types so it will not be possible to demux the video streams
   from each other without using the SSRC values.

   v=0
   o=- 20518 0 IN IP4 198.51.100.1
   s=
   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
   a=group:BUNDLE m0 m1 m2 m3

   m=audio 56600 RTP/SAVPF 0 96
   a=mid:m0
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
   a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
           192.0.2.1 rport 54401
   a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
           192.0.2.1 rport 54401

   m=video 0 RTP/SAVPF 97 98
   a=mid:m1
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1



Roach & Thomson        Expires November 08, 2013               [Page 17]


Internet-Draft               SDP Many Flows                     May 2013


   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:11111 cname:45:5f:fe:cb:81:e9

   m=video 0 RTP/SAVPF 97 98
   a=mid:m2
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:22222 cname:45:5f:fe:cb:81:e9

   m=video 0 RTP/SAVPF 97 98
   a=mid:m3
   a=rtpmap:97 H264/90000
   a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:333333 cname:45:5f:fe:cb:81:e9


7.4.  Multiple Videos with Simulcast

   This section shows an offer with with audio and two video each of
   which can send it two resolutions as described in Section 6.3.  Note
   that the grouping places the lower bitrate streams first, even though
   those appear first in the document.  All the video is bundle-only.

   v=0
   o=- 20518 0 IN IP4 198.51.100.1
   s=
   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
   a=group:BUNDLE m0 m1 m2 m3 m4

   a=group:SIMULCAST m2 m1
   a=group:SIMULCAST m4 m3




Roach & Thomson        Expires November 08, 2013               [Page 18]


Internet-Draft               SDP Many Flows                     May 2013


   m=audio 56600 RTP/SAVPF 0 96
   a=mid:m0
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
   a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
           192.0.2.1 rport 54401
   a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
           192.0.2.1 rport 54401

   m=video 0 RTP/SAVPF 98
   b=AS:1500
   a=mid:m1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:11111 cname:45:5f:fe:cb:81:e9
   a=framerate:30

   m=video 0 RTP/SAVPF 100
   b=AS:256
   a=mid:m2
   a=rtpmap:100 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:22222 cname:45:5f:fe:cb:81:e9
   a=framerate:15

   m=video 0 RTP/SAVPF 101
   b=AS:1500
   a=mid:m3
   a=rtpmap:101 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:333333 cname:45:5f:fe:cb:81:e9
   a=framerate:30




Roach & Thomson        Expires November 08, 2013               [Page 19]


Internet-Draft               SDP Many Flows                     May 2013


   m=video 0 RTP/SAVPF 103
   b=AS:256
   a=mid:m4
   a=rtpmap:103 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=ssrc:44444 cname:45:5f:fe:cb:81:e9
   a=framerate:15



7.5.  Video with Simulcast and RTX

   This section shows an SDP offer that has an audio and a single video
   stream.  The video stream that is simulcast at two resolutions and
   has [RFC4588] style re-transmission flows.

   v=0
   o=- 20518 0 IN IP4 198.51.100.1
   s=
   t=0 0
   c=IN IP4 203.0.113.1
   a=ice-ufrag:F7gI
   a=ice-pwd:x9cml/YzichV2+XlhiMu8g
   a=fingerprint:sha-1
           42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7
   a=group:BUNDLE m0 m1 m2 m3 m4

   a=group:SIMULCAST m2 m1
   a=group:FID m1 m3
   a=group:FID m2 m4

   m=audio 56600 RTP/SAVPF 0 96
   a=mid:m0
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 opus/48000
   a=ptime:20
   a=sendrecv
   a=rtcp-mux
   a=candidate:0 1 UDP 2113667327 192.0.2.1 54400 typ host
   a=candidate:1 2 UDP 2113667326 192.0.2.1 54401 typ host
   a=candidate:0 1 UDP 694302207 198.51.100.1 55500 typ srflx raddr
           192.0.2.1 rport 54400
   a=candidate:1 2 UDP 169430220 198.51.100.1 55501 typ srflx raddr
           192.0.2.1 rport 54401
   a=candidate:0 1 UDP 73545215 203.0.113.1 56600 typ relay raddr
           192.0.2.1 rport 54400



Roach & Thomson        Expires November 08, 2013               [Page 20]


Internet-Draft               SDP Many Flows                     May 2013


   a=candidate:1 2 UDP 51989708 203.0.113.1 56601 typ relay raddr
           192.0.2.1 rport 54401

   m=video 0 RTP/SAVPF 100 // This is the high res video
   b=AS:1500
   a=mid:m1
   a=rtpmap:98 VP8/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=framerate:30

   m=video 0 RTP/SAVPF 101  // This is the low res video
   b=AS:256
   a=mid:m2
   a=rtpmap:100 VP8/90000
   a=sendonly
   a=rtcp-mux
   a=bundle-only
   a=framerate:15

   m=video 0 RTP/SAVPF 110  // This is the retransmission of high res
   b=AS:1500
   a=mid:m3
   a=rtpmap:101 rtx/90000
   a=sendrecv
   a=rtcp-mux
   a=bundle-only
   a=framerate:30
   a=rtcp-fb:101 nack
   a=fmtp:101 apt=100;rtx-time=3000

   m=video 0 RTP/SAVPF 111  // This is retransmission of low res
   b=AS:256
   a=mid:m4
   a=rtpmap:103 rtx/90000
   a=sendonly
   a=rtcp-mux
   a=bundle-only
   a=framerate:15
   a=rtcp-fb:111 nack
   a=fmtp:11 apt=101;rtx-time=3000



8.  Security Considerations

   TBD



Roach & Thomson        Expires November 08, 2013               [Page 21]


Internet-Draft               SDP Many Flows                     May 2013


9.  IANA Considerations

   TBD: registration of SIMULCAST group

10.  Acknowledgements

   Thanks to Cullen Jennings for his assistance in generating the SDP
   examples in this document.

   Some of the material in this document was taken from
   [I-D.jennings-rtcweb-plan].

11.  References

11.1.  Normative References

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Multiplexing Negotiation Using Session Description
              Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
              bundle-negotiation-03 (work in progress), February 2013.

   [I-D.jennings-mmusic-media-req]
              Jennings, C., Uberti, J., and E. Rescorla, "Requirements
              from various WG for MMUSIC", draft-jennings-mmusic-media-
              req-00 (work in progress), February 2013.

   [I-D.nandakumar-mmusic-sdp-mux-attributes]
              Nandakumar, S., "A Framework for SDP Attributes when
              Multiplexing", draft-nandakumar-mmusic-sdp-mux-
              attributes-02 (work in progress), April 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June
              2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

11.2.  Informative References

   [I-D.ietf-rtcweb-rtp-usage]



Roach & Thomson        Expires November 08, 2013               [Page 22]


Internet-Draft               SDP Many Flows                     May 2013


              Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
              Communication (WebRTC): Media Transport and Use of RTP",
              draft-ietf-rtcweb-rtp-usage-06 (work in progress),
              February 2013.

   [I-D.jennings-rtcweb-plan]
              Jennings, C., "Proposed Plan for Usage of SDP and RTP",
              draft-jennings-rtcweb-plan-01 (work in progress), February
              2013.

   [I-D.roach-rtcweb-glareless-add]
              Roach, A. B., "An Approach for Adding RTCWEB Media Streams
              without Glare ", May 2013.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [webrtc-api]
              Bergkvist, Burnett, Jennings, Narayanan, , "WebRTC 1.0:
              Real-time Communication Between Browsers", October 2011.

              Available at http://dev.w3.org/2011/webrtc/editor/
              webrtc.html

Authors' Addresses

   Adam Roach
   Mozilla
   Dallas, TX
   US

   Phone: +1 650 903 0800 x863
   Email: adam@nostrum.com





Roach & Thomson        Expires November 08, 2013               [Page 23]


Internet-Draft               SDP Many Flows                     May 2013


   Martin Thomson
   Microsoft
   3210 Porter Drive
   Palo Alto, CA  94304
   US

   Phone: +1 650 353 1925
   Email: martin.thomson@skype.net










































Roach & Thomson        Expires November 08, 2013               [Page 24]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/