SDP for the WebRTC

draft-nandakumar-rtcweb-sdp-01

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.

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 August 27, 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 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 w/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. Add New Media (video)
• 5.8. Successful Simulcast with 2 Encodings, 2 Cameras
• 5.9. Successful SVC Video Stream
• 6. WebRTC <-> Legacy Interop Examples
• 6.1. Secure Two-Way Audio,Video w/Feedback - WebRTC <-> Legacy Interop
• 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 provide 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 the [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 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,agains 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 a decission is made.

5.2. Secure Two-way Audio,Video,Data and remove data stream

This scenario builds upon from the usecase in the section 5.1 It extends by Alice removing data-stream once the session is in progress.

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

As a precondition, A Two-Way Audio,Video and Data Session is already setup.

5.3. Secure Two-Way Audio,Video w/BUNDLE Support Unknown

This use-case demonstrates a successfull audio and video multiplexing scenario with SDP BUNDLE negotiation when the Alice is unsure of the Bob's BUNDLE support. Table below also illustrates, additional SDP Offer/Answer exchange once the Alice figures that a 2-way BUNDLE session can be setup.

title WebRTC Session - 2-Way Secure Audio,Video with BUNDLE
Alice->Bob: Offer(Audio:Opus Video:VP8) with BUNDLE support and different port numbers
Bob->Alice: Answer(Audio:Opus Video:VP8) indicating its support for BUNDLE
Alice->Bob: Updated Offer(Audio:Opus Video:VP8) with BUNDLE support and same port number
Bob->Alice: Answer(Audio:Opus Video:VP8) accepts the updated Offer
Alice->Bob: Two-way Opus Audio, H.264 Video over a single 5-tuple

5.4. Secure Two-Way Audio,Video w/BUNDLE Support Known

This use-case demonstrates a successfull audio and video multiplexing scenario with SDP BUNDLE negotiation Alice (Offerer) knows about Bob's (Answerer) BUNDLE support.

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

5.5. Secure Two-Way Audio,Video w/BUNDLE Unsupported

This use-case illustrates SDP Offer/Answer exchange when the far-end (Bob) either doesn't support media bundling or doesnot want to group m=lines 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.

5.6. Successful One Way Session with 2 Video Streams

In this scenario Alice and Bob engage in one-way multimedia session with Bob receiving two video streams, one corresponding to Alice's video and other corresponding to her presentation slides.

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

5.7. Add New Media (video)

This scenario describes the message exchanges when Alice decides to add video to an existing audio-only session

title Add New Media(Video)
Alice->Bob: Offer(Audio:G.711,Opus,iLBC)
Bob->Alice: Answer(Audio:Opus)
Alice->Bob: Two-way Opus Audio
note right of Alice
Alice decides to add Video
end note
Alice->Bob: Offer(Audio:G.711,Opus,iLBC Video:VP8)
Bob->Alice: Answer(Audio:Opus, Video:VP8)
Alice->Bob: Two-way Opus Audio, VP8 Video

Alice decides to add Video to the current session

5.8. Successful Simulcast with 2 Encodings, 2 Cameras

The SDP Offer/Answer exchange illustrates simulcasting use-case, where Alice 2 cameras with 2 encoding options per camera.

title 2 Way Successful Simulcast
note right of Alice
Alice offers 2 sendonly video streams with 2 simulcast encodings per stream
end note
Alice->Bob: Offer(Video1,2: H.264)
note left of Bob
Bob accepts Alice's offer and 1 encoding per stream
end note
Bob->Alice: Answer(Video1,2: H.264)
Alice->Bob: One-Way H.264 Video with Bob selected video stream encodings

5.9. Successful SVC Video Stream

In the example Offer/Answer exchange mechanism below, Alice Offers 3 media descriptions of type video along with the layered decoding depencies between them. On the other hand, Bob accepts only 2 of 3 Operation points offered by Alice.

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(Video: H.264)
note left of Bob
Bob accepts Alice's Offer with 2 Operation Points of the 3
offered
end note
Bob->Alice: Answer(Video: H.264)
Alice->Bob: One-Way H.264 Video with encodings per instructed by Bob

6. WebRTC <-> Legacy Interop Examples

In this section, we attempt to provide session descriptions showcasing inter-operability between a WebRTC end-point and a Legacy VOIP end-point. The ideas included in here are not fully baked into the standards and might be controversial in nature. The hope here is to demonstrate a plausible SDP composition to enchance seamless inter-operability between the aforementioned communication systems.

6.1. Secure Two-Way Audio,Video w/Feedback - WebRTC <-> Legacy Interop

In the scenario desribed below, Alice sends [RFC3264] Offer with two sets of media descriptions per media type.

• One set that correponds to [WEBRTC] Compliant RTP/SAVPF based audio and video descriptions.
• Another set with RTP/AVP based audio and video descriptions for the legacy Interop purposes.
• Also to note, Alice includes session level DTLS information and media level RTCP feedback information as applicable to both the sets of media descriptions

On the other hand, Bob being a Legacy VOIP end-point, recognizes only the media descriptions with RTP/AVP as the application protocol. The security and fedback requirements for the session are either handled by a intermediate gateway or with some combination of Bob's capabilities and the intermediate gateway.

title Successful 2-Way WebRTC <-> VOIP Interop
note right of Alice
Alice is on a WebRTC end-point & Bob is behind a legacy VOIP system
end note
Alice->Bob: Offer(Audio:Opus Video:VP8)
note right of Alice
 Alice includes 2 copies of media descriptions
 1. WebRTC compliant media description (RTP/SAVPF)
 2. Legacy compliant media description (RTP/AVP)
end note
Bob->Alice: Answer(Audio:Opus Video:VP8)
note right of Bob
 Bob recognizes"legacy compliant" media description from Alice.
 and accepts the same.
end note
Alice->Bob: Two-way Opus Audio, VP8 Video
note right of Alice
  Session also suports RTP/RTCP Mux, RTCP feedback (nack,pli) 
end note

7. IANA Considerations

This document requires no actions from IANA.

8. Change Log

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

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

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses

<span>
  <span>Suhas Nandakumar</span> 
  <span>
    <span>Nandakumar</span>
  </span>
</span>
<span>Cisco</span>
<span>
  <span>170 West Tasman Drive</span>

  <span>
    <span>San Jose</span>,  
    <span>CA</span> 
    <span>95134</span>
  </span>
  <span>USA</span>
</span>
<span>EMail: <a href="mailto:snandaku@cisco.com">snandaku@cisco.com</a></span>




<span>
  <span>Cullen Jennings</span> 
  <span>
    <span>Jennings</span>
  </span>
</span>
<span>Cisco</span>
<span>
  <span>170 West Tasman Drive</span>

  <span>
    <span>San Jose</span>,  
    <span>CA</span> 
    <span>95134</span>
  </span>
  <span>USA</span>
</span>
<span>Phone: +1 408 421-9990</span>

EMail: fluffy@cisco.com