Annotated Example SDP for WebRTC
draft-ietf-rtcweb-sdp-11

Abstract

The Real-Time Communications in WEB-browsers (Rtcweb) working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the Rtcweb framework, Session Description protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism.

This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common Rtcweb use-cases.

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 https://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 April 11, 2019.

Copyright Notice

Copyright (c) 2018 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 (https://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. SDP and the WebRTC
• 4. Offer/Answer and the WebRTC
• 5. WebRTC Session Description Examples
• 5.1. Some Conventions
• 5.2. Basic Examples
• 5.2.1. Audio Only Session
• 5.2.2. Audio/Video Session
• 5.2.2.1. IPv4 audio/video session
• 5.2.2.2. Dual Stack audio/video session
• 5.2.3. Data Only Session
• 5.2.4. Audio Call On Hold
• 5.2.5. Audio with DTMF Session
• 5.2.6. One Way Audio/Video Session - Document Camera
• 5.2.7. Audio, Video Session with BUNDLE Support Unknown
• 5.2.8. Audio, Video and Data Session
• 5.2.9. Audio, Video Session with BUNDLE Unsupported
• 5.2.10. Audio, Video BUNDLED, but Data (Not BUNDLED)
• 5.2.11. Audio Only, Add Video to BUNDLE
• 5.3. MultiResolution, RTX, FEC Examples
• 5.3.1. Sendonly Simulcast Session with 2 cameras and 2 encodings per camera
• 5.3.2. Successful SVC Video Session
• 5.3.3. Successful Simulcast Video Session with Retransmission
• 5.3.4. Successful 1-way Simulcast Session with 2 resolutions and RTX - One resolution rejected
• 5.3.5. Simulcast Video Session with Forward Error Correction
• 5.4. Others
• 5.4.1. Audio Session - Voice Activity Detection
• 5.4.2. Audio Conference - Voice Activity Detection
• 5.4.3. Successful legacy Interop Fallback with bundle-only
• 5.4.4. Legacy Interop with RTP/AVP profile
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgments
• 9. Change Log
• 10. Informative References
• Appendix A. Appendix
• A.1. JSEP SDP Attributes Checklist
• A.1.1. Common Checklist
• A.1.2. RTP Media Description Checklist
• A.1.3. DataChannel Media Description checklist
• Authors' Addresses

1. Introduction

Javascript Session Establishment Protocol(JSEP) [I-D.ietf-rtcweb-jsep] specifies a generic protocol needed to generate [RFC3264] Offers and Answers negotiated between the [WebRTC] peers for setting up, updating and tearing down a WebRTC session. For this purpose, SDP is used to construct [RFC3264] Offers/Answers for describing (media and non-media) streams as appropriate for the recipients of the session description to participate in the session.

The remainder of this document is organized as follows: Sections 3 and 4 provides an overview of SDP and the Offer/Answer exchange mechanism. Section 5 provides sample SDP generated for the most common WebRTC use-cases.

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

Readers should be familiar with the terminology defined in [RFC3264] and in [RFC7656].

3. SDP and the WebRTC

The purpose of this section is to provide a general overview of SDP and its components. For a more in-depth understanding, the readers are advised to refer to [RFC4566].

The Session Description Protocol (SDP) [RFC4566] describes multimedia sessions, which can contain audio, video, whiteboard, fax, modem, and other streams. SDP provides a general purpose, standard representation to describe various aspects of multimedia session such as media capabilities, transport addresses and related metadata in a transport agnostic manner, for the purposes of session announcement, session invitation and parameter negotiation.

As of today SDP is widely used in the context of Session Initiation Protocol [RFC3261], Real-time Transport Protocol [RFC3550] and Real-time Streaming Protocol applications [RFC7826].

Below figure introduces high-level breakup of SDP into components that semantically describe a multimedia session, in our case, a WebRTC session [WebRTC]. It by no means captures everything about SDP and hence, should be used for informational purposes only.

                                                +---------------------+
                                                |        v=           |
                                                +---------------------+
                +---------------------+         +---------------------+
        ====    |   Session Metadata  |  =====  |        o=           |
        |       +---------------------+         +----------------------
        |                                       +---------------------+
        |                                       |        t=           |
        |                                       +---------------------+
        |
        |
        |                                       +---------------------+
        |                                       |        c=           |
        |                                       +---------------------+
        |       +---------------------+
        ====    | Network Description |   =====
        |       +---------------------+
        |                                       +---------------------+
        |                                       |    a=candidate      |
        |                                       +---------------------+
        |
        |
        |                                       +---------------------+
        |                                       |        m=           |
        |                                       +---------------------+
        |        +---------------------+        +---------------------+
        ====     | Stream Description  |  ===== |      a=rtpmap       |
        |        +---------------------+        +----------------------
        |                                       +---------------------+
        |                                       |      a=fmtp         |
        |                                       +---------------------+
        |                                       +---------------------+
        |                                       |      a=sendrecv..   |
        |                                       +---------------------+
+---------------+
|    SEMANTIC   |
| COMPONENTS OF |
|     SDP       |
+---------------+
        |                                       +---------------------+
        |                                       |      a=crypto       |
        |                                       +---------------------+
        |         +---------------------+       +---------------------+
        ====      |Security Descriptions|  =====|      a=ice-frag     |
        |         +---------------------+       +----------------------
        |                                       +---------------------+
        |                                       |      a=ice-pwd      |
        |                                       +---------------------+
        |                                       +---------------------+
        |                                       |     a=fingerprint   |
        |                                       +---------------------+
        |
        |
        |
        |                                       +---------------------+
        |                                       |      a=rtcp-fb      |
        |                                       +---------------------+
        |         +---------------------+       +---------------------+
        ====      |   Qos,Grouping      |       |                     |
                  |   Descriptions      |  =====|       a=group       |
                  +---------------------+       +----------------------
                                                +---------------------+
                                                |       a=rtcpmux     |
                                                +---------------------+




          

Figure 1: Semantic Components of SDP

[WebRTC] proposes JavaScript application to fully specify and control the signaling plane of a multimedia session as described in the JSEP specification [I-D.ietf-rtcweb-jsep]. JSEP provides mechanisms to create session characterization and media definition information to conduct the session based on SDP exchanges.

In this context, SDP serves two purposes:

1. Provide grammatical structure syntactically.
2. Semantically convey participant's intention and capabilities required to successfully negotiate a session.

4. Offer/Answer and the WebRTC

This section introduces SDP Offer/Answer Exchange mechanism mandated by WebRTC for negotiating session capabilities while setting up, updating and tearing down a WebRTC session. This section is intentionally brief in nature and interested readers are recommended to refer [RFC3264] for specific details on the protocol operation.

The Offer/Answer [RFC3264] model specifies rule for the bilateral exchange of Session Description Protocol (SDP) messages for creation of multimedia streams. It defines protocol with involved participants exchanging desired session characteristics from each others perspective constructed as SDP to negotiate the session between them.

In the most basic form,the protocol operation begins by one of the participants sending an initial SDP Offer describing its intent to start a multimedia communication session. The participant receiving the offer MAY generate an SDP Answer accepting the offer or it MAY reject the offer. If the session is accepted the Offer/Answer model guarantees a common view of the multimedia session between the participants.

At any time, either participant MAY generate a new SDP offer that updates the session in progress.

With in the context of WebRTC, the Offer/Answer model defines the state-machinery for WebRTC peers to negotiate session descriptions between them during the initial setup stages as well as for eventual session updates. JSEP specification [I-D.ietf-rtcweb-jsep] for WebRTC provides the mechanism for generating [RFC3264] SDP Offers and Answers in order for both sides of the session to agree upon the details such as the list of media formats to be sent/received, bandwidth information, crypto parameters, transport parameters, for example.

5. WebRTC Session Description Examples

A typical web based real-time multimedia communication session can be characterized as below:

• It has zero or more Audio only, Video only or Audio/Video RTP Sessions,
• MAY contain zero or more non-media data sessions,
• All the sessions are secured with DTLS-SRTP,
• Supports NAT traversal using ICE mechanism,
• Provides RTCP based feedback mechanisms,
• Sessions can be over IPv4-only, IPv6-only, dual-stack based clients,
• Supports BUNDLE based grouping of media streams over a single 5-tuple transport.

5.1. Some Conventions

The examples given in this document follow the conventions listed below:

• In all the examples, Alice and Bob are assumed to be the WebRTC peers.
• It is assumed that for most of the examples, the support for [I-D.ietf-mmusic-sdp-bundle-negotiation] is established apriori either out-of-band or as a consequence of successful Offer/Answer negotiation between Alice and Bob, unless explicitly stated otherwise.
• Call-flow diagrams that accompany the use-cases capture only the prominent aspects of the system behavior and intentionally is not detailed to improve readability.
• Eventhough the call-flow diagrams shows SDP being exchanged between the parties, it doesn't represent the only way an WebRTC setup is expected to work. Other approaches may involve WebRTC applications to exchange the media setup information via non-SDP mechanisms as long as they confirm to the [I-D.ietf-rtcweb-jsep] API specification.
• The SDP examples 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.
  • Visual markers/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.
  • Any SDP 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.
  • 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).

• Against each SDP line, pointers to the appropriate RFCs are provided for further informational reference. Also an attempt has been made to provide explanatory notes to enable better understanding of the SDP usage, wherever appropriate.
• Following SDP details are common across all the use-cases defined in this document unless mentioned otherwise.
  • DTLS fingerprint for SRTP (a=fingerprint)
  • RTP/RTCP Multiplexing (a=rtcp-mux)
  • RTCP Feedback support (a=rtcp-fb)
  • Host and server-reflexive candidate lines (a=candidate)
  • SRTP Setup framework parameters (a=setup)
  • RTCP attribute (a=rtcp)
  • RTP header extension indicating audio-levels from client to the mixer

  For specific details, readers must refer to

  [I-D.ietf-rtcweb-jsep] specification.
• The term "Session" is used rather loosely in this document to refer to either a "Communication Session" or a "RTP Session" or a "RTP Stream" depending on the context.
• Payload type 109 is usually used for OPUS, 0 for PCMU, 8 for PCMA, 99 for H.264 and 120 for VP8 in most of the examples to maintain uniformity.
• The IP Address:Port combinations '192.0.2.4:61665' (host) and '203.0.113.141:54609' (Server Reflexive) is typically used for Alice.
• The IP Address:Port combinations '198.51.100.7:51556' (host) and '203.0.113.77:49203' (Server Reflexive) is typically used for Bob.
• The IPv6 addresses 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9 and 2001:DB8:30c:1266:5916:3779:22f6:77f7 are used to represent Alice and Bob host addresses respectively.
• In the actual use the values that represent SSRCs, ICE candidate foundations, WebRTC Mediastream, MediaStreamTrack Ids values shall be much larger and/or random than the ones shown in the examples.
• tls-id attribute values 89J2LRATQ3ULA24G9AHWVR31VJWSLB68 and UKA29UQLTF69OJW4WNPNUO2Y0GF1FJOZ are used for Alice. The values CJ6FF9ZZMJW7MDRJIR7XVIQM48GE1G31 and 9AIFS8AQ009IXF5D6QQUJ7P8BXPEZJ8G are used for Bob.
• identity attribute values are split across multiple lines to enhance readability, thus any line breaks and indentations in the value must be ignored.
• SDP attributes in the examples closely follow the checklist defined in section Appendix A.1.

5.2. Basic Examples

5.2.1. Audio Only Session

This common scenario shows SDP for secure two-way audio session with Alice offering Opus, PCMU, PCMA and Bob accepting all the offered audio codecs.

This example also shows the endpoints being [RFC8445] compliant by including "ice2" ice-options attribute.

        2-Way Audio Only Session

Alice                                Bob
|                                     |
|                                     |
|    Offer(Audio:Opus,PCMU,PCMA)      |
|------------------------------------>|
|                                     |
|                                     |
|   Answer(Audio:Opus,PCMU,PCMA)      |
|<------------------------------------|
|                                     |
|                                     |
|Two-way Opus Audio (preferred-codec) |
|.....................................|
|                                     |
|                                     |

5.2.2. Audio/Video Session

Alice and Bob establish a two-way audio and video session with Opus as the audio codec and H.264 as the video codec.

         2-Way Audio,Video Session

Alice                                       Bob
|                                            |
|                                            |
|Offer(Audio:Opus,PCMU,PCMA Video:H.264,VP8) |
|------------------------------------------->|
|                                            |
|                                            |
|      Answer(Audio:Opus,Video:H.264)        |
|<-------------------------------------------|
|                                            |
|                                            |
|     Two-way Opus Audio, H.264 Video        |
|............................................|
|                                            |

5.2.2.1. IPv4 audio/video session

This section shows the IPv4 only Offer/Answer exchange.

5.2.2.2. Dual Stack audio/video session

This section captures offer/answer exchange when Alice and Bob support both IPv4 and IPv6 host addresses.

5.2.3. Data Only Session

This scenario illustrates the SDP negotiated to setup a data-only session based on the SCTP Data Channel, thus enabling use-cases such as file-transfer, real-time game control for example.

      2-Way DataChannel Session

Alice                            Bob
|                                 |
|                                 |
|                                 |
|      Offer(DataChannel)         |
|-------------------------------->|
|                                 |
|                                 |
|      Answer(DataChannel)        |
|<--------------------------------|
|                                 |
|                                 |
| Two-way SCTP based DataChannel  |
|.................................|
|                                 |
|                                 |

5.2.4. Audio Call On Hold

Alice calls Bob, but when Bob answers he places Alice on hold by setting the SDP direction attribute to a=inactive in the Answer.

           Audio On Hold

Alice                            Bob
|                                 |
|                                 |
|      Offer(Audio:Opus)          |
|-------------------------------->|
|                                 |
|                                 |
|  Answer(Audio:Opus,a=inactive)  |
|<--------------------------------|
|                                 |
|                                 |
|      One-way Opus Audio         |
|.................................|
|                                 |
|

5.2.5. Audio with DTMF Session

In this example, Alice wishes to establish two separate audio streams, one for normal audio and the other for telephone-events. Alice offers first audio stream with three codecs and the other with [RFC4733] tones (for DTMF). Bob accepts both the audio streams by choosing Opus as the audio codec and telephone-event for the other stream.

            Audio Session with DTMF

Alice                                              Bob
|                                                   |
|                                                   |
|                                                   |
|  Offer(Audio:Opus,PCMU,PCMA Audio:telephone-event)|
|-------------------------------------------------->|
|                                                   |
|                                                   |
|    Answer(Audio:Opus, Audio:telephone-event)      |
|<--------------------------------------------------|
|                                                   |
|                                                   |
|   Opus audio stream and telephone-event stream    |
|...................................................|
|                                                   |
            

5.2.6. One Way Audio/Video Session - Document Camera

In this scenario Alice and Bob engage in a 1 way audio and video session with Bob receiving Alice's audio and her presentation slides as video stream.

   One Way Audio & Video Session - Document Camera


Alice                                                 Bob
|                                                      |
|                                                      |
|                                                      |
|   Alice Offers sendonly audio and video streams.     |
|  The video stream corresponds to her presentation    |
|                                                      |
|           Offer(Audio:Opus, Video: VP8)              |
|----------------------------------------------------->|
|                                                      |
|                                                      |
|            (Audio:Opus, Video: VP8)                  |
|<-----------------------------------------------------|
|                                                      |
|                                                      |
|          One-way Opus Audio, VP8 Video               |
|......................................................|
|   Bob can hear Alice and see her presentation slides.|
|                                                      |
|                                                      |

5.2.7. Audio, Video Session with BUNDLE Support Unknown

In this example, since Alice is unsure of the Bob's support of the BUNDLE framework, following steps are performed in order to negotiate and setup a BUNDLE Address for the session

• An SDP Offer, in which the Alice assigns unique addresses to each "m=" line in the BUNDLE group, and requests the Answerer to select the Offerer's BUNDLE address.
• An SDP Answer, in which the Bob indicates its support for BUNDLE, selects the offerer's BUNDLE address, selects its own BUNDLE address and associates it with each BUNDLED m=line within the BUNDLE group.

Once the Offer/Answer exchange completes, both Alice and Bob each end up using single RTP Session for both the Media Streams.

 Two-Way Secure Audio,Video with BUNDLE support unknown

Alice                                                 Bob
|                                                      |
|                                                      |
|   Alice offers BUNDLE support with unique address    |
|        for the audio and video m-line                |
|                                                      |
|                                                      |
|          Offer(Audio:Opus Video:VP8)                 |
|----------------------------------------------------->|
|                                                      |Bob
|                                                      |supports
|                                                      |BUNDLE,
|                                                      |Uses
|                                                      |identical
|                                                      |address
|          Answer(Audio:Opus Video:VP8)                |
|<-----------------------------------------------------|
|                                                      |
|    2 Way Call with Audio and Video Multiplexed       |
|......................................................|
|                                                      |

5.2.8. Audio, Video and Data Session

This example shows SDP for negotiating a session with Audio, Video and data streams between Alice and Bob with BUNDLE support known.

    Audio,Video,Data with BUNDLE support known

Alice                                       Bob
|                                            |
|                                            |
|   Alice indicates BUNDLE support with      |
|  identical address across all the m=lines  |
|                                            |
|                                            |
|     Offer(Audio:Opus Video:VP8 Data)       |
|------------------------------------------->|
|                                            |Bob does
|                                            |the same
|    Answer(Audio:Opus,Video:VP8 Data)       |
|<-------------------------------------------|
|                                            |
|                                            |
|                                            |
|    Two-way Audio,Video, Data multiplexed   |
|............................................|
|                                            |
|                                            |

5.2.9. Audio, Video Session with BUNDLE Unsupported

This use-case illustrates SDP Offer/Answer exchange where the far-end (Bob) either doesn't support media bundling or doesn't want to group m=lines over a single 5-tuple.

The same is indicated by dropping the "a=group:BUNDLE" line and BUNDLE RTP header extension in the Answer SDP.

On successful Offer/Answer exchange, Alice and Bob each end up using unique 5-tuple for audio and video media streams respectively.

   Two-Way Secure Audio,Video with BUNDLE Unsupported

Alice                                                 Bob
|                                                      |
|                                                      |
|     Alice offers BUNDLE support with unique address  |
|           for the audio and video m-line             |
|                                                      |
|                                                      |
|           Offer(Audio:Opus Video:VP8)                |
|----------------------------------------------------->|
|                                                      |Bob
|                                                      |doesn't
|                                                      |support
|                                                      |BUNDLE
|           Answer(Audio:Opus Video:VP8)               |
|<-----------------------------------------------------|
|                                                      |Bob uses
|                                                      |unique
|                                                      |addresses
|                                                      |across the
|                                                      |m=lines
|                                                      |
|2Way Call with Audio and Video on different 5-tuples  |
|......................................................|
|                                                      |
|                                                      |

5.2.10. Audio, Video BUNDLED, but Data (Not BUNDLED)

This example show-cases SDP for negotiating a session with Audio, Video and data streams between Alice and Bob with data stream not being part of the BUNDLE group. This is shown by assigning unique port for data media section and not adding the "mid" identification tag to the BUNDLE group.

       Audio, Video, with Data (Not in BUNDLE)

Alice                                                 Bob
|                                                      |
|                                                      |
|Alice wants to multiplex audio, video but not data    |
|                                                      |
|                                                      |
|  Offer(Audio:Opus Video:VP8, Data(not in BUNDLE))    |
|----------------------------------------------------->|
|                                                      |
|                                                      |
|       Answer(Audio:Opus Video:VP8, Data)             |
|<-----------------------------------------------------|
|                                                      |
|                                                      |
|2 Way Call with Audio, Video Multiplexed except data  |
|......................................................|
|                                                      |

5.2.11. Audio Only, Add Video to BUNDLE

This example involves 2 Offer/Answer exchanges. First one is used to negotiate and setup BUNDLE support for Audio-only session followed by an updated Offer/Answer exchange to add video stream to the ongoing session. Also the newly added video stream is BUNDLED with the audio stream.

         Audio Only , Add Video and BUNDLE

Alice                                                 Bob
|                                                      |
|                                                      |
|        Alice indicates support for BUNDLE            |
|                                                      |
|                Offer(Audio:Opus)                     |
|----------------------------------------------------->|
|                                                      |Bob
|                                                      |supports
|                                                      |BUNDLE
|                Answer(Audio:Opus)                    |
|<-----------------------------------------------------|
|                                                      |Alice adds
|                                                      |video stream
|        Updated Offer(Audio:Opus, Video:VP8)          |to BUNDLE
|----------------------------------------------------->|
|                                                      |
|                                                      |Bob accepts
|        Updated Answer(Audio:Opus, Video:VP8)         |
|<-----------------------------------------------------|
|                                                      |
|   2Way Call with Audio and Video Multiplexed         |
|......................................................|
|                                                      |
|                                                      |

5.3. MultiResolution, RTX, FEC Examples

This section provides examples related to multi-source, multi-stream negotiation such as layered coding, simulcast. Further included are few examples that cover techniques to deal with providing robustness against transmission errors such as FEC and RTX. Also to note, mechanisms such as FEC and RTX could be envisioned in the above basic scenarios as well.

5.3.1. Sendonly Simulcast Session with 2 cameras and 2 encodings per camera

The SDP below shows Offer/Answer exchange with one audio and two video sources (say 2 video cameras). Each of the video source can be sent at two different resolutions.

One video source corresponds to VP8 encoding, while the other corresponds to H.264 encoding.

[I-D.ietf-mmusic-rid] framework is used to further constrain the media format encodings and map the payload types (PT) to the 'rid' identifiers.

[I-D.ietf-mmusic-sdp-simulcast] framework identifies the simulcast streams via their 'rid' identifiers.

bundle-only attribute is used for the video sources in the Offer to ensure enabling video sources in the context of BUNDLE alone.

BUNDLE grouping framework enables multiplexing of all the 5 Source RTP Streams (1 audio stream + 4 video streams) over a single RTP Session.

Also, the audio and one video source RTP stream form a lip sync group while the other video source RTP stream represents a non-interactive media data.

       1 Way Successful Simulcast w/BUNDLE

Alice                                            Bob
|                                                 |
|                                                 |
|     Alice offers 2 sendonly video sources       |
|     with 2 simulcast encodings per source       |
|           and bundle-only for video             |
|                                                 |
|                                                 |
|   Offer(Audio:Opus,Video1:VP8,Video2:H.264)     |
|------------------------------------------------>|
|                                                 |
|                                                 |
|    Answer(Audio:Opus Video1:VP8,Video2:H.264)   |
|<------------------------------------------------|
|                                                 |
|One-Way 1 Opus, 2 H.264 and 2 VP8 video streams, |
| all multiplexed                                 |
|.................................................|
|                                                 |
|                                                 |

5.3.2. Successful SVC Video Session

This section shows an SDP Offer/Answer for a session with an audio and a single video source. The video source being encoded both as non-scalable and scalable H.264-SVC RTP stream (in the SST mode).

The Answerer picks the payload type corresponding to scalable encoding.

        SVC Session - 3 Layers w/BUNDLE

Alice                                            Bob
|                                                 |
|                                                 |
|      Alice offers sendonly video stream         |
|      with non-scalable and scalable encodings.  |
|                                                 |
|                                                 |
|            Offer(Video:H.264/H.264-SVC)         |
|------------------------------------------------>|
|                                                 |
|                                                 |Bob accepts Alice's
|                                                 |offered Codec
|                                                 |operation points
|                                                 |
|             Answer(Video:H.264-SVC)             |
|<------------------------------------------------|
|                                                 |
|One-Way  H.264-SVC video streams                 |
|.................................................|
|                                                 |
|                                                 |

5.3.3. Successful Simulcast Video Session with Retransmission

This section shows an SDP Offer/Answer exchange for a simulcast scenario with 3 resolutions and has [RFC4588] style re-transmission flows.

[I-D.ietf-mmusic-rid] framework is used to specify all the (3) resolution constraints mapped to a single Payload Type (98).

[I-D.ietf-mmusic-sdp-simulcast] framework identifies the simulcast streams via their 'rid' identifiers.

        Simulcast Streams with Retransmission

Alice                                                    Bob
|                                                         |
|                                                         |
|Alice offers single audio and simulcasted video streams  |
|                                                         |
|                                                         |
|    Offer(Audio:Opus Video:VP8 with 3 resolutions)       |
|    & RTX stream                                         |
|-------------------------------------------------------->|
|                                                         |
|                                                         |
|          Answer (Bob accepts Alice's offer)             |
|<--------------------------------------------------------|
|                                                         |
|                                                         |
|One-Way 1 Opus, 3 VP8 and RTX video streams,all muxed    |
|.........................................................|
|                                                         |
|                                                         |

5.3.4. Successful 1-way Simulcast Session with 2 resolutions and RTX - One resolution rejected

This section shows an SDP Offer/Answer exchange for a simulcast scenario with 2 two resolutions.

It also showcases where Bob rejects one of the Simulcast Video Stream which results in the rejection of the associated repair stream implicitly.

     Simulcast Streams with Retransmission Rejected

Alice                                                    Bob
|                                                         |
|                                                         |
|Alice offers single audio and simulcasted video streams  |
| with bundle-only for video                              |
|                                                         |
|                                                         |
|Offer(Audio:Opus Video:VP8 with 2 resolutions,RTX Stream)|
|-------------------------------------------------------->|
|                                                         |
|                                                         |Bob accepts 1
|                                                         |simulcast,rtx
|                                                         |rejects the
|                                                         |other
|   Answer(Audio:Opus Video:VP8 with 1 res & RTX Stream)  |
|<--------------------------------------------------------|
|                                                         |
|                                                         |
|1-way audio,video session and its associated RTX stream, |
| all multiplexed                                         |
|.........................................................|
|                                                         |
|                                                         |

5.3.5. Simulcast Video Session with Forward Error Correction

This section shows an SDP Offer/Answer exchange for Simulcast video stream at two resolutions and and has [RFC5956] style FEC flows.

On completion of the Offer/Answer exchange mechanism we end up one audio stream, 2 simulcast video streams and 2 associated FEC streams are sent over a single 5-tuple.

      Simulcast Streams with Forward Error Correction

Alice                                                            Bob
|                                                               |
|                                                               |
|                                                               |
|Alice offers single audio and simulcasted video streams        |
|with bundle-only                                               |
|                                                               |
|                                                               |
|Offer(Audio:Opus Video:VP8 with 2 resolutions with FEC Streams)|
|-------------------------------------------------------------->|
|                                                               |
|                                                               |Bob
|                                                               |accepts
|                                                               |Alice's
|                                                               |offer
|Answer(Audio:Opus Video:VP8 with 2 resolutions w/FEC Streams)  |
|<--------------------------------------------------------------|
|                                                               |
|One-Way Audio,Video session with 4 video streams(Simulcast     |
| and FEC) all multiplexed                                      |
|...............................................................|
|                                                               |
|                                                               |
|                                                               |

5.4. Others

The examples in the section provide SDP Offer/Answer exchange for a variety of scenarios related to RTP Header extension for conference usages, Legacy Interop scenarios and more.

5.4.1. Audio Session - Voice Activity Detection

This example shows Alice indicating the support of the RTP header extension to include the audio-level of the audio sample carried in the RTP packet.

           2-Way Audio with VAD

 Alice                                    Bob
 |                                         |
 |                                         |
 |Alice indicates support for including    |
 |audio level in RTP header                |
 |                                         |
 |     Offer(Audio:Opus,PCMU,PCMA)         |
 |---------------------------------------->|
 |                                         |
 |                                         |
 |     Answer(Audio:Opus,PCMU,PCMA)        |
 |<----------------------------------------|
 |                                         |
 |                                         |Bob accepts and
 |                                         |indicates his
 |                                         |support as well
 |                                         |
 |     Two way Opus Audio                  |
 |.........................................|
 |                                         |
 |Per packet audio-level is included in the|
 |RTP header                               |
 |                                         |

5.4.2. Audio Conference - Voice Activity Detection

This example shows SDP for RTP header extension that allows RTP-level mixers in audio conferences to deliver information about the audio level of individual participants.

     Audio Conference with VAD Support

Alice                                    Mixer
|                                         |
|Alice indicates her interest to audio    |
|levels for the contributing sources      |
|                                         |
|Offer(Audio:Opus,PCMU,PCMA)              |
|---------------------------------------->|
|                                         |
|                                         |
|Answer(Audio:Opus,PCMU,PCMA)             |
|<----------------------------------------|
|                                         |
|                                         |Mixer indicates
|                                         |it can provide
|                                         |audio-levels
|Two way Opus Audio                       |
|.........................................|
|                                         |
|Audio-levels per CSRCS is included in the|
|RTP header                               |
|                                         |

5.4.3. Successful legacy Interop Fallback with bundle-only

In the scenario described below, Alice is a multi-stream capable WebRTC endpoint while Bob is a legacy VOIP end-point. The SDP Offer/Answer exchange demonstrates successful session setup with fallback to audio only stream negotiated via bundle-only framework between the end-points. Specifically,

• Offer from Alice describes 2 cameras via 2 video m=lines with both marked as bundle-only.
• Bob doesn't recognize BUNDLE mechanism and since Alice has marked both the video m=lines with port 0, Bob accepts just the audio stream from Alice.

NOTE: Since Alice is unaware of Bob's support for BUNDLE framework, Alice includes separate RTP/RTCP ports and candidate information.

         Successful 2-Way WebRTC <-> VOIP Interop

Alice                                                       Bob
|                                                           |
|                                                           |
|       Alice is a multistream capable WebRTC end-point     |
|          & Bob is behind a legacy VOIP system             |
|                                                           |
|Offer(Audio:Opus Video:2 VP8,2 H.264 Streams) with         |
|          bundle-only                                      |
|---------------------------------------------------------->|
|     Alice marks both the video streams as bundle-only     |
|                                                           |
|                                                           |
|                  Answer(Audio:Opus)                       |
|<----------------------------------------------------------|
|                                                           |Bob
|                                                           |accepts
|                                                           |audio
|                                                           |stream,
|                                                           |since he
|                                                           |doesn't
|                                                           |recognize
|                                                           |bundle-only
|                                                           |
|                   Two way Opus Audio                      |
|...........................................................|
|                                                           |
|                                                           |

5.4.4. Legacy Interop with RTP/AVP profile

In the scenario described below, Alice is a legacy end-point which sends [RFC3264] Offer with RTP/AVP based audio and video descriptions along with DTLS fingerprint and RTCP feedback information.

On the other hand, Bob being a WebRTC end-point follows procedures in section 5.1.2 of [I-D.ietf-rtcweb-jsep] and accepts the Alice's offer for DTLS-SRTP based session with RTCP feedback.

           Successful 2-Way WebRTC <-> VOIP Interop

Alice                                                       Bob
|                                                            |
|                                                            |
|Alice is a legacy VOIP End-point & Bob is a WebRTC End-Point|
|                                                            |
|                                                            |
|                                                            |
|              Offer(Audio:Opus Video:H.264)                 |
|----------------------------------------------------------->|
|                                                            |
|                                                            |
|Alice includes :                                            |
|Legacy compliant media description (RTP/AVP) with dtls      |
|fingerprint and rtcp feedback support                       |
|                                                            |
|             Answer(Audio:Opus, Video:H.264)                |
|<-----------------------------------------------------------|
|                                                            |Bob
|                                                            |accepts
|                                                            |"legacy
|                                                            |compliant"
|                                                            |m=line
|                                                            |
|                                                            |
|             Two way Opus Audio, H.264 Video                |
|............................................................|
|       Session also supports RTP/RTCP Mux, RTCP Feedback    |
|                                                            |

6. IANA Considerations

This document requires no actions from IANA.

7. Security Considerations

The IETF has published separate documents [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing the security architecture for WebRTC as a whole.

In addition, since the SDP offer and answer messages can contain private information about addresses and sessions to be established between parties, if this information needs to be kept private, some security mechanism (using TLS transport for example) in the protocol used to carry the offers and answers must be used.

8. Acknowledgments

We would like to thank Justin Uberti, Chris Flo, Paul Kyzivat, Nils Ohlmeier, Flemming Andreason, Magnus Westerlund for their detailed review and inputs. Thanks to Adam Roach for providing syntax validation script to help highlight syntax and formatting errors.

9. Change Log

[RFC EDITOR NOTE: Please remove this section when publishing]

Changes from draft-ietf-rtcweb-sdp-11

• Address Magnus Westerlund Review comments.
• Remove reference to RFC5245 and use ice-sip-sdp instead.
• Add an ice2 example for RFC8445.

Changes from draft-ietf-rtcweb-sdp-09

• Review feedback incorporated from Flemming Andreason in Section 5.4

Changes from draft-ietf-rtcweb-sdp-08

• Fixed formatting and syntax issues pointed out by Adam Roach's validator script. List of issues are here: https://github.com/fluffy/ietf/issues?q=is%3Aissue+is%3Aclosed
• Align examples to match latest bundle specification as pointed by Christer Holmberg

Changes from draft-ietf-rtcweb-sdp-07

• Incorporate review from Nils.

Changes from draft-ietf-rtcweb-sdp-06

• Keep Alive Version.

Changes from draft-ietf-rtcweb-sdp-05

• Title change.

Changes from draft-ietf-rtcweb-sdp-04

• Add IPv6 Example.
• Add a=rtcp-mux-only and fix a=rtcp in examples.
• Fix Idnits.
• Add Security Considerations section.

Changes from draft-ietf-rtcweb-sdp-02 to draft-ietf-rtcweb-sdp-04

• Alignment with JSEP-19.
• Added a=identity example.
• Added a=dtls-id, a=group:LS in the examples.
• Added Appendix section to capture list of checklists for the attributes.
• Removed SSRC lines to match JSEP-19.
• Closed open issues on a=fingerprint, a=rtcp and a=rtcp-mux-only from ietf96 to reflect JSEP-19.
• Simplied Inter-op example

Changes from draft-ietf-rtcweb-sdp-02

• Version increment to avoid expiry

Changes from draft-ietf-rtcweb-sdp-01

• Complete face-lift
• Added visual markers around m=lines to indicate their type, added spacing between tables for aiding readers
• Updated table names to indicate offer vs answer
• Attempted to align to latest versions of SCTP, BUNDLE, MSID drafts
• Added mid header extensions to all the lines
• Harmonized BUNDLE semantics and conventions updated.

Changes from draft-ietf-rtcweb-sdp-00

• Updated Simulcast/FEC/RTX examples to use RID framework
• Fixed BUNDLE references for a=bundle-only

Changes from draft-nandakumar-rtcweb-sdp-08

• Fixed typos
• Moved to a WG version

Changes from draft-nandakumar-rtcweb-sdp-06 and draft-nandakumar-rtcweb-sdp-07

• Added clarification on Call-Flow diagram usage
• More cleanups

Changes from draft-nandakumar-rtcweb-sdp-05

• Added Ascii chart for all the SDP Eaxamples
• Improved text and updated SDP Examples for Simulcast and FEC
• Fixed MediaStream ID Semantics SDP Errors

Changes from draft-nandakumar-rtcweb-sdp-04

• Interim version of the draft to avert expiry
• Corrected placement of c= line as per RFC4566
• Updated simulcast SDP to reflect draft-westerlund-avtcore-rtp-simulcast-04

Changes from draft-nandakumar-rtcweb-sdp-03

• Aligned more closely with JSEP version -05
• Added Conventions to help readability
• Add more examples to clarify BUNDLE use-cases

Changes from draft-nandakumar-rtcweb-sdp-02

• Major refactoring was done to group the examples in to categories
• SDP was updated through out to reflect JSEP-04 style of defining attributes per m=line than at the session level.
• Added 8 new examples.
• Updated references for Trickle, Unified Plan
• Add section to explain the syntax conventions followed in the examples.

Changes from draft-nandakumar-rtcweb-sdp-01

• Updated references to OPUS RTP Payload Specification.
• Updated BUNDLE examples based on the latest draft-ietf-mmusic-sdp-bundle-negotiation.
• Added examples for multiple audio and video flows based on Unified Plan.
• Added new examples for RTX and FEC streams
• Updated Simulcast and SVC examples

Changes from draft-nandakumar-rtcweb-sdp-00

• Fixed editorial comments on the mailing list.
• Updated Data-channel SDP information based on draft-ietf-mmusic-sctp-sdp.
• Updated BUNDLE examples based on draft-ietf-mmusic-sdp-bundle-negotiation.
• Added examples for few more BUNDLE variants
• Added new examples for Simulcast and SVC

10. Informative References