draft-ietf-rtcweb-jsep-09.txt   draft-ietf-rtcweb-jsep-10.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: September 10, 2015 Cisco Expires: December 17, 2015 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
March 9, 2015 June 15, 2015
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-09 draft-ietf-rtcweb-jsep-10
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 10, 2015. This Internet-Draft will expire on December 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . 6 3.2. Session Descriptions and State Machine . . . . . . . . . 7
3.3. Session Description Format . . . . . . . . . . . . . . . 10 3.3. Session Description Format . . . . . . . . . . . . . . . 10
3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. ICE Gathering Overview . . . . . . . . . . . . . . . 10 3.4.1. ICE Gathering Overview . . . . . . . . . . . . . . . 10
3.4.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 11 3.4.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 11
3.4.2.1. ICE Candidate Format . . . . . . . . . . . . . . 11 3.4.2.1. ICE Candidate Format . . . . . . . . . . . . . . 11
3.4.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 12 3.4.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 12
3.4.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 13 3.4.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 13
3.5. Interactions With Forking . . . . . . . . . . . . . . . . 13 3.5. RTP CNAME Semantics . . . . . . . . . . . . . . . . . . . 13
3.5.1. Sequential Forking . . . . . . . . . . . . . . . . . 14 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14
3.5.2. Parallel Forking . . . . . . . . . . . . . . . . . . 14 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 14
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 15
4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7. Interactions With Forking . . . . . . . . . . . . . . . . 15
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 15 3.7.1. Sequential Forking . . . . . . . . . . . . . . . . . 16
4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 17 3.7.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16
4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 18 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 19 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 20 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17
4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 20 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19
4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 21 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20
4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 21 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21
4.1.7. localDescription . . . . . . . . . . . . . . . . . . 22 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22
4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 22 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 23
4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 22 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23
4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 23 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24
4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 24 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 24 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 24 4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 25
5.1.1. Implementation Requirements . . . . . . . . . . . . . 24 4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25
5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 26 4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26
5.1.3. Profile Names and Interoperability . . . . . . . . . 26 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 27 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 27 5.1.1. Implementation Requirements . . . . . . . . . . . . . 27
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 32 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 35 5.1.3. Profile Names and Interoperability . . . . . . . . . 28
5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 35 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29
5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 35 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29
5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 36 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34
5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 36 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 36 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 36 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 38
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 41 5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 42 5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 42 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 39
5.4. Processing a Local Description . . . . . . . . . . . . . 42 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39
5.5. Processing a Remote Description . . . . . . . . . . . . . 43 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43
5.6. Parsing a Session Description . . . . . . . . . . . . . . 43 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44
5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 44 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 45
5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 45 5.4. Processing a Local Description . . . . . . . . . . . . . 45
5.6.3. Semantics Verification . . . . . . . . . . . . . . . 47 5.5. Processing a Remote Description . . . . . . . . . . . . . 45
5.7. Applying a Local Description . . . . . . . . . . . . . . 47 5.6. Parsing a Session Description . . . . . . . . . . . . . . 46
5.8. Applying a Remote Description . . . . . . . . . . . . . . 48 5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46
5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 48 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 48
6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 48 5.6.3. Semantics Verification . . . . . . . . . . . . . . . 50
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.7. Applying a Local Description . . . . . . . . . . . . . . 50
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 50 5.8. Applying a Remote Description . . . . . . . . . . . . . . 51
7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 54 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 51
8. Security Considerations . . . . . . . . . . . . . . . . . . . 65 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 51
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 56
11.1. Normative References . . . . . . . . . . . . . . . . . . 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 67
11.2. Informative References . . . . . . . . . . . . . . . . . 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
11.1. Normative References . . . . . . . . . . . . . . . . . . 68
11.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
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 6, line 24 skipping to change at page 6, line 28
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Semantics and Syntax 3. Semantics and Syntax
3.1. Signaling Model 3.1. Signaling Model
JSEP does not specify a particular signaling model or state machine, JSEP does not specify a particular signaling model or state machine,
other than the generic need to exchange SDP media descriptions in the other than the generic need to exchange session descriptions in the
fashion described by [RFC3264] (offer/answer) in order for both sides fashion described by [RFC3264] (offer/answer) in order for both sides
of the session to know how to conduct the session. JSEP provides of the session to know how to conduct the session. JSEP provides
mechanisms to create offers and answers, as well as to apply them to mechanisms to create offers and answers, as well as to apply them to
a session. However, the browser is totally decoupled from the actual a session. However, the browser is totally decoupled from the actual
mechanism by which these offers and answers are communicated to the mechanism by which these offers and answers are communicated to the
remote side, including addressing, retransmission, forking, and glare remote side, including addressing, retransmission, forking, and glare
handling. These issues are left entirely up to the application; the handling. These issues are left entirely up to the application; the
application has complete control over which offers and answers get application has complete control over which offers and answers get
handed to the browser, and when. handed to the browser, and when.
skipping to change at page 13, line 34 skipping to change at page 13, line 34
One example of where this concept is useful is an application that 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 expects an incoming call at some point in the future, and wants to
minimize the time it takes to establish connectivity, to avoid minimize the time it takes to establish connectivity, to avoid
clipping of initial media. By pre-gathering candidates into the clipping of initial media. By pre-gathering candidates into the
pool, it can exchange and start sending connectivity checks from pool, it can exchange and start sending connectivity checks from
these candidates almost immediately upon receipt of a call. Note these candidates almost immediately upon receipt of a call. Note
though that by holding on to these pre-gathered candidates, which 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 be kept alive as long as they may be needed, the application
will consume resources on the STUN/TURN servers it is using. will consume resources on the STUN/TURN servers it is using.
3.5. Interactions With Forking 3.5. RTP CNAME Semantics
RTP CNAME values provide a canonical name for the RTP endpoint,
allowing other RTP endpoints to determine which RTP streams are using
the same clock and thus which clock sources can be used that to
synchronize media playout.
Any MediaStreamTracks which have different clock sources MUST have
different CNAMEs [TODO: need a reference for this.] Any
MediaStreamTracks which are in different PeerConnection objects MUST
have different CNAMEs; this prevents peers from linking calls from
multiple remote PeerConnections based on the CNAME. For simplicity,
MediaStreamTracks in the same PeerConnection which have the same
clock source SHOULD have the same CNAME.
3.6. Video Size Negotiation
Video size negotiation is the process through which a receiver can
use the "a=imageattr" SDP attribute [RFC6236] to indicate what video
frame sizes it is capable of receiving. A receiver may have hard
limits on what its video decoder can process, or it may wish to
constrain what it receives due to application preferences, e.g. a
specific size for the window in which the video will be displayed.
3.6.1. Creating an imageattr Attribute
In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated
MediaStreamTrack. If the decoder limits are unknown, e.g. when using
a software decoder, the mandatory constraints are used directly. For
the answerer, these mandatory constraints can be applied to the
remote MediaStreamTracks that are created by a setRemoteDescription
call, and will affect the output of the ensuing createAnswer call.
Any constraints set after setLocalDescription is used to set the
answer will result in a new offer-answer exchange. For the offerer,
because it does not know about any remote MediaStreamTracks until it
receives the answer, the offer can only reflect decoder hard limits.
If the offerer wishes to set mandatory constraints on video
resolution, it must do so after receiving the answer, and the result
will be a new offer-answer to communicate them.
If there are no known decoder limits or mandatory constraints, the
"a=imageattr" attribute SHOULD be omitted.
Otherwise, an "a=imageattr" attribute is created with "recv"
direction, and the resulting resolution space formed by intersecting
the decoder limits and constraints is used to specify its minimum and
maximum x= and y= values. If the intersection is the null set, i.e.,
there are no resolutions that are permitted by both the decoder and
the mandatory constraints, this SHOULD be represented by x=0 and y=0
values.
The rules here express a single set of preferences, and therefore,
the "a=imageattr" q= value is not important. It SHOULD be set to
1.0.
The "a=imageattr" field is payload type specific. When all video
codecs supported have the same capabilities, use of a single
attribute, with the wildcard payload type (*), is RECOMMENDED.
However, when the supported video codecs have differing capabilities,
specific "a=imageattr" attributes MUST be inserted for each payload
type.
As an example, consider a system with a HD-capable, multiformat video
decoder, where the application has constrained the received track to
at most 360p. In this case, the implemention would generate this
attribute:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]
3.6.2. Interpreting an imageattr Attribute
[RFC6236] defines "a=imageattr" to be an advisory field. This means
that it does not absolutely constrain the video formats that the
sender can use, but gives an indication of the preferred values.
This specification prescribes more specific behavior. When a sender
of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first
check to see if the original resolution meets the criteria specified
in the attribute, and transmit it untouched if so. If the original
resolution is too large for the attribute criteria, the sender SHOULD
apply downscaling to the output of the MediaStreamTrack in order to
satisfy the criteria. In rare cases, where a receiver requires a
minimum resolution which is greater than the native resolution of the
video, the sender SHOULD apply upscaling in order to provide that
resolution. The sender SHOULD NOT apply upscaling in any other
cases.
If there is no appropriate scaling mechanism that allows the received
criteria to be satisfied, the sender MUST NOT transmit the track.
In the special case of receiving a maximum resolution of [0, 0], as
described above, the sender MUST NOT transmit the track.
3.7. 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
skipping to change at page 14, line 8 skipping to change at page 16, line 11
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 with 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.7.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.
JSEP handles sequential forking well, allowing the application to JSEP handles sequential forking well, allowing the application to
easily control the policy for selecting the desired remote endpoint. easily control the policy for selecting the desired remote endpoint.
When an answer arrives from one of the callees, the application can When an answer arrives from one of the callees, the application can
choose to apply it either as a provisional answer, leaving open the choose to apply it either as a provisional answer, leaving open the
skipping to change at page 14, line 32 skipping to change at page 16, line 35
In a "first-one-wins" situation, the first answer will be applied as In a "first-one-wins" situation, the first answer will be applied as
a final answer, and the application will reject any subsequent a final answer, and the application will reject any subsequent
answers. In SIP parlance, this would be ACK + BYE. answers. In SIP parlance, this would be ACK + BYE.
In a "last-one-wins" situation, all answers would be applied as In a "last-one-wins" situation, all answers would be applied as
provisional answers, and any previous call leg will be terminated. provisional answers, and any previous call leg will be terminated.
At some point, the application will end the setup process, perhaps At some point, the application will end the setup process, perhaps
with a timer; at this point, the application could reapply the with a timer; at this point, the application could reapply the
existing remote description as a final answer. existing remote description as a final answer.
3.5.2. Parallel Forking 3.7.2. Parallel Forking
Parallel forking involves a call being dispatched to multiple remote Parallel forking involves a call being dispatched to multiple remote
callees, where each callee can accept the call, and multiple callees, where each callee can accept the call, and multiple
simultaneous active signaling sessions can be established as a simultaneous active signaling sessions can be established as a
result. If multiple callees send media at the same time, the result. If multiple callees send media at the same time, the
possibilities for handling this are described in Section 3.1 of possibilities for handling this are described in Section 3.1 of
[RFC3960]. Most SIP devices today only support exchanging media with [RFC3960]. Most SIP devices today only support exchanging media with
a single device at a time, and do not try to mix multiple early media a single device at a time, and do not try to mix multiple early media
audio sources, as that could result in a confusing situation. For audio sources, as that could result in a confusing situation. For
example, consider having a European ringback tone mixed together with example, consider having a European ringback tone mixed together with
skipping to change at page 16, line 24 skipping to change at page 18, line 30
If a size is specified for the ICE candidate pool, this indicates the If a size is specified for the ICE candidate pool, this indicates the
number of ICE components to pre-gather candidates for. Because pre- number of ICE components to pre-gather candidates for. Because pre-
gathering results in utilizing STUN/TURN server resources for gathering results in utilizing STUN/TURN server resources for
potentially long periods of time, this must only occur upon potentially long periods of time, this must only occur upon
application request, and therefore the default candidate pool size application request, and therefore the default candidate pool size
MUST be zero. MUST be zero.
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding use of
BUNDLE, the multiplexing mechanism defined in BUNDLE, the multiplexing mechanism defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. By specifying a policy [I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the
from the list below, the application can control how aggressively it application will always try to negotiate BUNDLE onto a single
will try to BUNDLE media streams together. The set of available transport, and will offer a single BUNDLE group across all media
policies is as follows: sections. However, by specifying a policy from the list below, the
application can control how aggressively it will try to BUNDLE media
streams together, which affects how it will interoperate with a non-
BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware
endpoint, only the streams not marked as bundle-only streams will be
established. The set of available policies is as follows:
balanced: The application will BUNDLE all media streams of the same balanced: The first media section of each type (audio, video, or
type together. That is, if there are multiple audio and multiple application) will contain transport parameters, which will allow
video MediaStreamTracks attached to a PeerConnection, all but the an answerer to unbundle that section. The second and any
first audio and video tracks will be marked as bundle-only, and subsequent media section of each type will be marked bundle-only.
candidates will only be gathered for N media streams, where N is The result is that if there are N distinct media types, then
the number of distinct media types. When talking to a non-BUNDLE- candidates will be gathered for for N media streams. This policy
aware endpoint, only the non-bundle-only streams will be balances desire to multiplex with the need to ensure basic audio
negotiated. This policy balances desire to multiplex with the and video can still be negotiated in legacy cases.
need to ensure basic audio and video still works in legacy cases.
Data channels will be in a separate bundle group.
max-compat: The application will offer BUNDLE, but mark none of its max-compat: All media sections will contain transport parameters;
streams as bundle-only. This policy will allow all streams to be none will be marked as bundle-only. This policy will allow all
received by non-BUNDLE-aware endpoints, but require separate streams to be received by non-BUNDLE-aware endpoints, but require
candidates to be gathered for each media stream. separate candidates to be gathered for each media stream.
max-bundle: The application will BUNDLE all of its media streams, max-bundle: Only the first media section will contain transport
including data channels, on a single transport. All streams other parameters; all streams other than the first will be marked as
than the first will be marked as bundle-only. This policy aims to bundle-only. This policy aims to minimize candidate gathering and
minimize candidate gathering and maximize multiplexing, at the maximize multiplexing, at the cost of less compatibility with
cost of less compatibility with legacy endpoints. legacy endpoints.
As it provides the best tradeoff between performance and As it provides the best tradeoff between performance and
compatibility with legacy endpoints, the default BUNDLE policy MUST compatibility with legacy endpoints, the default BUNDLE policy MUST
be set to "balanced". be set to "balanced".
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding use of
RTP/RTCP multiplexing [RFC5761] using one of the following policies: RTP/RTCP multiplexing [RFC5761] using one of the following policies:
negotiate: The browser will gather both RTP and RTCP candidates but negotiate: The browser will gather both RTP and RTCP candidates but
also will offer "a=rtcp-mux", thus allowing for compatibility with also will offer "a=rtcp-mux", thus allowing for compatibility with
either multiplexing or non-multiplexing endpoints. either multiplexing or non-multiplexing endpoints.
require: The browser will only gather RTP candidates. [[OPEN ISSUE: require: The browser will only gather RTP candidates. This halves
how should the answerer behave. https://github.com/rtcweb- the number of candidates that the offerer needs to gather. When
wg/jsep/issues/114]] This halves the number of candidates that the acting as answerer, the browser will reject any m= section that
offerer needs to gather. does not provide an "a=rtcp-mux" attribute.
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 19, line 14 skipping to change at page 21, line 26
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", or "answer". These types provide information as "offer", "pranswer", "answer" or "rollback". These types provide
to how the description parameter should be parsed, and how the media information as to how the description parameter should be parsed, and
state should be changed. how the media 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
transmission, if the answer does not specify an inactive media transmission, if the answer does not specify an inactive media
direction. A description used as a "pranswer" may be applied as a direction. A description used as a "pranswer" may be applied as a
response to an "offer", or an update to a previously sent "pranswer". response to an "offer", or an update to a previously sent "pranswer".
"answer" indicates that a description should be parsed as an answer, "answer" indicates that a description should be parsed as an answer,
the offer-answer exchange should be considered complete, and any the offer-answer exchange should be considered complete, and any
resources (decoders, candidates) that are no longer needed can be resources (decoders, candidates) that are no longer needed can be
released. A description used as an "answer" may be applied as a released. A description used as an "answer" may be applied as a
response to a "offer", or an update to a previously sent "pranswer". response to an "offer", or an update to a previously sent "pranswer".
The only difference between a provisional and final answer is that The only difference between a provisional and final answer is that
the final answer results in the freeing of any unused resources that the final answer results in the freeing of any unused resources that
were allocated as a result of the offer. As such, the application were allocated as a result of the offer. As such, the application
can use some discretion on whether an answer should be applied as can use some discretion on whether an answer should be applied as
provisional or final, and can change the type of the session provisional or final, and can change the type of the session
description as needed. For example, in a serial forking scenario, an description as needed. For example, in a serial forking scenario, an
application may receive multiple "final" answers, one from each application may receive multiple "final" answers, one from each
remote endpoint. The application could choose to accept the initial remote endpoint. The application could choose to accept the initial
answers as provisional answers, and only apply an answer as final answers as provisional answers, and only apply an answer as final
skipping to change at page 21, line 21 skipping to change at page 23, line 38
A rollback is performed by supplying a session description of type A rollback is performed by supplying a session description of type
"rollback" with empty contents to either setLocalDescription or "rollback" with empty contents to either setLocalDescription or
setRemoteDescription, depending on which was most recently used (i.e. setRemoteDescription, depending on which was most recently used (i.e.
if the new offer was supplied to setLocalDescription, the rollback if the new offer was supplied to setLocalDescription, the rollback
should be done using setLocalDescription as well). should be done using setLocalDescription as well).
4.1.5. setLocalDescription 4.1.5. setLocalDescription
The setLocalDescription method instructs the PeerConnection to apply The setLocalDescription method instructs the PeerConnection to apply
the supplied SDP blob as its local configuration. The type field the supplied session description as its local configuration. The
indicates whether the blob should be processed as an offer, type field indicates whether the description should be processed as
provisional answer, or final answer; offers and answers are checked an offer, provisional answer, or final answer; offers and answers are
differently, using the various rules that exist for each SDP line. checked differently, using the various rules that exist for each SDP
line.
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 receiving and decoding media. In order to up local resources for receiving and decoding media. In order to
successfully handle scenarios where the application wants to offer to successfully handle scenarios where the application wants to offer to
change from one media format to a different, incompatible format, the change from one media format to a different, incompatible format, the
PeerConnection must be able to simultaneously support use of both the PeerConnection must be able to simultaneously support use of both the
old and new local descriptions (e.g. support codecs that exist in old and new local descriptions (e.g. support codecs that exist in
both descriptions) until a final answer is received, at which point both descriptions) until a final answer is received, at which point
the PeerConnection can fully adopt the new local description, or roll the PeerConnection can fully adopt the new local description, or roll
back to the old description if the remote side denied the change. back to the old description if the remote side denied the change.
skipping to change at page 21, line 50 skipping to change at page 24, line 19
begin gathering candidates for them. begin gathering candidates for them.
If setRemoteDescription was previous called with an offer, and If setRemoteDescription was previous called with an offer, and
setLocalDescription is called with an answer (provisional or final), setLocalDescription 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.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 session description as the desired remote configuration.
setLocalDescription, the type field of the indicates how the blob As in setLocalDescription, the type field of the description
should be processed. indicates how it 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 setLocalDescription was previously called with an offer, and If setLocalDescription was previously called with an offer, and
setRemoteDescription 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
skipping to change at page 30, line 5 skipping to change at page 32, line 20
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. The audio and video codecs specified in [RFC4566], Section 6. The audio and video codecs
that MUST be supported are specified in [I-D.ietf-rtcweb-audio] that MUST be supported are specified in [I-D.ietf-rtcweb-audio]
(see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5). (see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5).
o If this m= section is for media with configurable frame sizes, o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6. specified in [RFC4566], Section 6.
o If this m= section is for video media, an "a=imageattr" line, as
specified in Section 3.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=rtpmap" and "a=fmtp" lines, o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in [RFC4566], Section 6. The FEC mechanisms that as specified in [RFC4566], Section 6. The FEC mechanisms that
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
Section 6, and specific usage for each media type is outlined in Section 6, and specific usage for each media type is outlined in
Sections 4 and 5. Sections 4 and 5.
o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], o "a=ice-ufrag" and "a=ice-pwd" 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 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
skipping to change at page 30, line 51 skipping to change at page 33, line 21
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] and Section 3.5.
specified for MSTs? Are they randomly generated for each
MediaStream? If so, can two MediaStreams be synced? See:
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 with semantics set with the FEC SSRC, and an "a=ssrc-group" line with semantics set
to "FEC-FR" and including the primary and FEC SSRCs, as specified to "FEC-FR" and including the primary and FEC SSRCs, as specified
in [RFC5956], section 4.3. For simplicity, if both RTX and FEC in [RFC5956], section 4.3. For simplicity, if both RTX and FEC
skipping to change at page 31, line 48 skipping to change at page 34, line 15
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.
The next step is to generate session-level lip sync groups as defined
in [RFC5888], Section 7. For each MediaStream with more than one
MediaStreamTrack, a group of type "LS" MUST be added that contains
the mid values for each MediaStreamTrack in that MediaStream.
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
identical. This promotes readability, especially if one of a set of identical. This promotes readability, especially if one of a set of
initially identical attributes is subsequently changed. initially identical attributes is subsequently changed.
Attributes other than the ones specified above MAY be included, Attributes other than the ones specified above MAY be included,
except for the following attributes which are specifically except for the following attributes which are specifically
incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage],
and MUST NOT be included: and MUST NOT be included:
skipping to change at page 33, line 50 skipping to change at page 36, line 26
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?
https://github.com/rtcweb-wg/jsep/issues/143]
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 35, line 5 skipping to change at page 37, line 27
o The "a=rtcp-rsize" line MUST only be added if present in the o The "a=rtcp-rsize" line MUST only be added if present in the
remote description. remote description.
The "a=group:BUNDLE" attribute MUST include the mid identifiers The "a=group:BUNDLE" attribute MUST include the mid identifiers
specified in the BUNDLE group in the most recent answer, minus any m= specified in the BUNDLE group in the most recent answer, minus any m=
sections that have been marked as rejected, plus any newly added or sections that have been marked as rejected, plus any newly added or
re-enabled m= sections. In other words, the BUNDLE attribute must re-enabled m= sections. In other words, the BUNDLE attribute must
contain all m= sections that were previously bundled, as long as they contain all m= sections that were previously bundled, as long as they
are still alive, as well as any new m= sections. are still alive, as well as any new m= sections.
The "LS" groups are generated in the same way as with initial offers.
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 options are present. description if the following options 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, and M audio MediaStreamTracks have been added to the value of N, and M audio MediaStreamTracks have been added to the
skipping to change at page 37, line 14 skipping to change at page 39, line 37
Section 5.2. For many cases, this is not a problem. However, if any Section 5.2. For many cases, this is not a problem. However, if any
mandatory SDP attributes are missing, or functionality listed as mandatory SDP attributes are missing, or functionality listed as
mandatory-to-use above is not present, this MUST be treated as an mandatory-to-use above is not present, this MUST be treated as an
error, and MUST cause the affected m= sections to be marked as error, and MUST cause the affected m= sections to be marked as
rejected. rejected.
The first step in generating an initial answer is to generate The first step in generating an initial answer is to generate
session-level attributes. The process here is identical to that session-level attributes. The process here is identical to that
indicated in the Initial Offers section above. indicated in the Initial Offers section above.
The next step is to generate lip sync groups as defined in [RFC5888],
Section 7. For each MediaStream with more than one MediaStreamTrack,
a group of type "LS" MUST be added that contains the mid values for
each MediaStreamTrack in that MediaStream. In some cases this may
result in adding a mid to a given LS group that was not in that LS
group in the associated offer. Although this is not allowed by
[RFC5888], it is allowed when implementing this specification.
The next step is to generate m= sections for each m= section that is The next step is to generate m= sections for each m= section that is
present in the remote offer, as specified in [RFC3264], Section 6. present in the remote offer, as specified in [RFC3264], Section 6.
For the purposes of this discussion, any session-level attributes in For the purposes of this discussion, any session-level attributes in
the offer that are also valid as media-level attributes SHALL be the offer that are also valid as media-level attributes SHALL be
considered to be present in each m= section. considered to be present in each m= section.
The next step is to go through each offered m= section. If there is The next step is to go through each offered m= section. If there is
a local MediaStreamTrack of the same type which has been added to the a local MediaStreamTrack of the same type which has been added to the
PeerConnection via addStream and not yet associated with a m= PeerConnection via addStream and not yet associated with a m=
section, and the specific m= section is either sendrecv or recvonly, section, and the specific m= section is either sendrecv or recvonly,
skipping to change at page 39, line 7 skipping to change at page 41, line 38
supported are specified in [I-D.ietf-rtcweb-audio] (see Section 3) supported are specified in [I-D.ietf-rtcweb-audio] (see Section 3)
and [I-D.ietf-rtcweb-video] (see Section 5). Note that for and [I-D.ietf-rtcweb-video] (see Section 5). Note that for
simplicity, the answerer MAY use different payload types 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, o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6. specified in [RFC4566], Section 6.
o If this m= section is for video media, an "a=imageattr" line, as
specified in Section 3.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, "a=rtpmap" and "a=fmtp" lines, o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in [RFC4566], Section 6. The FEC mechanisms that as specified in [RFC4566], Section 6. The FEC mechanisms that
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
Section 6, and specific usage for each media type is outlined in Section 6, and specific usage for each media type is outlined in
skipping to change at page 40, line 13 skipping to change at page 42, line 45
in [RFC6904], Section 4. 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, along with the mandatory "cname" source
attribute, as specified in Section 6.1, indicating the CNAME for
the source. The CNAME must be generated in accordance with
[RFC7022] and Section 3.5.
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 with semantics set to "FEC-FR" SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR"
skipping to change at page 44, line 19 skipping to change at page 47, line 5
defined in [RFC4566], Section 5. Note that while the specific line defined in [RFC4566], Section 5. Note that while the specific line
types (e.g. "v=", "c=") MUST occur in the defined order, lines of the types (e.g. "v=", "c=") MUST occur in the defined order, lines of the
same type (typically "a=") can occur in any order, and their ordering same type (typically "a=") can occur in any order, and their ordering
is not meaningful. is not meaningful.
For non-attribute (non-"a=") lines, their sequencing, syntax, and For non-attribute (non-"a=") lines, their sequencing, syntax, and
semantics, are checked, as mentioned above. The following lines are semantics, are checked, as mentioned above. The following lines are
not meaningful in the JSEP context and MAY be discarded once they not meaningful in the JSEP context and MAY be discarded once they
have been checked. have been checked.
The "c=" line MUST be checked for syntax but its value is not
used. This supersedes the guidance in [RFC5245], Section 6.1, to
use "ice-mismatch" to indicate mismatches between "c=" and the
candidate lines; because JSEP always uses ICE, "ice-mismatch" is
not useful in this context.
TODO TODO
The remaining lines are processed as follows: The remaining lines are processed as follows:
The "c=" line MUST be parsed and stored. The "b=" line, if present, MUST be parsed as specified in
[RFC4566], Section 5.8, and the bwtype and bandwidth values
stored.
[OPEN ISSUE: For example, because session-level bandwidth is
ambiguous when multiple media streams are present, a "b=" line at
session level is not useful and its value SHOULD be ignored.
[OPEN ISSUE: is this WG consensus? Are there other non-a= lines [OPEN ISSUE: is this WG consensus? Are there other non-a= lines
that we need to do more than just syntactical validation, e.g. that we need to do more than just syntactical validation, e.g.
v=?] v=?]
Specific processing MUST be applied for the following session-level Specific processing MUST be applied for the following session-level
attribute ("a=") lines: attribute ("a=") lines:
o Any "a=group" lines are parsed as specified in [RFC5888], o Any "a=group" lines are parsed as specified in [RFC5888],
Section 5, and the group's semantics and mids are stored. Section 5, and the group's semantics and mids are stored.
skipping to change at page 45, line 33 skipping to change at page 48, line 23
Like the session-level lines, the media session lines MUST occur in Like the session-level lines, the media session lines MUST occur in
the specific order and with the specific syntax defined in [RFC4566], the specific order and with the specific syntax defined in [RFC4566],
Section 5. Section 5.
The "m=" line itself MUST be parsed as described in [RFC4566], The "m=" line itself MUST be parsed as described in [RFC4566],
Section 5.14, and the media, port, proto, and fmt values stored. Section 5.14, and the media, port, proto, and fmt values stored.
Following the "m=" line, specific processing MUST be applied for the Following the "m=" line, specific processing MUST be applied for the
following non-attribute lines: following non-attribute lines:
o The "c=" line, if present, MUST be parsed as specified in o As with the "c=" line at the session level, the "c=" line MUST be
[RFC4566], Section 5.7, and its contents stored. parsed according to [RFC4566], Section 5.7, but its value is not
used.
o The "b=" line, if present, MUST be parsed as specified in o The "b=" line, if present, MUST be parsed as specified in
[RFC4566], Section 5.8, and the bwtype and bandwidth values [RFC4566], Section 5.8, and the bwtype and bandwidth values
stored. stored.
Specific processing MUST also be applied for the following attribute Specific processing MUST also be applied for the following attribute
lines: lines:
o If present, a single "a=ice-lite" line is parsed as specified in
[RFC5245], Section 15.3, and a value indicating the presence of
ice-lite is stored.
o If present, a single "a=ice-ufrag" line is parsed as specified in o If present, a single "a=ice-ufrag" line is parsed as specified in
[RFC5245], Section 15.4, and the ufrag value is stored. [RFC5245], Section 15.4, and the ufrag value is stored.
o If present, a single "a=ice-pwd" line is parsed as specified in o If present, a single "a=ice-pwd" line is parsed as specified in
[RFC5245], Section 15.4, and the password value is stored. [RFC5245], Section 15.4, and the password value is stored.
o If present, a single "a=ice-options" line is parsed as specified o If present, a single "a=ice-options" line is parsed as specified
in [RFC5245], Section 15.5, and the set of specified options is in [RFC5245], Section 15.5, and the set of specified options is
stored. stored.
skipping to change at page 48, line 32 skipping to change at page 51, line 25
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 session description MUST NOT be changed
changed between the createOffer and the setLocalDescription (or between the createOffer and the setLocalDescription (or between the
between the createAnswer and the setLocalDescription), since they createAnswer and the setLocalDescription), since they reflect
reflect transport attributes that are solely under browser control, transport attributes that are solely under browser control, and the
and the browser MUST NOT honor an attempt to change them: 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).
o The DTLS fingerprint(s) (a=fingerprint). o The DTLS fingerprint(s) (a=fingerprint).
The following modifications, if done by the browser to a description The following modifications, if done by the browser to a description
skipping to change at page 68, line 39 skipping to change at page 70, line 39
[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.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", RFC
6236, May 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[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, April Real-time Transport Protocol (SRTP)", RFC 6904, 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.
skipping to change at page 70, line 16 skipping to change at page 72, line 16
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. Change log Appendix A. Change log
Note: This section will be removed by RFC Editor before publication. Note: This section will be removed by RFC Editor before publication.
Changes in draft-09:"> Changes in draft-09:
o Don't return null for {local,remote}Description after close(). o Don't return null for {local,remote}Description after close().
o Changed TCP/TLS to UDP/DTLS in RTP profile names. o Changed TCP/TLS to UDP/DTLS in RTP profile names.
o Separate out bundle and mux policy. o Separate out bundle and mux policy.
o Added specific references to FEC mechanisms. o Added specific references to FEC mechanisms.
o Added canTrickle mechanism. o Added canTrickle mechanism.
 End of changes. 36 change blocks. 
127 lines changed or deleted 260 lines changed or added

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