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

Abstract

The Web Real-Time Communication (WebRTC) [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 negotiataion happens based on the SDP Offer/Answer exchange mechanism described in the RFC 3264 [RFC3264].

This document serves a introductory purpose in describing the role of SDP for the most common WebRTC use-cases.

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

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

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 January 14, 2014.

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 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. Secure Two-Way Audio,Video and Data with RTCP Feedback
• 5.2. Secure Two-way Audio,Video,Data and remove data stream
• 5.3. Secure Two-Way Audio,Video with BUNDLE Support Unknown
• 5.4. Secure Two-Way Audio,Video w/BUNDLE Support Known
• 5.5. Secure Two-Way Audio,Video w/BUNDLE Unsupported
• 5.6. Successful One Way Session with 2 Video Streams
• 5.7. Sendonly Simulcast w/2 cameras and 2 encodings per camera
• 5.8. Successful SVC Video Stream
• 5.9. Successful Simulcast Video Streams with Retransmisson
• 5.10. Successful 1-way Simulcast with 2 resolutions and RTX - One resolution rejected
• 5.11. Simulcast Video Stream with Forward Error Correction
• 6. WebRTC <-> Legacy Interop Examples
• 6.1. Successful legacy Interop Fallaback with bundle-only
• 7. IANA Considerations
• 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 multimedia session. For this purpose, SDP is used to construct [RFC3264] offers/answers for describing (media and non-media) streams as appropriate for recipients of a 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 and 6 provide sample SDP usages 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 be audio,video,whiteboards,fax,modem, and other streams. It 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, Real-time Transport Protocol and Real-time Streaming Protocol.

Below figure introduces high-level breakup of SDP into components that semantically describe a multimedia session,in our case,say,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 control the signaling plane of a multimedia session as described in the JSEP specification [JSEP]. JSEP provides mechanisms to create session characterisation and media definition information to conduct the session based on SDP exchanges.

In this context,SDP serves two purposes:

• Provide grammatical structure syntatically
• Semantically convey partipant's intention and capabilities.

4. Offer/Answer and the WebRTC

This section introduces SDP Offer/Answer Exchange mechanism mandated by WebRTC for negotitating 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 [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 modelled on 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.

The following sections provide samples of SDP message details and exchanges for the most common WebRTC usecases.

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 Media streams
• MAY contain zero or more non-media data streams
• All the streams are secured with DTLS/SRTP
• ICE processing for NAT Traversal
• Sessions over IPv4-only, IPv6-only, dual-stack based clients.

As mentioned earlier [WEBRTC] proposes using SDP based Offer/Answer model to negotiate multimedia session between peers' browsers Building on the concepts from the previous sections, the following subsections attempts to describe the usage of SDP for the most common WebRTC use-cases.

In all the use-cases, Alice and Bob are assumed to be the WebRTC peers unless mentioned otherwise. Pointers to appropriate RFCs and notes are provided, wherever necessary,against the SDP lines.

5.1. Secure Two-Way Audio,Video and Data with RTCP Feedback

This use-case allows two users to participate in a two-way communication session securely on their WebRTC enabled Web browsers.

title WebRTC Session - 2-Way Secure Audio,Video with RTCP Feedback
Alice->Bob: Offer(Audio:G.711,Opus,iLBC Video:H.264,VP8)
Bob->Alice: Answer(Audio:Opus,DTMF Video:H.264)
Alice->Bob: Two-way Opus Audio, H.264 Video
note right of Alice
  Session also suports RTP/RTCP Mux, RTCP feedback (nack,pli) 
end note

More specifically, this use-case demonstrates following aspects of a WebRTC session

• SRTP with DTLS based encryption
• RTP and RTCP Muxing
• RTCP based feedback and reduced size support
• ICE processing for NAT Traversal
• Audio Codec Offered : PCMU, Opus, iLBC
• Audio Codec Answered : Opus
• Video Codecs Offered: H.264, VP8
• Video Codecs Answered: H.264
• Data Channel Support

The tables (5.1 and 5.2) below capture in detail, the initial SDP Offer and Answer messages exchanged.

The exact SDP parameters specified for Data-Channel is still under the WG discussion and is expected to be updated once the final decision is reached..

title WebRTC Session (Audio,Video,Datachannel) - Drop Datachannel
note right of Alice
    Alice & Bob are in a two-way audio,video and datachannel session.
    Alice decides to stop the datachannel stream
end note
Alice->Bob: Offer(Audio:Opus Video:VP8, Application: Drop)
Bob->Alice: Answer(Audio:Opus Video:VP8, Application:Drop)
Alice->Bob: Two-way Opus Audio and VP8 Video

title WebRTC Session - 2-Way Secure Audio,Video with BUNDLE
Alice->Bob: Offer(Audio:Opus Video:VP8) with BUNDLE support and unique addresses.
Bob->Alice: Answer(Audio:Opus Video:VP8) indicating its support for BUNDLE
Alice->Bob: Updated Offer(Audio:Opus Video:VP8) for Bundle Address Synchronzation.

title WebRTC Session - 2-Way Secure Audio,Video with BUNDLE Support Known
Alice->Bob: Offer(Audio:Opus Video:VP8) with identical port numbers
Bob->Alice: Answer(Audio:Opus Video:VP8) with identical port numbers
Alice->Bob: Two-way Opus Audio, H.264 Video over a single 5-tuple

title WebRTC Session - 2-Way Secure Audio,Video with BUNDLE Unsupported
Alice->Bob: Offer(Audio:Opus Video:VP8)  with BUNDLE support, unique port numbers
Bob->Alice: Answer(Audio:Opus Video:VP8) with no BUNDLE support, unique port numbers
Alice->Bob: Two-way Opus Audio, H.264 Video over 2 different RTP sessions.

title 1 Way Audio & Video w/2 Video Streams
note right of Alice
Alice offers 2 sendonly video streams
one for her video feed and other for her presentation slides.
end note
Alice->Bob: Offer(Audio:Opus, Video1,2: VP8)
note right of Bob
Bob accepts Alice's offer
end note
Bob->Alice: Answer(Audio:Opus, Video1,2: VP8)
Alice->Bob: One-way Opus Audio, VP8 Video
note right of Alice
Bob can hear Alice and see her video feed as well
as her presentation slides.
end note

title 1 Way Successful Simulcast
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.

title 2 way SVC Video
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 right 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
note right of Alice
Successful 2 way simulcast session with associated retransmission streams
end note

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 Streams) bundle-only
note right 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
note right of Alice
Successful 1 way session with 1 Video Stream and the associated RTX Stream
end note

title Simulcast Streams with Forward Error Correction
note right of Alice
Alice offers single audio and simulcasted video stream
end note
Alice->Bob: Offer(Audio:Opus Video:VP8 with 2 resolutions with FEC Streams) bundle-only
note right 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
note right of Alice
Successful Session with 4 video streams (Simulcast + FEC) and 1 Audio Stream

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 right of Bob
 Bob accepts only Audio stream since he doesn't recognize
 bundle-only streams
end note
Alice->Bob: Two-way Opus Audio