SDP for the WebRTC
draft-nandakumar-rtcweb-sdp-05

Abstract

The Web Real-Time Communication [WebRTC] 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 WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism described in the RFC 3264 [RFC3264].

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

This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work.

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 February 13, 2015.

Copyright Notice

Copyright (c) 2014 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 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. Two-Way Audio Only Session
• 5.2.2. Two-Way Audio/Video Session
• 5.2.3. Two-Way 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. Two-Way Audio,Video w/BUNDLE Unsupported
• 5.2.10. Audio, Video BUNDLED but Data Not BUNDLED
• 5.2.11. Audio Only then Add Video and BUNDLE
• 5.3. MultiResolution, RTX, FEC Examples
• 5.3.1. Sendonly Simulcast w/2 cameras and 2 encodings per camera
• 5.3.2. Successful SVC Video Stream
• 5.3.3. Successful Simulcast Video Streams with Retransmisson
• 5.3.4. Successful 1-way Simulcast with 2 resolutions and RTX - One resolution rejected
• 5.3.5. Simulcast Video Stream 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 Fallaback with bundle-only
• 5.4.4. Legacy Interop with RTP/AVP profile
• 6. IANA Considerations
• 7. Acknowledgments
• 8. Change Log
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

Javascript Session Exchange Protocol(JSEP) [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: Section 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].

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

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.

[WebRTC] proposes JavaScript application to fully specify and control the signaling plane of a multimedia session as described in the JSEP specification [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 partipant'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. Javascript Session Establishment Protocol specification [JSEP] for WebRTC provides the mechanism for generating [RFC3264] SDP Offers and Answers in order for both sides of the session to agree upon details such as 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.

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.
• [draft-ietf-mmusic-sdp-bundle-negotiation] support for multiplexing several media streams on a single underlying transport is enabled by default unless explicitly specified 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.
• 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.
  • 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.
  • 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.
  • 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 provide for further information 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 more details, readers are recommended to refer to the Javascript Session Exchange Protocol(JSEP)

  [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, 99 for H.264 and 120 for VP8 in most of the examples to maintain uniformity.
• In the actual use that values that represent SSRCs, ICE candidate foundations, WebRTC Mediastream and MediaStreamTrack Ids can be much larger and random than the ones shown in the examples.

[OPEN ISSUE-1]: SDP Examples for Data Channel, Simulcast, SVC are still being discussed and doesn't represent the final solution.

[OPEN ISSUE-2]: API surface for controlling BUNDLE, TRICKLE-ICE are ignored for the time being.

5.2. Basic Examples

5.2.1. Two-Way 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 audio codecs offered.

title 2-Way Audio Only Session

participant Alice as Alice
participant Bob as Bob

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

title 2-Way Audio,Video Session

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

title WebRTC Session - 2-Way Secure Audio,Video with RTCP Feedback
Alice->Bob: Offer(DataChannel)
Bob->Alice: Answer(Data-Channel)
Alice->Bob: Two-way SCTP based Data-Channel

title Secure 2-Way Audio Only Session
participant Alice as Alice
participant Bob as Bob
Alice->Bob: Offer(Audio:Opus)
Bob->Alice: Answer(Audio:Opus,a=sendonly)
Alice->Bob: One-way Opus Audio (preferred codec)

title Audio Session with DTMF
participant Alice as Alice
participant Bob as Bob
Alice->Bob: Offer(Audio:Opus,PCMU,PCMA Audio:telephone-event)
Bob->Alice: Answer(Audio:Opus, Audio:telephone-event)
Alice->Bob: Opus audio stream and telephone-event stream

title 1 Way Audio & Video Session - Document Camera

note right of Alice
Alice Offers sendonly audio and video streams.
The video stream corresponds to her presentation
slides via a=content SDP attribute)
end note
Alice->Bob: Offer(Audio:Opus, Video: VP8)
note left of Bob
Bob accepts Alice's offer
end note
Bob->Alice: Answer(Audio:Opus, Video: VP8)
Alice->Bob: One-way Opus Audio, VP8 Video
note right of Alice
Bob can hear Alice and see her presentation slides.
end note

title 2-Way Secure Audio,Video with BUNDLE support unknown

Alice->Bob: Offer(Audio:Opus Video:VP8)
note right of Alice
Alice offers BUNDLE support with unique address for the audio and video m-line
end note

Bob->Alice: Answer(Audio:Opus Video:VP8) indicating its support for BUNDLE
note left of Bob
Bob uses identical addresses across the m=lines
end note

Alice->Bob: Updated Offer(Audio:Opus Video:VP8) for Bundle Address Synchronzation.

Alice <-> Bob: 2Way Call with Audio and Video Multiplexed

title Audio, Video, Data with BUNDLE support known

Alice->Bob: Offer(Audio:Opus, Video:VP8, Data)
note right of Alice
Alice indicates BUNDLE support with identical address across all the m=lines.
end note

Bob->Alice: Answer(Audio:Opus Video:VP8, Data)
note left of Bob
Bob does the same
end note
Alice<->Bob: Two way Audio, Video and Data multiplexed

title 2-Way Secure Audio,Video with BUNDLE Unsupported

Alice->Bob: Offer(Audio:Opus Video:VP8)
note right of Alice
Alice offers BUNDLE support with unique address for the audio and video m-line
end note

Bob->Alice: Answer(Audio:Opus Video:VP8)
note left of Bob
Bob uses unique addresses as well since he doesn't understand BUNDLE
end note

Alice <-> Bob: 2Way Call with Audio and Video on different addresses.

title Audio, Video, with Data out of BUNDLE
Alice->Bob: Offer(Audio:Opus, Video:VP8, Data (Not in BUNDLE)
note right of Alice
Alice wants to multiplex audio, video but not data
end note

Bob->Alice: Answer(Audio:Opus Video:VP8, Data)
note left of Bob
Bob does the same
end note
Alice<->Bob: Two way Audio, Video multiplexed except Data

title Audio Only , Add Video and BUNDLE

Alice->Bob: Offer(Audio:Opus)
note right of Alice
Alice indicates support for BUNDLE
end note

Bob->Alice: Answer(Audio:Opus)
note left of Bob
Bob also indicates support for BUNDLE
end note
Alice<->Bob: Two way Audio only session

Alice->Bob: Updated Offer(Audio:Opus, Video:VP8)
note right of Alice
Alice adds video stream to BUNDLE with audio
end note

Bob->Alice: Updated Answer(Audio:Opus, Video:VP8)
note left of Bob
Bob also does the same
end note
Alice<->Bob: Two way Opus Audio and VP8 Video session

title 1 Way Successful Simulcast w/BUNDLE

note right of Alice
Alice offers 2 sendonly video streams with 2 simulcast encodings per stream
end note
Alice->Bob: Offer(Audio:Opus,Video1:VP8,Video2:H.264) with bundle-only for video
note left of Bob
Bob accepts Alice's offer and 2 encodings per stream
end note
Alice->Bob: One-Way 1 Opus, 2 H.264 and 2 VP8 video streams, all mulitplexed

title SVC Session - 3 Layers w/BUNDLE
note right of Alice
Alice offers 3 sendonly video stream with 3 layers of SVC
end note
Alice->Bob: Offer(Audio:Opus Video: H.264 SVC) bundle-only
note left of Bob
Bob accepts Alice's Offered Codec operation points
end note
Bob->Alice: Answer(Video: H.264) bundle-only
Alice->Bob: One-Way H.264 Video with codec points as indicated by Bob.

title Simulcast Streams with Retransmission

note right of Alice
Alice offers single audio and simulcasted video stream
end note
Alice->Bob: Offer(Audio:Opus Video:VP8 with 2 resolutions and RTX Stream) bundle-only
note left of Bob
Bob accepts all the streams offered by Alice
end note

Bob->Alice: Answer(Audio:Opus Video:VP8 with 2 resolutions and RTX Stream) bundle-only

Alice<->Bob: 2 Way Audio and Simulcast Video with RTX Streams

title Simulcast Streams with Retransmission Rejected

note right of Alice
Alice offers sendonly single audio and simulcasted video stream.
end note
Alice->Bob: Offer(Audio:Opus Video:VP8 with 2 resolutions and RTX Streams) bundle-only

note left of Bob
Bob accepts one simulcast,rtx and rejects the other
end note
Bob->Alice: Answer(Audio:Opus Video:VP8 with 1 resolution and the RTX Stream) bundle-only

Alice->Bob: 1 Way Audio, Video Session
note right of Alice
Only 1 Video stream and its associated RTX stream
is sent to Bob
end note

title Simulcast Streams with Forward Error Correction

note right of Alice
Alice offers sendonly single audio and simulcasted video stream
end note
Alice->Bob: Offer(Audio:Opus Video:VP8 with 2 resolutions with FEC Streams) bundle-only

note left of Bob
Bob accepts simulcast stream as well as FEC streams
end note
Bob->Alice: Answer(Audio:Opus Video:VP8 with 2 resolutions with FEC Streams) bundle-only

Alice->Bob: 1 Way Audio, Video Session
note right of Alice
Successful Session with 4 video streams (Simulcast + FEC) and 1 Audio Stream

title 2-Way Audio with VAD

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

title Audio Conference with VAD Support

Alice->Mixer: Offer(Audio:Opus,PCMU,PCMA)
note right of Alice
Alice indicates its interest to audio levels for the contributing sources
end note
Mixer->Alice: Answer(Audio:Opus,PCMU,PCMA)
note left of Bob
Mixer indicates it can provide audio-levels per CSRC
end note
Alice<->Mixer: Two-way Opus Audio
note right of Alice
 Audio levels per CSRC is included in the RTP Header
end note

title Successful 2-Way WebRTC <-> VOIP Interop

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