draft-ietf-rtcweb-jsep-07.txt   draft-ietf-rtcweb-jsep-08.txt 
Network Working Group J. Uberti Network Working Group J. Uberti
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: January 5, 2015 Cisco Expires: April 30, 2015 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
July 4, 2014 October 27, 2014
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-07 draft-ietf-rtcweb-jsep-08
Abstract Abstract
This document describes the mechanisms for allowing a Javascript This document describes the mechanisms for allowing a Javascript
application to control the signaling plane of a multimedia session application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API, and via the interface specified in the W3C RTCPeerConnection API, and
discusses how this relates to existing signaling protocols. discusses how this relates to existing signaling protocols.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Design of JSEP . . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 3
1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6
3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Session Descriptions and State Machine . . . . . . . . . . 7 3.2. Session Descriptions and State Machine . . . . . . . . . 6
3.3. Session Description Format . . . . . . . . . . . . . . . . 9 3.3. Session Description Format . . . . . . . . . . . . . . . 10
3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. ICE Candidate Trickling . . . . . . . . . . . . . . . 10 3.4.1. ICE Gathering Overview . . . . . . . . . . . . . . . 10
3.4.1.1. ICE Candidate Format . . . . . . . . . . . . . . . 11 3.4.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 11
3.4.2. ICE Candidate Pool . . . . . . . . . . . . . . . . . . 11 3.4.2.1. ICE Candidate Format . . . . . . . . . . . . . . 11
3.5. Interactions With Forking . . . . . . . . . . . . . . . . 12 3.4.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 12
3.5.1. Sequential Forking . . . . . . . . . . . . . . . . . . 12 3.4.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 13
3.5.2. Parallel Forking . . . . . . . . . . . . . . . . . . . 13 3.5. Interactions With Forking . . . . . . . . . . . . . . . . 13
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.1. Sequential Forking . . . . . . . . . . . . . . . . . 14
4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.2. Parallel Forking . . . . . . . . . . . . . . . . . . 14
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 14 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 14 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 15
4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . . 16 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 17
4.1.4.1. Use of Provisional Answers . . . . . . . . . . . . 17 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 18
4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . . 18 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 19
4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 18 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 20
4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . . 19 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 20
4.1.7. localDescription . . . . . . . . . . . . . . . . . . . 19 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 21
4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 20 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 21
4.1.9. updateIce . . . . . . . . . . . . . . . . . . . . . . 20 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 22
4.1.10. addIceCandidate . . . . . . . . . . . . . . . . . . . 20 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 22
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . . 20 4.1.9. canTrickle . . . . . . . . . . . . . . . . . . . . . 22
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 21 4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 23
5.1.1. Implementation Requirements . . . . . . . . . . . . . 21 4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 24
5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . . 22 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 24
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 22 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 24
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . . 22 5.1.1. Implementation Requirements . . . . . . . . . . . . . 24
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 26 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 26
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . . 28 5.1.3. Profile Names and Interoperability . . . . . . . . . 26
5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 28 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 27
5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 29 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 27
5.2.3.3. VoiceActivityDetection . . . . . . . . . . . . . . 29 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 32
5.2.3.4. IceRestart . . . . . . . . . . . . . . . . . . . . 29 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 35
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . . 29 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 35
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 30 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 35
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . . 33 5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 36
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . . 33 5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 36
5.4. Parsing an Offer . . . . . . . . . . . . . . . . . . . . . 33 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 36
5.5. Parsing an Answer . . . . . . . . . . . . . . . . . . . . 33 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 36
5.6. Applying a Local Description . . . . . . . . . . . . . . . 33 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 40
5.7. Applying a Remote Description . . . . . . . . . . . . . . 33 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 41
6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 33 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 5.4. Parsing an Offer . . . . . . . . . . . . . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 5.5. Parsing an Answer . . . . . . . . . . . . . . . . . . . . 41
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 5.6. Applying a Local Description . . . . . . . . . . . . . . 41
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.7. Applying a Remote Description . . . . . . . . . . . . . . 41
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . . 38 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix A. JSEP Implementation Examples . . . . . . . . . . . . 39 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 43
A.1. Example API Flows . . . . . . . . . . . . . . . . . . . . 39 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 47
A.1.1. Call using ROAP . . . . . . . . . . . . . . . . . . . 39 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58
A.1.2. Call using XMPP . . . . . . . . . . . . . . . . . . . 40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
A.1.3. Adding video to a call, using XMPP . . . . . . . . . . 42 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58
A.1.4. Simultaneous add of video streams, using XMPP . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.1.5. Call using SIP . . . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . 59
A.1.6. Handling early media (e.g. 1-800-GO FEDEX), using 11.2. Informative References . . . . . . . . . . . . . . . . . 61
SIP . . . . . . . . . . . . . . . . . . . . . . . . . 44 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 62
A.2. Example Session Descriptions . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
A.2.1. createOffer . . . . . . . . . . . . . . . . . . . . . 45
A.2.2. createAnswer . . . . . . . . . . . . . . . . . . . . . 47
A.2.3. Call Flows . . . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
This document describes how the W3C WEBRTC RTCPeerConnection This document describes how the W3C WEBRTC RTCPeerConnection
interface[W3C.WD-webrtc-20140617] is used to control the setup, interface[W3C.WD-webrtc-20140617] is used to control the setup,
management and teardown of a multimedia session. management and teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
The thinking behind WebRTC call setup has been to fully specify and The thinking behind WebRTC call setup has been to fully specify and
skipping to change at page 4, line 28 skipping to change at page 3, line 51
to the particular application, perhaps for a novel use case. In this to the particular application, perhaps for a novel use case. In this
approach, the key information that needs to be exchanged is the approach, the key information that needs to be exchanged is the
multimedia session description, which specifies the necessary multimedia session description, which specifies the necessary
transport and media configuration information necessary to establish transport and media configuration information necessary to establish
the media plane. the media plane.
With these considerations in mind, this document describes the With these considerations in mind, this document describes the
Javascript Session Establishment Protocol (JSEP) that allows for full Javascript Session Establishment Protocol (JSEP) that allows for full
control of the signaling state machine from Javascript. JSEP removes control of the signaling state machine from Javascript. JSEP removes
the browser almost entirely from the core signaling flow, which is the browser almost entirely from the core signaling flow, which is
instead handled by the Javascript making use of two interfaces: (1) instead handled by the Javascript making use of two interfaces: (1)
passing in local and remote session descriptions and (2) interacting passing in local and remote session descriptions and (2) interacting
with the ICE state machine. with the ICE state machine.
In this document, the use of JSEP is described as if it always occurs In this document, the use of JSEP is described as if it always occurs
between two browsers. Note though in many cases it will actually be between two browsers. Note though in many cases it will actually be
between a browser and some kind of server, such as a gateway or MCU. between a browser and some kind of server, such as a gateway or MCU.
This distinction is invisible to the browser; it just follows the This distinction is invisible to the browser; it just follows the
instructions it is given via the API. instructions it is given via the API.
JSEP's handling of session descriptions is simple and JSEP's handling of session descriptions is simple and
straightforward. Whenever an offer/answer exchange is needed, the straightforward. Whenever an offer/answer exchange is needed, the
initiating side creates an offer by calling a createOffer() API. The initiating side creates an offer by calling a createOffer() API. The
application optionally modifies that offer, and then uses it to set application optionally modifies that offer, and then uses it to set
up its local config via the setLocalDescription() API. The offer is up its local config via the setLocalDescription() API. The offer is
then sent off to the remote side over its preferred signaling then sent off to the remote side over its preferred signaling
mechanism (e.g., WebSockets); upon receipt of that offer, the remote mechanism (e.g., WebSockets); upon receipt of that offer, the remote
party installs it using the setRemoteDescription() API. party installs it using the setRemoteDescription() API.
When the call is accepted, the callee uses the createAnswer() API to To complete the offer/answer exchange, the remote party uses the
generate an appropriate answer, applies it using createAnswer() API to generate an appropriate answer, applies it
setLocalDescription(), and sends the answer back to the initiator using the setLocalDescription() API, and sends the answer back to the
over the signaling channel. When the offerer gets that answer, it initiator over the signaling channel. When the initiator gets that
installs it using setRemoteDescription(), and initial setup is answer, it installs it using the setRemoteDescription() API, and
complete. This process can be repeated for additional offer/answer initial setup is complete. This process can be repeated for
exchanges. additional offer/answer exchanges.
Regarding ICE [RFC5245], JSEP decouples the ICE state machine from Regarding ICE [RFC5245], JSEP decouples the ICE state machine from
the overall signaling state machine, as the ICE state machine must the overall signaling state machine, as the ICE state machine must
remain in the browser, because only the browser has the necessary remain in the browser, because only the browser has the necessary
knowledge of candidates and other transport info. Performing this knowledge of candidates and other transport info. Performing this
separation also provides additional flexibility; in protocols that separation also provides additional flexibility; in protocols that
decouple session descriptions from transport, such as Jingle, the decouple session descriptions from transport, such as Jingle, the
session description can be sent immediately and the transport session description can be sent immediately and the transport
information can be sent when available. In protocols that don't, information can be sent when available. In protocols that don't,
such as SIP, the information can be used in the aggregated form. such as SIP, the information can be used in the aggregated form.
skipping to change at page 7, line 34 skipping to change at page 7, line 10
as how to handle the media that is received. These parameters are as how to handle the media that is received. These parameters are
determined by the exchange of session descriptions in offers and determined by the exchange of session descriptions in offers and
answers, and there are certain details to this process that must be answers, and there are certain details to this process that must be
handled in the JSEP APIs. handled in the JSEP APIs.
Whether a session description applies to the local side or the remote Whether a session description applies to the local side or the remote
side affects the meaning of that description. For example, the list side affects the meaning of that description. For example, the list
of codecs sent to a remote party indicates what the local side is of codecs sent to a remote party indicates what the local side is
willing to receive, which, when intersected with the set of codecs willing to receive, which, when intersected with the set of codecs
the remote side supports, specifies what the remote side should send. the remote side supports, specifies what the remote side should send.
However, not all parameters follow this rule; for example, the SRTP However, not all parameters follow this rule; for example, the DTLS-
parameters [RFC4568] sent to a remote party indicate what the local SRTP parameters [RFC5763] sent to a remote party indicate what
side will use to encrypt, and thereby what the remote party should certificate the local side will use in DTLS setup, and thereby what
expect to receive; the remote party will have to accept these the remote party should expect to receive; the remote party will have
parameters, with no option to choose a different value. [[OPEN to accept these parameters, with no option to choose different
ISSUE: This is not correct because we removed SDES values.
(https://github.com/rtcweb-wg/jsep/issues/10)]]
In addition, various RFCs put different conditions on the format of In addition, various RFCs put different conditions on the format of
offers versus answers. For example, a offer may propose multiple offers versus answers. For example, a offer may propose an arbitrary
SRTP configurations, but an answer may only contain a single SRTP number of media streams (i.e. m= sections), but an answer must
configuration. [[OPEN ISSUE: See issue 10 above.]] contain the exact same number as the offer.
Lastly, while the exact media parameters are only known only after an Lastly, while the exact media parameters are only known only after an
offer and an answer have been exchanged, it is possible for the offer and an answer have been exchanged, it is possible for the
offerer to receive media after they have sent an offer and before offerer to receive media after they have sent an offer and before
they have received an answer. To properly process incoming media in they have received an answer. To properly process incoming media in
this case, the offerer's media handler must be aware of the details this case, the offerer's media handler must be aware of the details
of the offer before the answer arrives. of the offer before the answer arrives.
Therefore, in order to handle session descriptions properly, the user Therefore, in order to handle session descriptions properly, the user
agent needs: agent needs:
skipping to change at page 10, line 33 skipping to change at page 10, line 38
Note that most applications should be able to treat the Note that most applications should be able to treat the
SessionDescriptions produced and consumed by these various API calls SessionDescriptions produced and consumed by these various API calls
as opaque blobs; that is, the application will not need to read or as opaque blobs; that is, the application will not need to read or
change them. The W3C WebRTC API specification will provide change them. The W3C WebRTC API specification will provide
appropriate APIs to allow the application to control various session appropriate APIs to allow the application to control various session
parameters, which will provide the necessary information to the parameters, which will provide the necessary information to the
browser about what sort of SessionDescription to produce. browser about what sort of SessionDescription to produce.
3.4. ICE 3.4. ICE
When a new ICE candidate is available, the ICE Agent will notify the 3.4.1. ICE Gathering Overview
application via a callback; these candidates will automatically be
added to the local session description. When all candidates have
been gathered, the callback will also be invoked to signal that the
gathering process is complete.
3.4.1. ICE Candidate Trickling JSEP gathers ICE candidates as needed by the application. Collection
of ICE candidates is referred to as a gathering phase, and this is
triggered either by the addition of a new or recycled m= line to the
local session description, or new ICE credentials in the description,
indicating an ICE restart. Use of new ICE credentials can be
triggered explicitly by the application, or implicitly by the browser
in response to changes in the ICE configuration.
When a new gathering phase starts, the ICE Agent will notify the
application that gathering is occurring through a callback. Then,
when each new ICE candidate becomes available, the ICE Agent will
supply it to the application via an additional callback; these
candidates will also automatically be added to the local session
description. Finally, when all candidates have been gathered, a
callback will be dispatched to signal that the gathering process is
complete.
Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= lines; other m= lines continue to use
their existing candidates.
3.4.2. ICE Candidate Trickling
Candidate trickling is a technique through which a caller may Candidate trickling is a technique through which a caller may
incrementally provide candidates to the callee after the initial incrementally provide candidates to the callee after the initial
offer has been dispatched; the semantics of "Trickle ICE" are defined offer has been dispatched; the semantics of "Trickle ICE" are defined
in [I-D.ietf-mmusic-trickle-ice]. This process allows the callee to in [I-D.ietf-mmusic-trickle-ice]. This process allows the callee to
begin acting upon the call and setting up the ICE (and perhaps DTLS) begin acting upon the call and setting up the ICE (and perhaps DTLS)
connections immediately, without having to wait for the caller to connections immediately, without having to wait for the caller to
gather all possible candidates. This results in faster media setup gather all possible candidates. This results in faster media setup
in cases where gathering is not performed prior to initiating the in cases where gathering is not performed prior to initiating the
call. call.
JSEP supports optional candidate trickling by providing APIs that JSEP supports optional candidate trickling by providing APIs, as
provide control and feedback on the ICE candidate gathering process. described above, that provide control and feedback on the ICE
Applications that support candidate trickling can send the initial candidate gathering process. Applications that support candidate
offer immediately and send individual candidates when they get the trickling can send the initial offer immediately and send individual
notified of a new candidate; applications that do not support this candidates when they get the notified of a new candidate;
feature can simply wait for the indication that gathering is applications that do not support this feature can simply wait for the
complete, and then create and send their offer, with all the indication that gathering is complete, and then create and send their
candidates, at this time. offer, with all the candidates, at this time.
Upon receipt of trickled candidates, the receiving application will Upon receipt of trickled candidates, the receiving application will
supply them to its ICE Agent. This triggers the ICE Agent to start supply them to its ICE Agent. This triggers the ICE Agent to start
using the new remote candidates for connectivity checks. using the new remote candidates for connectivity checks.
3.4.1.1. ICE Candidate Format 3.4.2.1. ICE Candidate Format
As with session descriptions, the syntax of the IceCandidate object As with session descriptions, the syntax of the IceCandidate object
provides some abstraction, but can be easily converted to and from provides some abstraction, but can be easily converted to and from
the SDP candidate lines. the SDP candidate lines.
The candidate lines are the only SDP information that is contained The candidate lines are the only SDP information that is contained
within IceCandidate, as they represent the only information needed within IceCandidate, as they represent the only information needed
that is not present in the initial offer (i.e., for trickle that is not present in the initial offer (i.e., for trickle
candidates). This information is carried with the same syntax as the candidates). This information is carried with the same syntax as the
"candidate-attribute" field defined for ICE. For example: "candidate-attribute" field defined for ICE. For example:
skipping to change at page 11, line 29 skipping to change at page 12, line 4
provides some abstraction, but can be easily converted to and from provides some abstraction, but can be easily converted to and from
the SDP candidate lines. the SDP candidate lines.
The candidate lines are the only SDP information that is contained The candidate lines are the only SDP information that is contained
within IceCandidate, as they represent the only information needed within IceCandidate, as they represent the only information needed
that is not present in the initial offer (i.e., for trickle that is not present in the initial offer (i.e., for trickle
candidates). This information is carried with the same syntax as the candidates). This information is carried with the same syntax as the
"candidate-attribute" field defined for ICE. For example: "candidate-attribute" field defined for ICE. For example:
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
The IceCandidate object also contains fields to indicate which m= The IceCandidate object also contains fields to indicate which m=
line it should be associated with. The m line can be identified in line it should be associated with. The m= line can be identified in
one of two ways; either by a m-line index, or a MID. The m-line one of two ways; either by a m= line index, or a MID. The m= line
index is a zero-based index, with index N referring to the N+1th index is a zero-based index, with index N referring to the N+1th m=
m-line in the SDP sent by the entity which sent the IceCandidate. line in the SDP sent by the entity which sent the IceCandidate. The
The MID uses the "media stream identification", as defined in MID uses the "media stream identification" attribute, as defined in
[RFC5888], to identify the m-line. WebRTC implementations creating [RFC5888], Section 4, to identify the m= line. JSEP implementations
an ICE Candidate object MUST populate both of these fields. creating an ICE Candidate object MUST populate both of these fields.
Implementations receiving an ICE Candidate object SHOULD use the MID Implementations receiving an ICE Candidate object MUST use the MID if
if they implement that functionality, or the m-line index, if not. present, or the m= line index, if not (as it could have come from a
non-JSEP endpoint).
3.4.2. ICE Candidate Pool 3.4.3. ICE Candidate Policy
Typically, when gathering ICE candidates, the browser will gather all
possible forms of initial candidates - host, server reflexive, and
relay. However, in certain cases, applications may want to have more
specific control over the gathering process, due to privacy or
related concerns. For example, one may want to suppress the use of
host candidates, to avoid exposing information about the local
network, or go as far as only using relay candidates, to leak as
little location information as possible (note that these choices come
with corresponding operational costs). To accomplish this, the
browser MUST allow the application to restrict which ICE candidates
are used in a session. In addition, administrators may also wish to
control the set of ICE candidates, and so the browser SHOULD also
allow control via local policy, with the most restrictive policy
prevailing.
There may also be cases where the application wants to change which
types of candidates are used while the session is active. A prime
example is where a callee may initially want to use only relay
candidates, to avoid leaking location information to an arbitrary
caller, but then change to use all candidates (for lower operational
cost) once the user has indicated they want to take the call. For
this scenario, the browser MUST allow the candidate policy to be
changed in mid-session, subject to the aforementioned interactions
with local policy.
To administer the ICE candidate policy, the browser will determine
the current setting at the start of each gathering phase. Then,
during the gathering phase, the browser MUST NOT expose candidates
disallowed by the current policy to the application, use them as the
source of connectivity checks, or indirectly expose them via other
fields, such as the raddr/rport attributes for other ICE candidates.
Later, if a different policy is specified by the application, the
application can apply it by kicking off a new gathering phase via an
ICE restart.
3.4.4. ICE Candidate Pool
JSEP applications typically inform the browser to begin ICE gathering JSEP applications typically inform the browser to begin ICE gathering
via the information supplied to setLocalDescription, as this is where via the information supplied to setLocalDescription, as this is where
the app specifies the number of media streams for which to gather the app specifies the number of media streams, and thereby ICE
candidates. However, to accelerate cases where the application knows components, for which to gather candidates. However, to accelerate
the number of media streams to use ahead of time, it MAY ask the cases where the application knows the number of ICE components to use
browser to gather a pool of potential ICE candidates to help ensure ahead of time, it may ask the browser to gather a pool of potential
rapid media setup. When setLocalDescription is eventually called, ICE candidates to help ensure rapid media setup.
and the browser goes to gather the needed ICE candidates, it SHOULD
start by checking if any candidates are available in the pool. If When setLocalDescription is eventually called, and the browser goes
there are candidates in the pool, they SHOULD be handed to the to gather the needed ICE candidates, it SHOULD start by checking if
application immediately via the ICE candidate callback. If the pool any candidates are available in the pool. If there are candidates in
becomes depleted, either because a larger-than-expected number of the pool, they SHOULD be handed to the application immediately via
media streams is used, or because the pool has not had enough time to the ICE candidate callback. If the pool becomes depleted, either
gather candidates, the remaining candidates are gathered as usual. because a larger-than-expected number of ICE components is used, or
because the pool has not had enough time to gather candidates, the
remaining candidates are gathered as usual.
One example of where this concept is useful is an application that
expects an incoming call at some point in the future, and wants to
minimize the time it takes to establish connectivity, to avoid
clipping of initial media. By pre-gathering candidates into the
pool, it can exchange and start sending connectivity checks from
these candidates almost immediately upon receipt of a call. Note
though that by holding on to these pre-gathered candidates, which
will be kept alive as long as they may be needed, the application
will consume resources on the STUN/TURN servers it is using.
3.5. Interactions With Forking 3.5. Interactions With Forking
Some call signaling systems allow various types of forking where an Some call signaling systems allow various types of forking where an
SDP Offer may be provided to more than one device. For example, SIP SDP Offer may be provided to more than one device. For example, SIP
[RFC3261] defines both a "Parallel Search" and "Sequential Search". [RFC3261] defines both a "Parallel Search" and "Sequential Search".
Although these are primarily signaling level issues that are outside Although these are primarily signaling level issues that are outside
the scope of JSEP, they do have some impact on the configuration of the scope of JSEP, they do have some impact on the configuration of
the media plane that is relevant. When forking happens at the the media plane that is relevant. When forking happens at the
signaling layer, the Javascript application responsible for the signaling layer, the Javascript application responsible for the
signaling needs to make the decisions about what media should be sent signaling needs to make the decisions about what media should be sent
or received at any point of time, as well as which remote endpoint it or received at any point of time, as well as which remote endpoint it
should communicate with; JSEP is used to make sure the media engine should communicate with; JSEP is used to make sure the media engine
can make the RTP and media perform as required by the application. can make the RTP and media perform as required by the application.
The basic operations that the applications can have the media engine The basic operations that the applications can have the media engine
do are: do are:
o Start exchanging media to a given remote peer, but keep all the
o Start exchanging media with a given remote peer, but keep all the
resources reserved in the offer. resources reserved in the offer.
o Start exchanging media with a given remote peer, and free any o Start exchanging media with a given remote peer, and free any
resources in the offer that are not being used. resources in the offer that are not being used.
3.5.1. Sequential Forking 3.5.1. Sequential Forking
Sequential forking involves a call being dispatched to multiple Sequential forking involves a call being dispatched to multiple
remote callees, where each callee can accept the call, but only one remote callees, where each callee can accept the call, but only one
active session ever exists at a time; no mixing of received media is active session ever exists at a time; no mixing of received media is
performed. performed.
skipping to change at page 14, line 11 skipping to change at page 15, line 34
implement JSEP functionality. The actual API exposed in the W3C API implement JSEP functionality. The actual API exposed in the W3C API
may have somewhat different syntax, but should map easily to these may have somewhat different syntax, but should map easily to these
concepts. concepts.
4.1. Methods 4.1. Methods
4.1.1. Constructor 4.1.1. Constructor
The PeerConnection constructor allows the application to specify The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN global parameters for the media session, such as the STUN/TURN
servers and credentials to use when gathering candidates. The size servers and credentials to use when gathering candidates, as well as
of the ICE candidate pool can also be set, if desired; this indicates the initial ICE candidate policy and pool size, and also the BUNDLE
the number of ICE components to pre-gather candidates for. If the policy to use.
application does not indicate a candidate pool size, the browser may
select any default candidate pool size.
In addition, the application can specify its preferred policy If an ICE candidate policy is specified, it functions as described in
regarding use of BUNDLE, the multiplexing mechanism defined in Section 3.4.3, causing the browser to only surface the permitted
candidates to the application, and only use those candidates for
connectivity checks. The set of available policies is as follows:
all: All candidates will be gathered and used.
public: Candidates with private IP addresses [RFC1918] will be
filtered out. This prevents exposure of internal network details,
at the cost of requiring relay usage even for intranet calls, if
the NAT does not allow hairpinning as described in [RFC4787],
section 6.
relay: All candidates except relay candidates will be filtered out.
This obfuscates the location information that might be ascertained
by the remote peer from the received candidates. Depending on how
the application deploys its relay servers, this could obfuscate
location to a metro or possibly even global level.
Although it can be overridden by local policy, the default ICE
candidate policy MUST be set to allow all candidates, as this
minimizes use of application STUN/TURN server resources.
If a size is specified for the ICE candidate pool, this indicates the
number of ICE components to pre-gather candidates for. Because pre-
gathering results in utilizing STUN/TURN server resources for
potentially long periods of time, this must only occur upon
application request, and therefore the default candidate pool size
MUST be zero.
Lastly, the application can specify its preferred policy regarding
use of BUNDLE, the multiplexing mechanism defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. By specifying a policy [I-D.ietf-mmusic-sdp-bundle-negotiation]. By specifying a policy
from the list below, the application can control how aggressively it from the list below, the application can control how aggressively it
will try to BUNDLE media streams together. The set of available will try to BUNDLE media streams together. The set of available
policies is as follows: policies is as follows:
balanced: The application will BUNDLE all media streams of the same balanced: The application will BUNDLE all media streams of the same
type together. That is, if there are multiple audio and multiple type together. That is, if there are multiple audio and multiple
video MediaStreamTracks attached to a PeerConnection, all but the video MediaStreamTracks attached to a PeerConnection, all but the
first audio and video tracks will be marked as bundle-only, and first audio and video tracks will be marked as bundle-only, and
candidates will only be gathered for N media streams, where N is candidates will only be gathered for N media streams, where N is
the number of distinct media types. When talking to a non-BUNDLE- the number of distinct media types. When talking to a non-BUNDLE-
aware endpoint, only the non-bundle-only streams will be aware endpoint, only the non-bundle-only streams will be
negotiated. This policy balances desire to multiplex with the negotiated. This policy balances desire to multiplex with the
need to ensure basic audio and video still works in legacy cases. need to ensure basic audio and video still works in legacy cases.
Data channels will be in a separate bundle group. Data channels will be in a separate bundle group.
skipping to change at page 14, line 34 skipping to change at page 16, line 40
type together. That is, if there are multiple audio and multiple type together. That is, if there are multiple audio and multiple
video MediaStreamTracks attached to a PeerConnection, all but the video MediaStreamTracks attached to a PeerConnection, all but the
first audio and video tracks will be marked as bundle-only, and first audio and video tracks will be marked as bundle-only, and
candidates will only be gathered for N media streams, where N is candidates will only be gathered for N media streams, where N is
the number of distinct media types. When talking to a non-BUNDLE- the number of distinct media types. When talking to a non-BUNDLE-
aware endpoint, only the non-bundle-only streams will be aware endpoint, only the non-bundle-only streams will be
negotiated. This policy balances desire to multiplex with the negotiated. This policy balances desire to multiplex with the
need to ensure basic audio and video still works in legacy cases. need to ensure basic audio and video still works in legacy cases.
Data channels will be in a separate bundle group. Data channels will be in a separate bundle group.
max-compat: The application will offer BUNDLE, but mark none of its
streams as bundle-only. This policy will allow all streams to be
received by non-BUNDLE-aware endpoints, but require separate
candidates to be gathered for each media stream.
max-bundle: The application will BUNDLE all of its media streams, max-bundle: The application will BUNDLE all of its media streams,
including data channels, on a single transport. All streams other including data channels, on a single transport. All streams other
than the first will be marked as bundle-only. This policy aims to than the first will be marked as bundle-only. This policy aims to
minimize candidate gathering and maximize multiplexing, at the minimize candidate gathering and maximize multiplexing, at the
cost of less compatibility with legacy endpoints. cost of less compatibility with legacy endpoints.
max-compat: The application will offer BUNDLE, but mark none of its max-bundle-and-rtcp-mux: Similar to max-bundle, but RTCP candidates
streams as bundle-only. This policy will allow all streams to be are not gathered. This policy reduces the candidates that must be
received by non-BUNDLE-aware endpoints, but require separate gathered to the absolute minimum, but will not be compatible with
candidates to be gathered for each media stream. legacy endpoints that do not support RTCP mux.
As it provides the best tradeoff between performance and
compatibility with legacy endpoints, the default BUNDLE policy MUST
be set to "balanced".
4.1.2. createOffer 4.1.2. createOffer
The createOffer method generates a blob of SDP that contains a The createOffer method generates a blob of SDP that contains a
[RFC3264] offer with the supported configurations for the session, [RFC3264] offer with the supported configurations for the session,
including descriptions of the local MediaStreams attached to this including descriptions of the local MediaStreams attached to this
PeerConnection, the codec/RTP/RTCP options supported by this PeerConnection, the codec/RTP/RTCP options supported by this
implementation, and any candidates that have been gathered by the ICE implementation, and any candidates that have been gathered by the ICE
Agent. An options parameter may be supplied to provide additional Agent. An options parameter may be supplied to provide additional
control over the generated offer. This options parameter should control over the generated offer. This options parameter should
skipping to change at page 16, line 34 skipping to change at page 19, line 12
currently available resources, it may need to be implemented as an currently available resources, it may need to be implemented as an
async operation. async operation.
Calling this method may do things such as generate new ICE Calling this method may do things such as generate new ICE
credentials, but does not trigger candidate gathering or change media credentials, but does not trigger candidate gathering or change media
state. state.
4.1.4. SessionDescriptionType 4.1.4. SessionDescriptionType
Session description objects (RTCSessionDescription) may be of type Session description objects (RTCSessionDescription) may be of type
"offer", "pranswer", and "answer". These types provide information "offer", "pranswer", or "answer". These types provide information as
as to how the description parameter should be parsed, and how the to how the description parameter should be parsed, and how the media
media state should be changed. state should be changed.
"offer" indicates that a description should be parsed as an offer; "offer" indicates that a description should be parsed as an offer;
said description may include many possible media configurations. A said description may include many possible media configurations. A
description used as an "offer" may be applied anytime the description used as an "offer" may be applied anytime the
PeerConnection is in a stable state, or as an update to a previously PeerConnection is in a stable state, or as an update to a previously
supplied but unanswered "offer". supplied but unanswered "offer".
"pranswer" indicates that a description should be parsed as an "pranswer" indicates that a description should be parsed as an
answer, but not a final answer, and so should not result in the answer, but not a final answer, and so should not result in the
freeing of allocated resources. It may result in the start of media freeing of allocated resources. It may result in the start of media
skipping to change at page 19, line 30 skipping to change at page 22, line 10
4.1.6. setRemoteDescription 4.1.6. setRemoteDescription
The setRemoteDescription method instructs the PeerConnection to apply The setRemoteDescription method instructs the PeerConnection to apply
the supplied SDP blob as the desired remote configuration. As in the supplied SDP blob as the desired remote configuration. As in
setLocalDescription, the type field of the indicates how the blob setLocalDescription, the type field of the indicates how the blob
should be processed. should be processed.
This API changes the local media state; among other things, it sets This API changes the local media state; among other things, it sets
up local resources for sending and encoding media. up local resources for sending and encoding media.
If setRemoteDescription was previously called with an offer, and If setLocalDescription was previously called with an offer, and
setLocalDescription is called with an answer (provisional or final), setRemoteDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission. send, this will result in the starting of media transmission.
4.1.7. localDescription 4.1.7. localDescription
The localDescription method returns a copy of the current local The localDescription method returns a copy of the current local
configuration, i.e. what was most recently passed to configuration, i.e. what was most recently passed to
setLocalDescription, plus any local candidates that have been setLocalDescription, plus any local candidates that have been
generated by the ICE Agent. generated by the ICE Agent.
[[OPEN ISSUE: Do we need to expose accessors for both the current [[OPEN ISSUE: Do we need to expose accessors for both the current and
and proposed local description? proposed local description? https://github.com/rtcweb-wg/jsep/
https://github.com/rtcweb-wg/jsep/issues/16]] issues/16]]
A null object will be returned if the local description has not yet A null object will be returned if the local description has not yet
been established, or if the PeerConnection has been closed. been established, or if the PeerConnection has been closed.
4.1.8. remoteDescription 4.1.8. remoteDescription
The remoteDescription method returns a copy of the current remote The remoteDescription method returns a copy of the current remote
configuration, i.e. what was most recently passed to configuration, i.e. what was most recently passed to
setRemoteDescription, plus any remote candidates that have been setRemoteDescription, plus any remote candidates that have been
supplied via processIceMessage. supplied via processIceMessage.
[[OPEN ISSUE: Do we need to expose accessors for both the current [[OPEN ISSUE: Do we need to expose accessors for both the current and
and proposed remote description? proposed remote description? https://github.com/rtcweb-wg/jsep/
https://github.com/rtcweb-wg/jsep/issues/16]] issues/16]]
A null object will be returned if the remote description has not yet A null object will be returned if the remote description has not yet
been established, or if the PeerConnection has been closed. been established, or if the PeerConnection has been closed.
4.1.9. updateIce 4.1.9. canTrickle
The updateIce method allows the configuration of the ICE Agent to be [[TODO: Revise if the W3C API uses different stuff here.]] The
changed during the session, primarily for changing which types of canTrickle property indicates whether the remote side supports
local candidates are provided to the application and used for receiving trickled candidates. There are three potential values:
connectivity checks. A callee may initially configure the ICE Agent
to use only relay candidates, to avoid leaking location information,
but update this configuration to use all candidates once the call is
accepted.
Regardless of the configuration, the gathering process collects all null: No SDP has been received from the other side, so it is not
available candidates, but excluded candidates will not be surfaced in known if it can handle trickle. This is the initial value before
onicecandidate callback or used for connectivity checks. setRemoteDescription() is called.
true: SDP has been received from the other side indicating that it
can support trickle.
false: SDP has been received from the other side indicating that it
cannot support trickle.
As described in Section 3.4.2, JSEP implementations always provide
candidates to the application individually, consistent with what is
needed for Trickle ICE. However, applications can use the canTrickle
property to determine whether they can actually do Trickle ICE, i.e.
safely send an initial offer or answer followed later by candidates
as they are gathered. As "true" is the only value that definitively
indicates remote Trickle ICE support, an application which compares
canTrickle against "true" will by default attempt Half Trickle on
initial offers and Full Trickle on subsequent interactions with a
Trickle ICE-compatible agent.
4.1.10. setConfiguration
The setConfiguration method allows the global configuration of the
PeerConnection, which was initially set by constructor parameters, to
be changed during the session. The effects of this method call
depend on when it is invoked, and differ depending on which specific
parameters are changed:
o Any changes to the STUN/TURN servers to use affect the next
gathering phase. If gathering has already occurred, this will
cause the next call to createOffer to generate new ICE
credentials, for the purpose of forcing an ICE restart and kicking
off a new gathering phase, in which the new servers will be used.
If the ICE candidate pool has a nonzero size, any existing
candidates will be discarded, and new candidates will be gathered
from the new servers.
o Any changes to the ICE candidate policy also affect the next
gathering phase, in similar fashion to the server changes
described above. Note though that changes to the policy have no
effect on the candidate pool, because pooled candidates are not
surfaced to the application until a gathering phase occurs, and so
any necessary filtering can still be done on any pooled
candidates.
o Any changes to the ICE candidate pool size take effect
immediately; if increased, additional candidates are pre-gathered;
if decreased, the now-superfluous candidates are discarded.
o Any changes to the BUNDLE policy take effect immediately, i.e.
any future tracks added to the PeerConnection will have their
bundle-only state marked accordingly.
This call may result in a change to the state of the ICE Agent, and This call may result in a change to the state of the ICE Agent, and
may result in a change to media state if it results in connectivity may result in a change to media state if it results in connectivity
being established. being established.
4.1.10. addIceCandidate 4.1.11. addIceCandidate
The addIceCandidate method provides a remote candidate to the ICE The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the remote Agent, which, if parsed successfully, will be added to the remote
description according to the rules defined for Trickle ICE. description according to the rules defined for Trickle ICE.
Connectivity checks will be sent to the new candidate. Connectivity checks will be sent to the new candidate.
This call will result in a change to the state of the ICE Agent, and This call will result in a change to the state of the ICE Agent, and
may result in a change to media state if it results in connectivity may result in a change to media state if it results in connectivity
being established. being established.
skipping to change at page 21, line 23 skipping to change at page 24, line 47
not support them. not support them.
The second set of specifications is the "mandatory-to-use" set. The The second set of specifications is the "mandatory-to-use" set. The
local JSEP endpoint and any remote endpoint must indicate support for local JSEP endpoint and any remote endpoint must indicate support for
these specifications in their session descriptions. these specifications in their session descriptions.
5.1.1. Implementation Requirements 5.1.1. Implementation Requirements
This list of mandatory-to-implement specifications is derived from This list of mandatory-to-implement specifications is derived from
the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. the requirements outlined in [I-D.ietf-rtcweb-rtp-usage].
R-1 [RFC4566] is the base SDP specification and MUST be R-1 [RFC4566] is the base SDP specification and MUST be
implemented. implemented.
R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF
RTP profile. [RFC5764] and TCP/TLS/RTP/SAVPF
[I-D.nandakumar-mmusic-proto-iana-registration] RTP profiles.
R-3 [RFC5245] MUST be implemented for signaling the ICE credentials R-3 [RFC5245] MUST be implemented for signaling the ICE credentials
and candidate lines corresponding to each media stream. The and candidate lines corresponding to each media stream. The
ICE implementation MUST be a Full implementation, not a Lite ICE implementation MUST be a Full implementation, not a Lite
implementation. implementation.
R-4 [RFC5763] MUST be implemented to signal DTLS certificate R-4 [RFC5763] MUST be implemented to signal DTLS certificate
fingerprints. fingerprints.
R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying
information. information.
R-6 The [RFC5888] grouping framework MUST be implemented for R-6 The [RFC5888] grouping framework MUST be implemented for
signaling grouping information, and MUST be used to identify m= signaling grouping information, and MUST be used to identify m=
lines via the a=mid attribute. lines via the a=mid attribute.
R-7 [I-D.ietf-mmusic-msid] MUST be supported, in order to signal R-7 [I-D.ietf-mmusic-msid] MUST be supported, in order to signal
associations between RTP objects and W3C MediaStreams and associations between RTP objects and W3C MediaStreams and
MediaStreamTracks in a standard way. MediaStreamTracks in a standard way.
R-8 The bundle mechanism in R-8 The bundle mechanism in
[I-D.ietf-mmusic-sdp-bundle-negotiation] MUST be supported to [I-D.ietf-mmusic-sdp-bundle-negotiation] MUST be supported to
signal the ability to multiplex RTP streams on a single UDP signal the ability to multiplex RTP streams on a single UDP
port, in order to avoid excessive use of port number resources. port, in order to avoid excessive use of port number resources.
R-9 The SDP attributes of "sendonly", "recvonly", "inactive", and R-9 The SDP attributes of "sendonly", "recvonly", "inactive", and
"sendrecv" from [RFC4566] MUST be implemented to signal "sendrecv" from [RFC4566] MUST be implemented to signal
information about media direction. information about media direction.
R-10 [RFC5576] MUST be implemented to signal RTP SSRC values. R-10 [RFC5576] MUST be implemented to signal RTP SSRC values.
R-11 [RFC4585] MUST be implemented to signal RTCP based feedback. R-11 [RFC4585] MUST be implemented to signal RTCP based feedback.
R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and
RTCP. RTCP.
R-13 [RFC5506] MUST be implemented to signal reduced-size RTCP R-13 [RFC5506] MUST be implemented to signal reduced-size RTCP
messages. messages.
R-14 [RFC3556] with bandwidth modifiers MAY be supported for R-14 [RFC3556] with bandwidth modifiers MAY be supported for
specifying RTCP bandwidth as a fraction of the media bandwidth, specifying RTCP bandwidth as a fraction of the media bandwidth,
RTCP fraction allocated to the senders and setting maximum RTCP fraction allocated to the senders and setting maximum
media bit-rate boundaries. media bit-rate boundaries.
As required by [RFC4566], Section 5.13, JSEP implementations MUST As required by [RFC4566], Section 5.13, JSEP implementations MUST
ignore unknown attribute (a=) lines. ignore unknown attribute (a=) lines.
5.1.2. Usage Requirements 5.1.2. Usage Requirements
skipping to change at page 22, line 23 skipping to change at page 26, line 13
media bit-rate boundaries. media bit-rate boundaries.
As required by [RFC4566], Section 5.13, JSEP implementations MUST As required by [RFC4566], Section 5.13, JSEP implementations MUST
ignore unknown attribute (a=) lines. ignore unknown attribute (a=) lines.
5.1.2. Usage Requirements 5.1.2. Usage Requirements
All session descriptions handled by JSEP endpoints, both local and All session descriptions handled by JSEP endpoints, both local and
remote, MUST indicate support for the following specifications. If remote, MUST indicate support for the following specifications. If
any of these are absent, this omission MUST be treated as an error. any of these are absent, this omission MUST be treated as an error.
R-1 Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP
profile, as specified in [RFC5764], MUST be used. R-1 ICE, as specified in [RFC5245], MUST be used. Note that the
R-2 ICE, as specified in [RFC5245], MUST be used. Note that the
remote endpoint may use a Lite implementation; implementations remote endpoint may use a Lite implementation; implementations
MUST properly handle remote endpoints which do ICE-Lite. MUST properly handle remote endpoints which do ICE-Lite.
R-3 DTLS-SRTP, as specified in [RFC5763], MUST be used.
R-2 DTLS-SRTP, as specified in [RFC5763], MUST be used.
5.1.3. Profile Names and Interoperability
For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/
RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of
these two profiles for each media m= line they produce in an offer.
For data m= sections, JSEP endpoints must support both the "UDP/TLS/
SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two
profiles for each data m= line they produce in an offer. Because ICE
can select either TCP or UDP transport depending on network
conditions, both advertisements are consistent with ICE eventually
selecting either either UDP or TCP.
Unfortunately, in an attempt at compatibility, some endpoints
generate other profile strings even when they mean to support one of
these profiles. For instance, an endpoint might generate "RTP/AVP"
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its
willingness to support "(UDP,TCP)/TLS/RTP/SAVPF". In order to
simplify compatibility with such endpoints, JSEP endpoints MUST
follow the following rules when processing the media m= sections in
an offer:
o The profile in any "m=" line in any answer MUST exactly match the
profile provided in the offer.
o Any profile matching the following patterns MUST be accepted:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"
o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no
effect; support for DTLS-SRTP is determined by the presence of the
"a=fingerprint" attribute. Note that lack of an "a=fingerprint"
attribute will lead to negotiation failure.
o The use of AVPF or AVP simply controls the timing rules used for
RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute
is present, assume AVPF timing, i.e. a default value of "trr-
int=0". Otherwise, assume that AVPF is being used in an AVP
compatible mode and use AVP timing, i.e., "trr-int=4".
o For data m= sections, JSEP endpoints MUST support receiving the
"UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles.
Note that re-offers by JSEP endpoints MUST use the correct profile
strings even if the initial offer/answer exchange used an (incorrect)
older profile string.
5.2. Constructing an Offer 5.2. Constructing an Offer
When createOffer is called, a new SDP description must be created When createOffer is called, a new SDP description must be created
that includes the functionality specified in that includes the functionality specified in
[I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are
explained below. explained below.
5.2.1. Initial Offers 5.2.1. Initial Offers
skipping to change at page 24, line 10 skipping to change at page 29, line 8
without bundling them. without bundling them.
For DTLS, all m= sections MUST use the certificate for the identity For DTLS, all m= sections MUST use the certificate for the identity
that has been specified for the PeerConnection; as a result, they that has been specified for the PeerConnection; as a result, they
MUST all have the same [RFC4572] fingerprint value, or this value MUST all have the same [RFC4572] fingerprint value, or this value
MUST be a session-level attribute. MUST be a session-level attribute.
Each m= section should be generated as specified in [RFC4566], Each m= section should be generated as specified in [RFC4566],
Section 5.14. For the m= line itself, the following rules MUST be Section 5.14. For the m= line itself, the following rules MUST be
followed: followed:
o The port value is set to the port of the default ICE candidate for o The port value is set to the port of the default ICE candidate for
this m= section; if this m= section is not being bundled into this m= section, but given that no candidates have yet been
another m= section, the port value MUST be unique. If no gathered, the "dummy" port value of 9 (Discard) MUST be used, as
candidates have yet been gathered, and a 'null' port value is indicated in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
being used, as indicated in [I-D.ietf-mmusic-trickle-ice], Section
5.1., this port MUST still be unique.
o To properly indicate use of DTLS, the <proto> field MUST be set to o To properly indicate use of DTLS, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the
default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as
specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the
default candidate uses TCP transport.
The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP6 ::",
as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
Each m= section MUST include the following attribute lines: Each m= section MUST include the following attribute lines:
o An "a=mid" line, as specified in [RFC5888], Section 4.
o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section o An "a=mid" line, as specified in [RFC5888], Section 4. When
2. generating mid values, it is RECOMMENDED that the values be 3
o [OPEN ISSUE: Use of AppID] bytes or less, to allow them to efficiently fit into the RTP
header extension defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP6 ::", because no candidates
have yet been gathered.
o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
Section 2.
o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1. o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1.
o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in [RFC4566], Section 6. For audio, the codecs specified in [RFC4566], Section 6. For audio, the codecs
specified in [I-D.ietf-rtcweb-audio], Section 3, MUST be be specified in [I-D.ietf-rtcweb-audio], Section 3, MUST be be
supported. supported.
o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6.
o For each primary codec where RTP retransmission should be used, a o For each primary codec where RTP retransmission should be used, a
corresponding "a=rtpmap" line indicating "rtx" with the clock rate corresponding "a=rtpmap" line indicating "rtx" with the clock rate
of the primary codec and an "a=fmtp" line that references the of the primary codec and an "a=fmtp" line that references the
payload type of the primary codec, as specified in [RFC4588], payload type of the primary codec, as specified in [RFC4588],
Section 8.1. Section 8.1.
o For each supported FEC mechanism, a corresponding "a=rtpmap" line o For each supported FEC mechanism, a corresponding "a=rtpmap" line
indicating the desired FEC codec. indicating the desired FEC codec.
o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245],
Section 15.4. Section 15.4.
o An "a=ice-options" line, with the "trickle" option, as specified o An "a=ice-options" line, with the "trickle" option, as specified
in [I-D.ietf-mmusic-trickle-ice], Section 4. in [I-D.ietf-mmusic-trickle-ice], Section 4.
o For each candidate that has been gathered during the most recent
gathering phase, an "a=candidate" line, as specified in [RFC5245],
Section 4.3., paragraph 3.
o For the current default candidate, a "c=" line, as specified in
[RFC5245], Section 4.3., paragraph 6. If no candidates have been
gathered yet, the default candidate should be set to the 'null'
value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the
algorithm used for the fingerprint MUST match that used in the algorithm used for the fingerprint MUST match that used in the
certificate signature. certificate signature.
o An "a=setup" line, as specified in [RFC4145], Section 4, and o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the offer MUST be "actpass". The role value in the offer MUST be "actpass".
o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1. o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1.
o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
o For each supported RTP header extension, an "a=extmap" line, as o For each supported RTP header extension, an "a=extmap" line, as
specified in [RFC5285], Section 5. The list of header extensions specified in [RFC5285], Section 5. The list of header extensions
that SHOULD/MUST be supported is specified in that SHOULD/MUST be supported is specified in
[I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions [I-D.ietf-rtcweb-rtp-usage], Section 5.2. [TODO: ensure that
that require encryption MUST be specified as indicated in urn:ietf:params:rtp-hdrext:sdes:mid appears either there or here]
[RFC6904], Section 4. Any header extensions that require encryption MUST be specified as
indicated in [RFC6904], Section 4.
o For each supported RTCP feedback mechanism, an "a=rtcp-fb" o For each supported RTCP feedback mechanism, an "a=rtcp-fb"
mechanism, as specified in [RFC4585], Section 4.2. The list of mechanism, as specified in [RFC4585], Section 4.2. The list of
RTCP feedback mechanisms that SHOULD/MUST be supported is RTCP feedback mechanisms that SHOULD/MUST be supported is
specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1.
o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, o An "a=ssrc" line, as specified in [RFC5576], Section 4.1,
indicating the SSRC to be used for sending media, along with the indicating the SSRC to be used for sending media, along with the
mandatory "cname" source attribute, as specified in Section 6.1, mandatory "cname" source attribute, as specified in Section 6.1,
indicating the CNAME for the source. The CNAME must be generated indicating the CNAME for the source. The CNAME must be generated
in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs
specified for MSTs? Are they randomly generated for each specified for MSTs? Are they randomly generated for each
MediaStream? If so, can two MediaStreams be synced? See: MediaStream? If so, can two MediaStreams be synced? See:
https://github.com/rtcweb-wg/jsep/issues/4] https://github.com/rtcweb-wg/jsep/issues/4]
o If RTX is supported for this media type, another "a=ssrc" line o If RTX is supported for this media type, another "a=ssrc" line
with the RTX SSRC, and an "a=ssrc-group" line, as specified in with the RTX SSRC, and an "a=ssrc-group" line, as specified in
[RFC5576], section 4.2, with semantics set to "FID" and including [RFC5576], section 4.2, with semantics set to "FID" and including
the primary and RTX SSRCs. the primary and RTX SSRCs.
o If FEC is supported for this media type, another "a=ssrc" line o If FEC is supported for this media type, another "a=ssrc" line
with the FEC SSRC, and an "a=ssrc-group" line, as specified in with the FEC SSRC, and an "a=ssrc-group" line, as specified in
[RFC5576], section 4.2, with semantics set to "FEC" and including [RFC5576], section 4.2, with semantics set to "FEC" and including
the primary and FEC SSRCs. the primary and FEC SSRCs.
o [OPEN ISSUE: Handling of a=imageattr]
o [OPEN ISSUE: Handling of a=imageattr]
o If the BUNDLE policy for this PeerConnection is set to "max- o If the BUNDLE policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the BUNDLE bundle", and this is not the first m= section, or the BUNDLE
policy is set to "default", and this is not the first m= section policy is set to "balanced", and this is not the first m= section
for this media type, an "a=bundle-only" line. for this media type, an "a=bundle-only" line.
Lastly, if a data channel has been created, a m= section MUST be Lastly, if a data channel has been created, a m= section MUST be
generated for data. The <media> field MUST be set to "application" generated for data. The <media> field MUST be set to "application"
and the <proto> field MUST be set to "DTLS/SCTP", as specified in and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default
[I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to candidate uses UDP transport, or "TCP/TLS/SCTP" if the default
the SCTP port number, as specified in Section 4.1. candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt"
value MUST be set to the SCTP port number, as specified in
Section 4.1. [TODO: update this to use a=sctp-port, as indicated in
the latest data channel docs]
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-
passwd", "a=ice-options", "a=candidate", "a=fingerprint", and passwd", "a=ice-options", "a=candidate", "a=fingerprint", and
"a=setup" lines MUST be included as mentioned above, along with an "a=setup" lines MUST be included as mentioned above, along with an
"a=sctpmap" line referencing the SCTP port number and specifying the "a=sctpmap" line referencing the SCTP port number and specifying the
application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. application protocol indicated in [I-D.ietf-rtcweb-data-protocol].
[OPEN ISSUE: the -01 of this document is missing this information.]
[OPEN ISSUE: the -01 of this document is missing this information.]
Once all m= sections have been generated, a session-level "a=group" Once all m= sections have been generated, a session-level "a=group"
attribute MUST be added as specified in [RFC5888]. This attribute attribute MUST be added as specified in [RFC5888]. This attribute
MUST have semantics "BUNDLE", and MUST include the mid identifiers of MUST have semantics "BUNDLE", and MUST include the mid identifiers of
each m= section. The effect of this is that the browser offers all each m= section. The effect of this is that the browser offers all
m= sections as one BUNDLE group. However, whether the m= sections m= sections as one BUNDLE group. However, whether the m= sections
are bundle-only or not depends on the BUNDLE policy. are bundle-only or not depends on the BUNDLE policy.
Attributes which SDP permits to either be at the session level or the Attributes which SDP permits to either be at the session level or the
media level SHOULD generally be at the media level even if they are media level SHOULD generally be at the media level even if they are
skipping to change at page 27, line 7 skipping to change at page 32, line 43
o The fields of the "o=" line MUST stay the same except for the o The fields of the "o=" line MUST stay the same except for the
<session-version> field, which MUST increment if the session <session-version> field, which MUST increment if the session
description changes in any way, including the addition of ICE description changes in any way, including the addition of ICE
candidates. candidates.
If the initial offer was applied using setLocalDescription, but an If the initial offer was applied using setLocalDescription, but an
answer from the remote side has not yet been applied, meaning the answer from the remote side has not yet been applied, meaning the
PeerConnection is still in the "local-offer" state, an offer is PeerConnection is still in the "local-offer" state, an offer is
generated by following the steps in the "stable" state above, along generated by following the steps in the "stable" state above, along
with these exceptions: with these exceptions:
o The "s=" and "t=" lines MUST stay the same. o The "s=" and "t=" lines MUST stay the same.
o Each "m=" and c=" line MUST be filled in with the port and address
of the default candidate for the m= section, as described in
[RFC5245], Section 4.3. Each "a=rtcp" attribute line MUST also be
filled in with the port and address of the appropriate default
candidate, either the default RTP or RTCP candidate, depending on
whether RTCP multiplexing is currently active or not. Note that
if RTCP multiplexing is being offered, but not yet active, the
default RTCP candidate MUST be used, as indicated in [RFC5761],
section 5.1.3. In each case, if no candidates of the desired type
have yet been gathered, dummy values MUST be used, as described
above. [TODO: update profile UDP/TCP per default candidate]
o Each "a=mid" line MUST stay the same. o Each "a=mid" line MUST stay the same.
o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless
the "IceRestart" option (Section 5.2.3 was specified. Note that o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
it's not clear why you would actually want to do this, since at the ICE configuration has changed (either changes to the supported
this point ICE has not yet started and is thus unlikely to need a STUN/TURN servers, or the ICE candidate policy), or the
restart. "IceRestart" option (Section 5.2.3.3 was specified.
o Within each m= section, for each candidate that has been gathered
during the most recent gathering phase (see Section 3.4.1), an
"a=candidate" line MUST be added, as specified in [RFC5245],
Section 4.3., paragraph 3. If candidate gathering for the section
has completed, an "a=end-of-candidates" attribute MUST be added,
as described in [I-D.ietf-mmusic-trickle-ice], Section 9.3.
o For MediaStreamTracks that are still present, the "a=msid", o For MediaStreamTracks that are still present, the "a=msid",
"a=ssrc", and "a=ssrc-group" lines MUST stay the same. "a=ssrc", and "a=ssrc-group" lines MUST stay the same.
o If any MediaStreamTracks have been removed, either through the o If any MediaStreamTracks have been removed, either through the
removeStream method or by removing them from an added MediaStream, removeStream method or by removing them from an added MediaStream,
their m= sections MUST be marked as recvonly by changing the value their m= sections MUST be marked as recvonly by changing the value
of the [RFC3264] directional attribute to "a=recvonly". The of the [RFC3264] directional attribute to "a=recvonly". The
"a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed from "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed from
the associated m= sections. the associated m= sections.
o If any MediaStreamTracks have been added, and there exist m= o If any MediaStreamTracks have been added, and there exist m=
sections of the appropriate media type with no associated sections of the appropriate media type with no associated
MediaStreamTracks (i.e. as described in the preceding paragraph), MediaStreamTracks (i.e. as described in the preceding paragraph),
those m= sections MUST be recycled by adding the new those m= sections MUST be recycled by adding the new
MediaStreamTrack to the m= section. This is done by adding the MediaStreamTrack to the m= section. This is done by adding the
necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the
recycled m= section, and removing the "a=recvonly" attribute. recycled m= section, and removing the "a=recvonly" attribute.
If the initial offer was applied using setLocalDescription, and an If the initial offer was applied using setLocalDescription, and an
answer from the remote side has been applied using answer from the remote side has been applied using
skipping to change at page 27, line 35 skipping to change at page 33, line 47
those m= sections MUST be recycled by adding the new those m= sections MUST be recycled by adding the new
MediaStreamTrack to the m= section. This is done by adding the MediaStreamTrack to the m= section. This is done by adding the
necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the
recycled m= section, and removing the "a=recvonly" attribute. recycled m= section, and removing the "a=recvonly" attribute.
If the initial offer was applied using setLocalDescription, and an If the initial offer was applied using setLocalDescription, and an
answer from the remote side has been applied using answer from the remote side has been applied using
setRemoteDescription, meaning the PeerConnection is in the "remote- setRemoteDescription, meaning the PeerConnection is in the "remote-
pranswer" or "stable" states, an offer is generated based on the pranswer" or "stable" states, an offer is generated based on the
negotiated session descriptions by following the steps mentioned for negotiated session descriptions by following the steps mentioned for
the "local-offer" state above, along with these exceptions: [OPEN the "local-offer" state above, along with these exceptions: [OPEN
ISSUE: should this be permitted in the remote-pranswer state?] ISSUE: should this be permitted in the remote-pranswer state?]
o If a m= section exists in the current local description, but does o If a m= section exists in the current local description, but does
not have an associated local MediaStreamTrack (possibly because not have an associated local MediaStreamTrack (possibly because
said MediaStreamTrack was removed since the last exchange), a m= said MediaStreamTrack was removed since the last exchange), a m=
section MUST still be generated in the new offer, as indicated in section MUST still be generated in the new offer, as indicated in
[RFC3264], Section 8. The disposition of this section will depend [RFC3264], Section 8. The disposition of this section will depend
on the state of the remote MediaStreamTrack associated with this on the state of the remote MediaStreamTrack associated with this
m= section. If one exists, and it is still in the "live" state, m= section. If one exists, and it is still in the "live" state,
the new m= section MUST be marked as "a=recvonly", with no the new m= section MUST be marked as "a=recvonly", with no
"a=msid" or related attributes present. If no remote "a=msid" or related attributes present. If no remote
MediaStreamTrack exists, or it is in the "ended" state, the m= MediaStreamTrack exists, or it is in the "ended" state, the m=
skipping to change at page 28, line 39 skipping to change at page 35, line 14
5.2.3. Options Handling 5.2.3. Options Handling
The createOffer method takes as a parameter an RTCOfferOptions The createOffer method takes as a parameter an RTCOfferOptions
object. Special processing is performed when generating a SDP object. Special processing is performed when generating a SDP
description if the following constraints are present. description if the following constraints are present.
5.2.3.1. OfferToReceiveAudio 5.2.3.1. OfferToReceiveAudio
If the "OfferToReceiveAudio" option is specified, with an integer If the "OfferToReceiveAudio" option is specified, with an integer
value of N, the offer MUST include N non-rejected m= sections with value of N, and M audio MediaStreamTracks have been added to the
media type "audio", even if fewer than N audio MediaStreamTracks have PeerConnection, the offer MUST include N non-rejected m= sections
been added to the PeerConnection. This allows the offerer to receive with media type "audio", even if N is greater than M. This allows
audio, including multiple independent streams, even when not sending the offerer to receive audio, including multiple independent streams,
it; accordingly, the directional attribute on the audio m= sections even when not sending it; accordingly, the directional attribute on
without associated MediaStreamTracks MUST be set to recvonly. If the N-M audio m= sections without associated MediaStreamTracks MUST
this option is specified in the case where at least N audio be set to recvonly.
MediaStreamTracks have already been added to the PeerConnection, or N
non-rejected m= sections with media type "audio" would otherwise be If N is set to a value less than M, the offer MUST mark the m=
generated, it has no effect. For backwards compatibility, a value of sections associated with the M-N most recently added (since the last
"true" is interpreted as equivalent to N=1. setLocalDescription) MediaStreamTracks as sendonly. This allows the
offerer to indicate that it does not want to receive audio on some or
all of its newly created streams. For m= sections that have
previously been negotiated, this setting has no effect. [TODO: refer
to RTCRtpSender in the future]
For backwards compatibility with pre-standard versions of this
specification, a value of "true" is interpreted as equivalent to N=1,
and "false" as N=0.
5.2.3.2. OfferToReceiveVideo 5.2.3.2. OfferToReceiveVideo
If the "OfferToReceiveVideo" option is specified, with an integer If the "OfferToReceiveVideo" option is specified, with an integer
value of N, the offer MUST include N non-rejected m= sections with value of N, and M video MediaStreamTracks have been added to the
media type "video", even if fewer than N video MediaStreamTracks have PeerConnection, the offer MUST include N non-rejected m= sections
been added to the PeerConnection. This allows the offerer to receive with media type "video", even if N is greater than M. This allows
video, including multiple independent streams, even when not sending the offerer to receive video, including multiple independent streams,
it; accordingly, the directional attribute on the video m= sections even when not sending it; accordingly, the directional attribute on
without associated MediaStreamTracks MUST be set to recvonly. If the N-M video m= sections without associated MediaStreamTracks MUST
this option is specified in the case where at least N video be set to recvonly.
MediaStreamTracks have already been added to the PeerConnection, or N
non-rejected m= sections with media type "video" would otherwise be
generated, it has no effect. For backwards compatibility, a value of
"true" is interpreted as equivalent to N=1.
5.2.3.3. VoiceActivityDetection If N is set to a value less than M, the offer MUST mark the m=
sections associated with the M-N most recently added (since the last
setLocalDescription) MediaStreamTracks as sendonly. This allows the
offerer to indicate that it does not want to receive video on some or
all of its newly created streams. For m= sections that have
previously been negotiated, this setting has no effect. [TODO: refer
to RTCRtpSender in the future]
For backwards compatibility with pre-standard versions of this
specification, a value of "true" is interpreted as equivalent to N=1,
and "false" as N=0.
5.2.3.3. IceRestart
If the "IceRestart" option is specified, with a value of "true", the
offer MUST indicate an ICE restart by generating new ICE ufrag and
pwd attributes, as specified in [RFC5245], Section 9.1.1.1. If this
option is specified on an initial offer, it has no effect (since a
new ICE ufrag and pwd are already generated). Similarly, if the ICE
configuration has changed, this option has no effect, since new ufrag
and pwd attributes will be generated automatically. This option is
primarily useful for reestablishing connectivity in cases where
failures are detected by the application.
5.2.3.4. VoiceActivityDetection
If the "VoiceActivityDetection" option is specified, with a value of If the "VoiceActivityDetection" option is specified, with a value of
"true", the offer MUST indicate support for silence suppression in "true", the offer MUST indicate support for silence suppression in
the audio it receives by including comfort noise ("CN") codecs for the audio it receives by including comfort noise ("CN") codecs for
each offered audio codec, as specified in [RFC3389], Section 5.1, each offered audio codec, as specified in [RFC3389], Section 5.1,
except for codecs that have their own internal silence suppression except for codecs that have their own internal silence suppression
support. For codecs that have their own internal silence suppression support. For codecs that have their own internal silence suppression
support, the appropriate fmtp parameters for that codec MUST be support, the appropriate fmtp parameters for that codec MUST be
specified to indicate that silence suppression for received audio is specified to indicate that silence suppression for received audio is
desired. For example, when using the Opus codec, the "usedtx=1" desired. For example, when using the Opus codec, the "usedtx=1"
parameter would be specified in the offer. This option allows the parameter would be specified in the offer. This option allows the
endpoint to significantly reduce the amount of audio bandwidth it endpoint to significantly reduce the amount of audio bandwidth it
receives, at the cost of some fidelity, depending on the quality of receives, at the cost of some fidelity, depending on the quality of
the remote VAD algorithm. the remote VAD algorithm.
5.2.3.4. IceRestart
If the "IceRestart" option is specified, with a value of "true", the
offer MUST indicate an ICE restart by generating new ICE ufrag and
pwd attributes, as specified in RFC5245, Section 9.1.1.1. If this
option is specified on an initial offer, it has no effect (since a
new ICE ufrag and pwd are already generated). This option is useful
for reestablishing connectivity in cases where failures are detected.
5.3. Generating an Answer 5.3. Generating an Answer
When createAnswer is called, a new SDP description must be created When createAnswer is called, a new SDP description must be created
that is compatible with the supplied remote description as well as that is compatible with the supplied remote description as well as
the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact
details of this process are explained below. details of this process are explained below.
5.3.1. Initial Answers 5.3.1. Initial Answers
When createAnswer is called for the first time after a remote When createAnswer is called for the first time after a remote
skipping to change at page 30, line 52 skipping to change at page 37, line 42
subsequent offer. subsequent offer.
For each offered m= section, if the associated remote For each offered m= section, if the associated remote
MediaStreamTrack has been stopped, and is therefore in state "ended", MediaStreamTrack has been stopped, and is therefore in state "ended",
and no local MediaStreamTrack has been associated, the corresponding and no local MediaStreamTrack has been associated, the corresponding
m= section in the answer MUST be marked as rejected by setting the m= section in the answer MUST be marked as rejected by setting the
port in the m= line to zero, as indicated in [RFC3264], Section 6., port in the m= line to zero, as indicated in [RFC3264], Section 6.,
and further processing for this m= section can be skipped. and further processing for this m= section can be skipped.
Provided that is not the case, each m= section in the answer should Provided that is not the case, each m= section in the answer should
then be generated as specified in [RFC3264], Section 6.1. Because then be generated as specified in [RFC3264], Section 6.1. For the m=
use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/ line itself, the following rules must be followed:
RTP/SAVPF". If the offer supports BUNDLE, all m= sections to be
BUNDLEd must use the same ICE credentials and candidates; all m= o The port value would normally be set to the port of the default
sections not being BUNDLEd must use unique ICE credentials and ICE candidate for this m= section, but given that no candidates
candidates. Each m= section MUST include the following: have yet been gathered, the "dummy" port value of 9 (Discard) MUST
be used, as indicated in [I-D.ietf-mmusic-trickle-ice],
Section 5.1.
o The <proto> field MUST be set to exactly match the <proto> field
for the corresponding m= line in the offer.
The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP6 ::",
as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
If the offer supports BUNDLE, all m= sections to be BUNDLEd must use
the same ICE credentials and candidates; all m= sections not being
BUNDLEd must use unique ICE credentials and candidates. Each m=
section MUST include the following:
o If present in the offer, an "a=mid" line, as specified in o If present in the offer, an "a=mid" line, as specified in
[RFC5888], Section 9.1. The "mid" value MUST match that specified [RFC5888], Section 9.1. The "mid" value MUST match that specified
in the offer. in the offer.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP6 ::", because no candidates
have yet been gathered.
o If a local MediaStreamTrack has been associated, an "a=msid" line, o If a local MediaStreamTrack has been associated, an "a=msid" line,
as specified in [I-D.ietf-mmusic-msid], Section 2. as specified in [I-D.ietf-mmusic-msid], Section 2.
o [OPEN ISSUE: Use of AppID]
o Depending on the directionality of the offer, the disposition of o Depending on the directionality of the offer, the disposition of
any associated remote MediaStreamTrack, and the presence of an any associated remote MediaStreamTrack, and the presence of an
associated local MediaStreamTrack, the appropriate directionality associated local MediaStreamTrack, the appropriate directionality
attribute, as specified in [RFC3264], Section 6.1. If the offer attribute, as specified in [RFC3264], Section 6.1. If the offer
was sendrecv, and the remote MediaStreamTrack is still "live", and was sendrecv, and the remote MediaStreamTrack is still "live", and
there is a local MediaStreamTrack that has been associated, the there is a local MediaStreamTrack that has been associated, the
directionality MUST be set as sendrecv. If the offer was directionality MUST be set as sendrecv. If the offer was
sendonly, and the remote MediaStreamTrack is still "live", the sendonly, and the remote MediaStreamTrack is still "live", the
directionality MUST be set as recvonly. If the offer was directionality MUST be set as recvonly. If the offer was
recvonly, and a local MediaStreamTrack has been associated, the recvonly, and a local MediaStreamTrack has been associated, the
skipping to change at page 31, line 27 skipping to change at page 38, line 41
associated local MediaStreamTrack, the appropriate directionality associated local MediaStreamTrack, the appropriate directionality
attribute, as specified in [RFC3264], Section 6.1. If the offer attribute, as specified in [RFC3264], Section 6.1. If the offer
was sendrecv, and the remote MediaStreamTrack is still "live", and was sendrecv, and the remote MediaStreamTrack is still "live", and
there is a local MediaStreamTrack that has been associated, the there is a local MediaStreamTrack that has been associated, the
directionality MUST be set as sendrecv. If the offer was directionality MUST be set as sendrecv. If the offer was
sendonly, and the remote MediaStreamTrack is still "live", the sendonly, and the remote MediaStreamTrack is still "live", the
directionality MUST be set as recvonly. If the offer was directionality MUST be set as recvonly. If the offer was
recvonly, and a local MediaStreamTrack has been associated, the recvonly, and a local MediaStreamTrack has been associated, the
directionality MUST be set as sendonly. If the offer was directionality MUST be set as sendonly. If the offer was
inactive, the directionality MUST be set as inactive. inactive, the directionality MUST be set as inactive.
o For each supported codec that is present in the offer, "a=rtpmap" o For each supported codec that is present in the offer, "a=rtpmap"
and "a=fmtp" lines, as specified in [RFC4566], Section 6, and and "a=fmtp" lines, as specified in [RFC4566], Section 6, and
[RFC3264], Section 6.1. For audio, the codecs specified in [RFC3264], Section 6.1. For audio, the codecs specified in
[I-D.ietf-rtcweb-audio], Section 3, MUST be supported. Note that [I-D.ietf-rtcweb-audio], Section 3, MUST be supported. Note that
for simplicity, the answerer MAY use different payload types for for simplicity, the answerer MAY use different payload types for
codecs than the offerer, as it is not prohibited by Section 6.1. codecs than the offerer, as it is not prohibited by Section 6.1.
o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6.
o If "rtx" is present in the offer, for each primary codec where RTP o If "rtx" is present in the offer, for each primary codec where RTP
retransmission should be used, a corresponding "a=rtpmap" line retransmission should be used, a corresponding "a=rtpmap" line
indicating "rtx" with the clock rate of the primary codec and an indicating "rtx" with the clock rate of the primary codec and an
"a=fmtp" line that references the payload type of the primary "a=fmtp" line that references the payload type of the primary
codec, as specified in [RFC4588], Section 8.1. codec, as specified in [RFC4588], Section 8.1.
o For each supported FEC mechanism that is present in the offer, a o For each supported FEC mechanism that is present in the offer, a
corresponding "a=rtpmap" line indicating the desired FEC codec. corresponding "a=rtpmap" line indicating the desired FEC codec.
o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245],
Section 15.4. Section 15.4.
o If the "trickle" ICE option is present in the offer, an "a=ice- o If the "trickle" ICE option is present in the offer, an "a=ice-
options" line, with the "trickle" option, as specified in options" line, with the "trickle" option, as specified in
[I-D.ietf-mmusic-trickle-ice], Section 4. [I-D.ietf-mmusic-trickle-ice], Section 4.
o For each candidate that has been gathered during the most recent
gathering phase, an "a=candidate" line, as specified in [RFC5245],
Section 4.3., paragraph 3.
o For the current default candidate, a "c=" line, as specified in
[RFC5245], Section 4.3., paragraph 6. If no candidates have been
gathered yet, the default candidate should be set to the 'null'
value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the
algorithm used for the fingerprint MUST match that used in the algorithm used for the fingerprint MUST match that used in the
certificate signature. certificate signature.
o An "a=setup" line, as specified in [RFC4145], Section 4, and o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the answer MUST be "active" or "passive"; the The role value in the answer MUST be "active" or "passive"; the
"active" role is RECOMMENDED. "active" role is RECOMMENDED.
o If present in the offer, an "a=rtcp-mux" line, as specified in o If present in the offer, an "a=rtcp-mux" line, as specified in
[RFC5761], Section 5.1.1. [RFC5761], Section 5.1.1.
o If present in the offer, an "a=rtcp-rsize" line, as specified in o If present in the offer, an "a=rtcp-rsize" line, as specified in
[RFC5506], Section 5. [RFC5506], Section 5.
o For each supported RTP header extension that is present in the o For each supported RTP header extension that is present in the
offer, an "a=extmap" line, as specified in [RFC5285], Section 5. offer, an "a=extmap" line, as specified in [RFC5285], Section 5.
The list of header extensions that SHOULD/MUST be supported is The list of header extensions that SHOULD/MUST be supported is
specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. [TODO:
extensions that require encryption MUST be specified as indicated Ensure this contains MID header] Any header extensions that
in [RFC6904], Section 4. require encryption MUST be specified as indicated in [RFC6904],
Section 4.
o For each supported RTCP feedback mechanism that is present in the o For each supported RTCP feedback mechanism that is present in the
offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585],
Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ Section 4.2. The list of RTCP feedback mechanisms that SHOULD/
MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage],
Section 5.1. Section 5.1.
o If a local MediaStreamTrack has been associated, an "a=ssrc" line, o If a local MediaStreamTrack has been associated, an "a=ssrc" line,
as specified in [RFC5576], Section 4.1, indicating the SSRC to be as specified in [RFC5576], Section 4.1, indicating the SSRC to be
used for sending media. used for sending media.
o If a local MediaStreamTrack has been associated, and RTX has been o If a local MediaStreamTrack has been associated, and RTX has been
negotiated for this m= section, another "a=ssrc" line with the RTX negotiated for this m= section, another "a=ssrc" line with the RTX
SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], SSRC, and an "a=ssrc-group" line, as specified in [RFC5576],
section 4.2, with semantics set to "FID" and including the primary section 4.2, with semantics set to "FID" and including the primary
and RTX SSRCs. and RTX SSRCs.
o If a local MediaStreamTrack has been associated, and FEC has been o If a local MediaStreamTrack has been associated, and FEC has been
negotiated for this m= section, another "a=ssrc" line with the FEC negotiated for this m= section, another "a=ssrc" line with the FEC
SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], SSRC, and an "a=ssrc-group" line, as specified in [RFC5576],
section 4.2, with semantics set to "FEC" and including the primary section 4.2, with semantics set to "FEC" and including the primary
and FEC SSRCs. and FEC SSRCs.
o [OPEN ISSUE: Handling of a=imageattr]
o [OPEN ISSUE: Handling of a=imageattr]
If a data channel m= section has been offered, a m= section MUST also If a data channel m= section has been offered, a m= section MUST also
be generated for data. The <media> field MUST be set to be generated for data. The <media> field MUST be set to
"application" and the <proto> field MUST be set to "DTLS/SCTP", as "application" and the <proto> field MUST be set to exactly match the
specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value field in the offer; the "fmt" value MUST be set to the SCTP port
MUST be set to the SCTP port number, as specified in Section 4.1. number, as specified in Section 4.1. [TODO: update this to use
a=sctp-port, as indicated in the latest data channel docs]
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-
passwd", "a=ice-options", "a=candidate", "a=fingerprint", and passwd", "a=ice-options", "a=candidate", "a=fingerprint", and
"a=setup" lines MUST be included as mentioned above, along with an "a=setup" lines MUST be included as mentioned above, along with an
"a=sctpmap" line referencing the SCTP port number and specifying the "a=sctpmap" line referencing the SCTP port number and specifying the
application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. application protocol indicated in [I-D.ietf-rtcweb-data-protocol].
[OPEN ISSUE: the -01 of this document is missing this information.]
[OPEN ISSUE: the -01 of this document is missing this information.]
If "a=group" attributes with semantics of "BUNDLE" are offered, If "a=group" attributes with semantics of "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as corresponding session-level "a=group" attributes MUST be added as
specified in [RFC5888]. These attributes MUST have semantics specified in [RFC5888]. These attributes MUST have semantics
"BUNDLE", and MUST include the all mid identifiers from the offered "BUNDLE", and MUST include the all mid identifiers from the offered
BUNDLE groups that have not been rejected. Note that regardless of BUNDLE groups that have not been rejected. Note that regardless of
the presence of "a=bundle-only" in the offer, no m= sections in the the presence of "a=bundle-only" in the offer, no m= sections in the
answer should have an "a=bundle-only" line. answer should have an "a=bundle-only" line.
Attributes that are common between all m= sections MAY be moved to Attributes that are common between all m= sections MAY be moved to
skipping to change at page 33, line 22 skipping to change at page 41, line 4
the presence of "a=bundle-only" in the offer, no m= sections in the the presence of "a=bundle-only" in the offer, no m= sections in the
answer should have an "a=bundle-only" line. answer should have an "a=bundle-only" line.
Attributes that are common between all m= sections MAY be moved to Attributes that are common between all m= sections MAY be moved to
session-level, if explicitly defined to be valid at session-level. session-level, if explicitly defined to be valid at session-level.
The attributes prohibited in the creation of offers are also The attributes prohibited in the creation of offers are also
prohibited in the creation of answers. prohibited in the creation of answers.
5.3.2. Subsequent Answers 5.3.2. Subsequent Answers
5.3.3. Options Handling 5.3.3. Options Handling
The createOffer method takes as a parameter an RTCAnswerOptions
object. Special processing is performed when generating a SDP
description if the following constraints are present.
5.3.3.1. VoiceActivityDetection
Handling of the "VoiceActivityDetection" option in answers is the
same as is indicated for offers in Section 5.2.3.4.
5.4. Parsing an Offer 5.4. Parsing an Offer
5.5. Parsing an Answer 5.5. Parsing an Answer
5.6. Applying a Local Description 5.6. Applying a Local Description
5.7. Applying a Remote Description 5.7. Applying a Remote Description
6. Configurable SDP Parameters 6. Configurable SDP Parameters
skipping to change at page 33, line 40 skipping to change at page 41, line 30
5.7. Applying a Remote Description 5.7. Applying a Remote Description
6. Configurable SDP Parameters 6. Configurable SDP Parameters
It is possible to change elements in the SDP returned from It is possible to change elements in the SDP returned from
createOffer before passing it to setLocalDescription. When an createOffer before passing it to setLocalDescription. When an
implementation receives modified SDP it MUST either: implementation receives modified SDP it MUST either:
o Accept the changes and adjust its behavior to match the SDP. o Accept the changes and adjust its behavior to match the SDP.
o Reject the changes and return an error via the error callback. o Reject the changes and return an error via the error callback.
Changes MUST NOT be silently ignored. Changes MUST NOT be silently ignored.
The following elements of the SDP media description MUST NOT be The following elements of the SDP media description MUST NOT be
changed between the createOffer and the setLocalDescription, since changed between the createOffer and the setLocalDescription, since
they reflect transport attributes that are solely under browser they reflect transport attributes that are solely under browser
control, and the browser MUST NOT honor an attempt to change them: control, and the browser MUST NOT honor an attempt to change them:
o The number, type and port number of m-lines. o The number, type and port number of m= lines.
o The generated ICE credentials (a=ice-ufrag and a=ice-pwd). o The generated ICE credentials (a=ice-ufrag and a=ice-pwd).
o The set of ICE candidates and their parameters (a=candidate). o The set of ICE candidates and their parameters (a=candidate).
The following modifications, if done by the browser to a description The following modifications, if done by the browser to a description
between createOffer/createAnswer and the setLocalDescription, MUST be between createOffer/createAnswer and the setLocalDescription, MUST be
honored by the browser: honored by the browser:
o Remove or reorder codecs (m=) o Remove or reorder codecs (m=)
The following parameters may be controlled by constraints passed into The following parameters may be controlled by constraints passed into
createOffer/createAnswer. As an open issue, these changes may also createOffer/createAnswer. As an open issue, these changes may also
be be performed by manipulating the SDP returned from createOffer/ be be performed by manipulating the SDP returned from createOffer/
createAnswer, as indicated above, as long as the capabilities of the createAnswer, as indicated above, as long as the capabilities of the
endpoint are not exceeded (e.g. asking for a resolution greater than endpoint are not exceeded (e.g. asking for a resolution greater than
what the endpoint can encode): what the endpoint can encode):
o [[OPEN ISSUE: This is a placeholder for other modifications, o [[OPEN ISSUE: This is a placeholder for other modifications, which
which we may continue adding as use cases appear.]] we may continue adding as use cases appear.]]
Implementations MAY choose to either honor or reject any elements not Implementations MAY choose to either honor or reject any elements not
listed in the above two categories, but must do so explicitly as listed in the above two categories, but must do so explicitly as
described at the beginning of this section. Note that future described at the beginning of this section. Note that future
standards may add new SDP elements to the list of elements which must standards may add new SDP elements to the list of elements which must
be accepted or rejected, but due to version skew, applications must be accepted or rejected, but due to version skew, applications must
be prepared for implementations to accept changes which must be be prepared for implementations to accept changes which must be
rejected and vice versa. rejected and vice versa.
The application can also modify the SDP to reduce the capabilities in The application can also modify the SDP to reduce the capabilities in
skipping to change at page 34, line 48 skipping to change at page 42, line 38
the offer. the offer.
As always, the application is solely responsible for what it sends to As always, the application is solely responsible for what it sends to
the other party, and all incoming SDP will be processed by the the other party, and all incoming SDP will be processed by the
browser to the extent of its capabilities. It is an error to assume browser to the extent of its capabilities. It is an error to assume
that all SDP is well-formed; however, one should be able to assume that all SDP is well-formed; however, one should be able to assume
that any implementation of this specification will be able to that any implementation of this specification will be able to
process, as a remote offer or answer, unmodified SDP coming from any process, as a remote offer or answer, unmodified SDP coming from any
other implementation of this specification. other implementation of this specification.
7. Security Considerations 7. Examples
Note that this example section shows several SDP fragments. To
format in 72 columns, some of the lines in SDP have been split into
multiple lines, where leading whitespace indicates that a line is a
continuation of the previous line. In addition, some blank lines
have been added to improve readability but are not valid in SDP.
More examples of SDP for WebRTC call flows can be found in
[I-D.nandakumar-rtcweb-sdp].
7.1. Simple Example
This section shows a very simple example that sets up a minimal audio
/ video call between two browsers and does not use trickle ICE. The
example in the following section provides a more realistic example of
what would happen in a normal browser to browser connection.
The flow shows Alice's browser initiating the session to Bob's
browser. The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server. The JS on both
Alice's side and Bob's side waits for all candidates before sending
the offer or answer, so the offers and answers are complete. Trickle
ICE is not used. Both Alice and Bob are using the default policy of
balanced.
// set up local media state
AliceJS->AliceUA: create new PeerConnection
AliceJS->AliceUA: addStream with stream containing audio and video
AliceJS->AliceUA: createOffer to get offer
AliceJS->AliceUA: setLocalDescription with offer
AliceUA->AliceJS: multiple onicecandidate callbacks with candidates
// wait for ICE gathering to complete
AliceUA->AliceJS: onicecandidate callback with null candidate
AliceJS->AliceUA: get |offer-A1| from value of localDescription
// |offer-A1| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |offer-A1|
WebServer->BobJS: signaling with |offer-A1|
// |offer-A1| arrives at Bob
BobJS->BobUA: create a PeerConnection
BobJS->BobUA: setRemoteDescription with |offer-A1|
BobUA->BobJS: onaddstream callback with remoteStream
// Bob accepts call
BobJS->BobUA: addStream with local media
BobJS->BobUA: createAnswer
BobJS->BobUA: setLocalDescription with answer
BobUA->BobJS: multiple onicecandidate callbacks with candidates
// wait for ICE gathering to complete
BobUA->BobJS: onicecandidate callback with null candidate
BobJS->BobUA: get |answer-A1| from value of localDescription
// |answer-A1| is sent over signaling protocol to Alice
BobJS->WebServer: signaling with |answer-A1|
WebServer->AliceJS: signaling with |answer-A1|
// |answer-A1| arrives at Alice
AliceJS->AliceUA: setRemoteDescription with |answer-A1|
AliceUA->AliceJS: onaddstream callback with remoteStream
// media flows
BobUA->AliceUA: media sent from Bob to Alice
AliceUA->BobUA: media sent from Alice to Bob
The SDP for |offer-A1| looks like:
v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 v1
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.1
a=mid:a1
a=rtcp:56501 IN IP4 192.0.2.1
a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:ETEn1v9DoTMB9J4r
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
typ host
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501
typ host
a=end-of-candidates
m=video 56502 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.1
a=rtcp:56503 IN IP4 192.0.2.1
a=mid:v1
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:BGKkWnG5GmiUpdIV
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
a=ssrc-group:FID 1366781083 1366781084
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502
typ host
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
typ host
a=end-of-candidates
The SDP for |answer-A1| looks like:
v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
m=audio 20000 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.2
a=mid:a1
a=rtcp:20000 IN IP4 192.0.2.2
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host
a=end-of-candidates
m=video 20001 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.2
a=rtcp 20001 IN IP4 192.0.2.2
a=mid:v1
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=rtcp-mux
a=rtcp-rsize
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 3229706345 3229706346
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20001
typ host
a=end-of-candidates
7.2. Normal Examples
This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel. Trickle ICE
is used in full trickle mode with a policy of max-bundle-and-rtcp-mux
and a single TURN server. Later, two video flows, one for the
presenter and one for screen sharing, are added to the session. This
example shows Alice's browser initiating the session to Bob's
browser. The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server.
// set up local media state
AliceJS->AliceUA: create new PeerConnection
AliceJS->AliceUA: addStream that contains audio track
AliceJS->AliceUA: createDataChannel to get data channel
AliceJS->AliceUA: createOffer to get |offer-B1|
AliceJS->AliceUA: setLocalDescription with |offer-B1|
// |offer-B1| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |offer-B1|
WebServer->BobJS: signaling with |offer-B1|
// |offer-B1| arrives at Bob
BobJS->BobUA: create a PeerConnection
BobJS->BobUA: setRemoteDescription with |offer-B1|
BobUA->BobJS: onaddstream with audio track from Alice
// candidates are sent to Bob
AliceUA->AliceJS: onicecandidate callback with |candidate-B1| (host)
AliceJS->WebServer: signaling with |candidate-B1|
AliceUA->AliceJS: onicecandidate callback with |candidate-B2| (srflx)
AliceJS->WebServer: signaling with |candidate-B2|
AliceUA->AliceJS: onicecandidate callback with |candidate-B3| (relay)
AliceJS->WebServer: signaling with |candidate-B3|
WebServer->BobJS: signaling with |candidate-B1|
BobJS->BobUA: addIceCandidate with |candidate-B1|
WebServer->BobJS: signaling with |candidate-B2|
BobJS->BobUA: addIceCandidate with |candidate-B2|
WebServer->BobJS: signaling with |candidate-B3|
BobJS->BobUA: addIceCandidate with |candidate-B3|
// Bob accepts call
BobJS->BobUA: addStream with local audio stream
BobJS->BobUA: createDataChannel to get data channel
BobJS->BobUA: createAnswer to get |answer-B1|
BobJS->BobUA: setLocalDescription with |answer-B1|
// |answer-B1| is sent to Alice
BobJS->WebServer: signaling with |answer-B1|
WebServer->AliceJS: signaling with |answer-B1|
AliceJS->AliceUA: setRemoteDescription with |answer-B1|
AliceUA->AliceJS: onaddstream callback with audio track from Bob
// candidates are sent to Alice
BobUA->BobJS: onicecandidate callback with |candidate-B4| (host)
BobJS->WebServer: signaling with |candidate-B4|
BobUA->BobJS: onicecandidate callback with |candidate-B5| (srflx)
BobJS->WebServer: signaling with |candidate-B5|
BobUA->BobJS: onicecandidate callback with |candidate-B6| (relay)
BobJS->WebServer: signaling with |candidate-B6|
WebServer->AliceJS: signaling with |candidate-B4|
AliceJS->AliceUA: addIceCandidate with |candidate-B4|
WebServer->AliceJS: signaling with |candidate-B5|
AliceJS->AliceUA: addIceCandidate with |candidate-B5|
WebServer->AliceJS: signaling with |candidate-B6|
AliceJS->AliceUA: addIceCandidate with |candidate-B6|
// data channel opens
BobUA->BobJS: ondatachannel callback
AliceUA->AliceJS: ondatachannel callback
BobUA->BobJS: onopen
AliceUA->AliceJS: onopen
// media is flowing between browsers
BobUA->AliceUA: audio+data sent from Bob to Alice
AliceUA->BobUA: audio+data sent from Alice to Bob
// some time later Bob adds two video streams
// note, no candidates exchanged, because of BUNDLE
BobJS->BobUA: addStream with first video stream
BobJS->BobUA: addStream with second video stream
BobJS->BobUA: createOffer to get |offer-B2|
BobJS->BobUA: setLocalDescription with |offer-B2|
// |offer-B2| is sent to Alice
BobJS->WebServer: signaling with |offer-B2|
WebServer->AliceJS: signaling with |offer-B2|
AliceJS->AliceUA: setRemoteDescription with |offer-B2|
AliceUA->AliceJS: onaddstream callback with first video stream
AliceUA->AliceJS: onaddstream callback with second video stream
AliceJS->AliceUA: createAnswer to get |answer-B2|
AliceJS->AliceUA: setLocalDescription with |answer-B2|
// |answer-B2| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |answer-B2|
WebServer->BobJS: signaling with |answer-B2|
BobJS->BobUA: setRemoteDescription with |answer-B2|
// media is flowing between browsers
BobUA->AliceUA: audio+video+data sent from Bob to Alice
AliceUA->BobUA: audio+video+data sent from Alice to Bob
The SDP for |offer-B1| looks like:
v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP6 ::
a=rtcp:9 IN IP6 ::
a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
m=application 9 UDP/TLS/SCTP webrtc-datachannel
c=IN IP6 ::
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
The SDP for |candidate-B1| looks like:
candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
The SDP for |candidate-B2| looks like:
candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
The SDP for |candidate-B3| looks like:
candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
The SDP for |answer-B1| looks like:
v=0
o=- 7729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP6 ::
a=rtcp:9 IN IP6 ::
a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
m=application 9 UDP/TLS/SCTP webrtc-datachannel
c=IN IP6 ::
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
The SDP for |candidate-B4| looks like:
candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
The SDP for |candidate-B5| looks like:
candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
The SDP for |candidate-B6| looks like:
candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
The SDP for |offer-B2| looks like: (note the increment of the version
number in the o= line, and the c= and a=rtcp lines, which indicate
the local candidate that was selected)
v=0
o=- 7729291447651054566 2 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 v1 v2
m=audio 64532 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88
a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
m=application 64532 UDP/TLS/SCTP webrtc-datachannel
c=IN IP4 55.66.77.88
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:actpass
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
m=video 64532 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 1366781083 1366781084
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
m=video 64532 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1
a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 2366781083 2366781084
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
The SDP for |answer-B2| looks like: (note the use of setup:passive to
maintain the existing DTLS roles, and the use of a=recvonly to
indicate that the video streams are one-way)
v=0
o=- 4962303333179871723 2 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 v1 v2
m=audio 52546 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44
a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
m=application 52546 UDP/TLS/SCTP webrtc-datachannel
c=IN IP4 11.22.33.44
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
m=video 52546 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v1
a=recvonly
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive
a=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
m=video 52546 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v2
a=recvonly
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive
a=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
8. Security Considerations
The IETF has published separate documents The IETF has published separate documents
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing
the security architecture for WebRTC as a whole. The remainder of the security architecture for WebRTC as a whole. The remainder of
this section describes security considerations for this document. this section describes security considerations for this document.
While formally the JSEP interface is an API, it is better to think of While formally the JSEP interface is an API, it is better to think of
it is an Internet protocol, with the JS being untrustworthy from the it is an Internet protocol, with the JS being untrustworthy from the
perspective of the browser. Thus, the threat model of [RFC3552] perspective of the browser. Thus, the threat model of [RFC3552]
applies. In particular, JS can call the API in any order and with applies. In particular, JS can call the API in any order and with
skipping to change at page 35, line 23 skipping to change at page 58, line 35
While correct API usage requires that the application pass in SDP While correct API usage requires that the application pass in SDP
which was derived from createOffer() or createAnswer() (perhaps which was derived from createOffer() or createAnswer() (perhaps
suitably modified as described in Section 6, there is no guarantee suitably modified as described in Section 6, there is no guarantee
that applications do so. The browser MUST be prepared for the JS to that applications do so. The browser MUST be prepared for the JS to
pass in bogus data instead. pass in bogus data instead.
Conversely, the application programmer MUST recognize that the JS Conversely, the application programmer MUST recognize that the JS
does not have complete control of browser behavior. One case that does not have complete control of browser behavior. One case that
bears particular mention is that editing ICE candidates out of the bears particular mention is that editing ICE candidates out of the
SDP or suppressing trickled candidates does not have the expected SDP or suppressing trickled candidates does not have the expected
behavior: implementations will still perform checks from those behavior: implementations will still perform checks from those
candidates even if they are not sent to the other side. Thus, for candidates even if they are not sent to the other side. Thus, for
instance, it is not possible to prevent the remote peer from learning instance, it is not possible to prevent the remote peer from learning
your public IP address by removing server reflexive candidates. your public IP address by removing server reflexive candidates.
Applications which wish to conceal their public IP address should Applications which wish to conceal their public IP address should
instead configure the ICE agent to use only relay candidates. instead configure the ICE agent to use only relay candidates.
8. IANA Considerations 9. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
9. Acknowledgements 10. Acknowledgements
Significant text incorporated in the draft as well and review was Significant text incorporated in the draft as well and review was
provided by Harald Alvestrand and Suhas Nandakumar. Dan Burnett, provided by Harald Alvestrand and Suhas Nandakumar. Dan Burnett,
Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton, Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton,
Richard Ejzak, Adam Bergkvist and Matthew Kaufman all provided Richard Ejzak, Adam Bergkvist and Matthew Kaufman all provided
valuable feedback on this proposal. valuable feedback on this proposal.
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "Cross Session Stream Identification in Alvestrand, H., "Cross Session Stream Identification in
the Session Description Protocol", the Session Description Protocol", draft-ietf-mmusic-
draft-ietf-mmusic-msid-01 (work in progress), August 2013. msid-01 (work in progress), August 2013.
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Loreto, S. and G. Camarillo, "Stream Control Transmission Loreto, S. and G. Camarillo, "Stream Control Transmission
Protocol (SCTP)-Based Media Transport in the Session Protocol (SCTP)-Based Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04
(work in progress), June 2013. (work in progress), June 2013.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
draft-ietf-mmusic-sdp-bundle-negotiation-04 (work in bundle-negotiation-04 (work in progress), June 2013.
progress), June 2013.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-01 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-01
(work in progress), February 2014. (work in progress), February 2014.
[I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-00 (work in progress), March 2013.
[I-D.ietf-rtcweb-audio] [I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-02 (work in Requirements", draft-ietf-rtcweb-audio-02 (work in
progress), August 2013. progress), August 2013.
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Protocol", draft-ietf-rtcweb-data-protocol-04 (work in Protocol", draft-ietf-rtcweb-data-protocol-04 (work in
progress), February 2013. progress), February 2013.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-09 (work in progress), draft-ietf-rtcweb-rtp-usage-09 (work in progress),
September 2013. September 2013.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", Rescorla, E., "Security Considerations for WebRTC", draft-
draft-ietf-rtcweb-security-06 (work in progress), ietf-rtcweb-security-06 (work in progress), January 2014.
January 2014.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", Rescorla, E., "WebRTC Security Architecture", draft-ietf-
draft-ietf-rtcweb-security-arch-09 (work in progress), rtcweb-security-arch-09 (work in progress), February 2014.
February 2014.
[I-D.nandakumar-mmusic-proto-iana-registration]
Nandakumar, S., "IANA registration of SDP 'proto'
attribute for transporting RTP Media over TCP under
various RTP profiles.", September 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552, July
July 2003. 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October
2003.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
July 2006. 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904, April
April 2013. 2013.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
10.2. Informative References 11.2. Informative References
[I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol",
draft-ietf-mmusic-trickle-ice-00 (work in progress),
March 2013.
[I-D.nandakumar-rtcweb-sdp] [I-D.nandakumar-rtcweb-sdp]
Nandakumar, S. and C. Jennings, "SDP for the WebRTC", Nandakumar, S. and C. Jennings, "SDP for the WebRTC",
draft-nandakumar-rtcweb-sdp-02 (work in progress), draft-nandakumar-rtcweb-sdp-02 (work in progress), July
July 2013. 2013.
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002. Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
RFC 3556, July 2003. 3556, July 2003.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, December 2004. RFC 3960, December 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
skipping to change at page 39, line 21 skipping to change at page 62, line 41
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[W3C.WD-webrtc-20140617] [W3C.WD-webrtc-20140617]
Bergkvist, A., Burnett, D., Narayanan, A., and C. Bergkvist, A., Burnett, D., Narayanan, A., and C.
Jennings, "WebRTC 1.0: Real-time Communication Between Jennings, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc- Browsers", World Wide Web Consortium WD WD-webrtc-
20140617, June 2014, 20140617, June 2014,
<http://www.w3.org/TR/2011/WD-webrtc-20140617>. <http://www.w3.org/TR/2011/WD-webrtc-20140617>.
Appendix A. JSEP Implementation Examples Appendix A. Change log
A.1. Example API Flows
Below are several sample flows for the new PeerConnection and library
APIs, demonstrating when the various APIs are called in different
situations and with various transport protocols. For clarity and
simplicity, the createOffer/createAnswer calls are assumed to be
synchronous in these examples, whereas the actual APIs are async.
A.1.1. Call using ROAP
This example demonstrates a ROAP call, without the use of trickle
candidates.
// Call is initiated toward Answerer
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererUA->OffererJS: iceCallback(candidate);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS->AnswererJS: {"type":"OFFER", "sdp":offer }
// OFFER arrives at Answerer
AnswererJS->AnswererUA: pc = new PeerConnection();
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", msg.sdp);
AnswererUA->AnswererJS: onaddstream(remoteStream);
AnswererUA->OffererUA: iceCallback(candidate);
// Answerer accepts call
AnswererJS->AnswererUA: pc.addStream(localStream, null);
AnswererJS->AnswererUA: answer = pc.createAnswer(msg.sdp, null);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS->OffererJS: {"type":"ANSWER","sdp":answer }
// ANSWER arrives at Offerer
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
// ICE Completes (at Answerer)
AnswererUA->OffererUA: Media
// ICE Completes (at Offerer)
OffererJS->AnswererJS: {"type":"OK" }
OffererUA->AnswererUA: Media
A.1.2. Call using XMPP
This example demonstrates an XMPP call, making use of trickle
candidates.
// Call is initiated toward Answerer
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS: xmpp = createSessionInitiate(offer);
OffererJS->AnswererJS: <jingle action="session-initiate"/>
OffererJS->OffererUA: pc.startIce();
OffererUA->OffererJS: onicecandidate(cand);
OffererJS: createTransportInfo(cand);
OffererJS->AnswererJS: <jingle action="transport-info"/>
// session-initiate arrives at Answerer
AnswererJS->AnswererUA: pc = new PeerConnection();
AnswererJS: offer = parseSessionInitiate(xmpp);
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer);
AnswererUA->AnswererJS: onaddstream(remoteStream);
// transport-infos arrive at Answerer
AnswererJS->AnswererUA: candidate = parseTransportInfo(xmpp);
AnswererJS->AnswererUA: pc.addIceCandidate(candidate);
AnswererUA->AnswererJS: onicecandidate(cand)
AnswererJS: createTransportInfo(cand);
AnswererJS->OffererJS: <jingle action="transport-info"/>
// transport-infos arrive at Offerer
OffererJS->OffererUA: candidates = parseTransportInfo(xmpp);
OffererJS->OffererUA: pc.addIceCandidate(candidates);
// Answerer accepts call
AnswererJS->AnswererUA: pc.addStream(localStream, null);
AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null);
AnswererJS: xmpp = createSessionAccept(answer);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS->OffererJS: <jingle action="session-accept"/>
// session-accept arrives at Offerer
OffererJS: answer = parseSessionAccept(xmpp);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
// ICE Completes (at Answerer)
AnswererUA->OffererUA: Media
// ICE Completes (at Offerer)
OffererUA->AnswererUA: Media
A.1.3. Adding video to a call, using XMPP
This example demonstrates an XMPP call, where the XMPP content-add
mechanism is used to add video media to an existing session. For
simplicity, candidate exchange is not shown.
Note that the offerer for the change to the session may be different
than the original call offerer.
// Offerer adds video stream
OffererJS->OffererUA: pc.addStream(videoStream)
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS: xmpp = createContentAdd(offer);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS->AnswererJS: <jingle action="content-add"/>
// content-add arrives at Answerer
AnswererJS: offer = parseContentAdd(xmpp);
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer);
AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS: xmpp = createContentAccept(answer);
AnswererJS->OffererJS: <jingle action="content-accept"/>
// content-accept arrives at Offerer
OffererJS: answer = parseContentAccept(xmpp);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
A.1.4. Simultaneous add of video streams, using XMPP
This example demonstrates an XMPP call, where new video sources are
added at the same time to a call that already has video; since adding
these sources only affects one side of the call, there is no
conflict. The XMPP description-info mechanism is used to indicate
the new sources to the remote side.
// Offerer and "Answerer" add video streams at the same time
OffererJS->OffererUA: pc.addStream(offererVideoStream2)
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS: xmpp = createDescriptionInfo(offer);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS->AnswererJS: <jingle action="description-info"/>
AnswererJS->AnswererUA: pc.addStream(answererVideoStream2)
AnswererJS->AnswererUA: offer = pc.createOffer(null);
AnswererJS: xmpp = createDescriptionInfo(offer);
AnswererJS->AnswererUA: pc.setLocalDescription("offer", offer);
AnswererJS->OffererJS: <jingle action="description-info"/>
// description-info arrives at "Answerer", and is acked
AnswererJS: offer = parseDescriptionInfo(xmpp);
AnswererJS->OffererJS: <iq type="result"/> // ack
// description-info arrives at Offerer, and is acked Note: This section will be removed by RFC Editor before publication.
OffererJS: offer = parseDescriptionInfo(xmpp);
OffererJS->AnswererJS: <iq type="result"/> // ack
// ack arrives at Offerer; remote offer is used as an answer Changes in draft-08:
OffererJS->OffererUA: pc.setRemoteDescription("answer", offer);
// ack arrives at "Answerer"; remote offer is used as an answer o Added new example section and removed old examples in appendix.
AnswererJS->AnswererUA: pc.setRemoteDescription("answer", offer);
A.1.5. Call using SIP o Fixed <proto> field handling.
This example demonstrates a simple SIP call (e.g. where the client o Added text describing a=rtcp attribute.
talks to a SIP proxy over WebSockets).
// Call is initiated toward Answerer o Reworked handling of OfferToReceiveAudio and OfferToReceiveVideo
OffererJS->OffererUA: pc = new PeerConnection(); per discussion at IETF 90.
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererUA->OffererJS: onicecandidate(candidate);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS: sip = createInvite(offer);
OffererJS->AnswererJS: SIP INVITE w/ SDP
// INVITE arrives at Answerer o Reworked trickle ICE handling and its impact on m= and c= lines
AnswererJS->AnswererUA: pc = new PeerConnection(); per discussion at interim.
AnswererJS: offer = parseInvite(sip);
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer);
AnswererUA->AnswererJS: onaddstream(remoteStream);
AnswererUA->OffererUA: onicecandidate(candidate);
// Answerer accepts call o Added max-bundle-and-rtcp-mux policy.
AnswererJS->AnswererUA: pc.addStream(localStream, null);
AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null);
AnswererJS: sip = createResponse(200, answer);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS->OffererJS: 200 OK w/ SDP
// 200 OK arrives at Offerer o Added description of maxptime handling.
OffererJS: answer = parseResponse(sip);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
OffererJS->AnswererJS: ACK
// ICE Completes (at Answerer) o Updated ICE candidate pool default to 0.
AnswererUA->OffererUA: Media
// ICE Completes (at Offerer) o Resolved open issues around AppID/receiver-ID.
OffererUA->AnswererUA: Media
A.1.6. Handling early media (e.g. 1-800-GO FEDEX), using SIP o Reworked and expanded how changes to the ICE configuration are
handled.
This example demonstrates how early media could be handled; for o Some reference updates.
simplicity, only the offerer side of the call is shown.
// Call is initiated toward Answerer o Editorial clarification.
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererUA->OffererJS: onicecandidate(candidate);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS: sip = createInvite(offer);
OffererJS->AnswererJS: SIP INVITE w/ SDP
// 180 Ringing is received by offerer, w/ SDP Changes in draft-07:
OffererJS: answer = parseResponse(sip);
OffererJS->OffererUA: pc.setRemoteDescription("pranswer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
// ICE Completes (at Offerer) o Expanded discussion of VAD and Opus DTX.
OffererUA->AnswererUA: Media
// 200 OK arrives at Offerer o Added a security considerations section.
OffererJS: answer = parseResponse(sip);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererJS->AnswererJS: ACK
A.2. Example Session Descriptions o Rewrote the section on modifying SDP to require implementations to
clearly indicate whether any given modification is allowed.
A.2.1. createOffer o Clarified impact of IceRestart on CreateOffer in local-offer
state.
This SDP shows a typical initial offer, created by createOffer for a o Guidance on whether attributes should be defined at the media
PeerConnection with a single audio MediaStreamTrack, a single video level or the session level.
MediaStreamTrack, and a single data channel. Host candidates have
also already been gathered. Note some lines have been broken into
two lines for formatting reasons.
v=0 o Renamed "default" bundle policy to "balanced".
o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE audio video data
m=audio 56500 UDP/TLS/RTP/SAVPF 111 0 8 126
c=IN IP4 192.0.2.1
a=rtcp:56501 IN IP4 192.0.2.1
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
typ host generation 0
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501
typ host generation 0
a=ice-ufrag:ETEn1v9DoTMB9J4r
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
m=video 56502 UDP/TLS/RTP/SAVPF 100 115 116 117
c=IN IP4 192.0.2.1
a=rtcp:56503 IN IP4 192.0.2.1
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502
typ host generation 0
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
typ host generation 0
a=ice-ufrag:BGKkWnG5GmiUpdIV
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=ice-options:trickle
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=100
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781085 cname:EocUG1f0fcg/yvY7
a=ssrc-group:FID 1366781083 1366781084
a=ssrc-group:FEC 1366781083 1366781085
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
m=application 56504 DTLS/SCTP 5000
c=IN IP4 192.0.2.1
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56504
typ host generation 0
a=ice-ufrag:VD5v2BnbZm3mgP3d
a=ice-pwd:+Jlkuox+VVIUDqxcfIDuTZMH
a=ice-options:trickle
a=mid:data
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=sctpmap:5000 webrtc-datachannel 16
A.2.2. createAnswer o Removed default ICE candidate pool size and clarify how it works.
This SDP shows a typical initial answer to the above offer, created o Defined a canonical order for assignment of MSTs to m= lines.
by createAnswer for a PeerConnection with a single audio
MediaStreamTrack, a single video MediaStreamTrack, and a single data
channel. Host candidates have also already been gathered. Note some
lines have been broken into two lines for formatting reasons.
v=0 o Removed discussion of rehydration.
o=- 6729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE audio video data
m=audio 20000 UDP/TLS/RTP/SAVPF 111 0 8 126
c=IN IP4 192.0.2.2
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host generation 0
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
m=video 20000 UDP/TLS/RTP/SAVPF 100 115 116 117
c=IN IP4 192.0.2.2
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host generation 0
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=100
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706347 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 3229706345 3229706346
a=ssrc-group:FEC 3229706345 3229706347
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
m=application 20000 DTLS/SCTP 5000
c=IN IP4 192.0.2.2
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host generation 0
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=mid:data
a=sctpmap:5000 webrtc-datachannel 16
A.2.3. Call Flows o Added Eric Rescorla as a draft editor.
Example SDP for WebRTC call flows can be found in o Cleaned up references.
[I-D.nandakumar-rtcweb-sdp]. [TODO: should these call flows be
merged into this section?]
Appendix B. Change log o Editorial cleanup
Changes in draft-06: Changes in draft-06:
o Reworked handling of m= line recycling. o Reworked handling of m= line recycling.
o Added handling of BUNDLE and bundle-only. o Added handling of BUNDLE and bundle-only.
o Clarified handling of rollback. o Clarified handling of rollback.
o Added text describing the ICE Candidate Pool and its behavior. o Added text describing the ICE Candidate Pool and its behavior.
o Allowed OfferToReceiveX to create multiple recvonly m= sections. o Allowed OfferToReceiveX to create multiple recvonly m= sections.
Changes in draft-05: Changes in draft-05:
o Fixed several issues identified in the createOffer/Answer sections o Fixed several issues identified in the createOffer/Answer sections
during document review. during document review.
o Updated references. o Updated references.
Changes in draft-04: Changes in draft-04:
o Filled in sections on createOffer and createAnswer. o Filled in sections on createOffer and createAnswer.
o Added SDP examples. o Added SDP examples.
o Fixed references. o Fixed references.
Changes in draft-03: Changes in draft-03:
o Added text describing relationship to W3C specification o Added text describing relationship to W3C specification
Changes in draft-02: Changes in draft-02:
o Converted from nroff o Converted from nroff
o Removed comparisons to old approaches abandoned by the working o Removed comparisons to old approaches abandoned by the working
group group
o Removed stuff that has moved to W3C specification o Removed stuff that has moved to W3C specification
o Align SDP handling with W3C draft o Align SDP handling with W3C draft
o Clarified section on forking. o Clarified section on forking.
Changes in draft-01: Changes in draft-01:
o Added diagrams for architecture and state machine. o Added diagrams for architecture and state machine.
o Added sections on forking and rehydration. o Added sections on forking and rehydration.
o Clarified meaning of "pranswer" and "answer". o Clarified meaning of "pranswer" and "answer".
o Reworked how ICE restarts and media directions are controlled. o Reworked how ICE restarts and media directions are controlled.
o Added list of parameters that can be changed in a description. o Added list of parameters that can be changed in a description.
o Updated suggested API and examples to match latest thinking. o Updated suggested API and examples to match latest thinking.
o Suggested API and examples have been moved to an appendix. o Suggested API and examples have been moved to an appendix.
Changes in draft -00: Changes in draft -00:
o Migrated from draft-uberti-rtcweb-jsep-02. o Migrated from draft-uberti-rtcweb-jsep-02.
Authors' Addresses Authors' Addresses
Justin Uberti Justin Uberti
Google Google
skipping to change at page 50, line 15 skipping to change at page 65, line 31
o Migrated from draft-uberti-rtcweb-jsep-02. o Migrated from draft-uberti-rtcweb-jsep-02.
Authors' Addresses Authors' Addresses
Justin Uberti Justin Uberti
Google Google
747 6th Ave S 747 6th Ave S
Kirkland, WA 98033 Kirkland, WA 98033
USA USA
Email: justin@uberti.name Email: justin@uberti.name
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: fluffy@iii.ca Email: fluffy@iii.ca
Eric Rescorla (editor) Eric Rescorla (editor)
Mozilla Mozilla
331 Evelyn Ave 331 Evelyn Ave
Mountain View, CA 94041 Mountain View, CA 94041
USA USA
Email: ekr@rtfm.com Email: ekr@rtfm.com
 End of changes. 180 change blocks. 
687 lines changed or deleted 1359 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/