draft-ietf-rtcweb-jsep-12.txt   draft-ietf-rtcweb-jsep-13.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: April 20, 2016 Cisco Expires: September 10, 2016 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
October 18, 2015 March 9, 2016
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-12 draft-ietf-rtcweb-jsep-13
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 April 20, 2016. This Internet-Draft will expire on September 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . 7 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 . . . . . . . . . . . . . . 12
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. Video Size Negotiation . . . . . . . . . . . . . . . . . 13 3.5. Video Size Negotiation . . . . . . . . . . . . . . . . . 14
3.5.1. Creating an imageattr Attribute . . . . . . . . . . . 13 3.5.1. Creating an imageattr Attribute . . . . . . . . . . . 14
3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14 3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 15
3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15 3.6. Interactions With Forking . . . . . . . . . . . . . . . . 16
3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15 3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 16
3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16 3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 17
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 18
4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 20
4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 21
4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 22
4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22
4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 23
4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 24
4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24
4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24 4.1.7. currentLocalDescription . . . . . . . . . . . . . . . 25
4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24 4.1.8. pendingLocalDescription . . . . . . . . . . . . . . . 25
4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 24 4.1.9. currentRemoteDescription . . . . . . . . . . . . . . 25
4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25 4.1.10. pendingRemoteDescription . . . . . . . . . . . . . . 25
4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26 4.1.11. canTrickleIceCandidates . . . . . . . . . . . . . . . 26
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26 4.1.12. setConfiguration . . . . . . . . . . . . . . . . . . 26
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26 4.1.13. addIceCandidate . . . . . . . . . . . . . . . . . . . 27
5.1.1. Implementation Requirements . . . . . . . . . . . . . 26 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 27
5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 27
5.1.3. Profile Names and Interoperability . . . . . . . . . 28 5.1.1. Implementation Requirements . . . . . . . . . . . . . 28
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 29
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29 5.1.3. Profile Names and Interoperability . . . . . . . . . 29
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 30
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 30
5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 35
5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 38 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 38
5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 38
5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 39
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 39 5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 39
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39 5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 39
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 40
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 40
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 45 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 45
5.4. Processing a Local Description . . . . . . . . . . . . . 45 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 46
5.5. Processing a Remote Description . . . . . . . . . . . . . 45 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 46
5.6. Parsing a Session Description . . . . . . . . . . . . . . 46 5.4. Processing a Local Description . . . . . . . . . . . . . 46
5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46 5.5. Processing a Remote Description . . . . . . . . . . . . . 47
5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 48 5.6. Parsing a Session Description . . . . . . . . . . . . . . 47
5.6.3. Semantics Verification . . . . . . . . . . . . . . . 49 5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 48
5.7. Applying a Local Description . . . . . . . . . . . . . . 50 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 50
5.8. Applying a Remote Description . . . . . . . . . . . . . . 51 5.6.3. Semantics Verification . . . . . . . . . . . . . . . 52
5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 53 5.7. Applying a Local Description . . . . . . . . . . . . . . 53
6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 54 5.8. Applying a Remote Description . . . . . . . . . . . . . . 54
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 56
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 56 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 57
7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 60 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 59
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 63
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 72
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
11.1. Normative References . . . . . . . . . . . . . . . . . . 73
11.2. Informative References . . . . . . . . . . . . . . . . . 75 11.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 76 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
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 10, line 48 skipping to change at page 10, line 48
3.4.1. ICE Gathering Overview 3.4.1. ICE Gathering Overview
JSEP gathers ICE candidates as needed by the application. Collection JSEP gathers ICE candidates as needed by the application. Collection
of ICE candidates is referred to as a gathering phase, and this is 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 triggered either by the addition of a new or recycled m= line to the
local session description, or new ICE credentials in the description, local session description, or new ICE credentials in the description,
indicating an ICE restart. Use of new ICE credentials can be indicating an ICE restart. Use of new ICE credentials can be
triggered explicitly by the application, or implicitly by the browser triggered explicitly by the application, or implicitly by the browser
in response to changes in the ICE configuration. in response to changes in the ICE configuration.
When the ICE configuration changes in a way that requires a new
gathering phase, a 'needs-ice-restart' bit is set. When this bit is
set, calls to the createOffer API will generate new ICE credentials.
This bit is cleared by a call to the setLocalDescription API with new
ICE credentials from either an offer or an answer, i.e., from either
a local- or remote-initiated ICE restart.
When a new gathering phase starts, the ICE Agent will notify the When a new gathering phase starts, the ICE Agent will notify the
application that gathering is occurring through an event. Then, when application that gathering is occurring through an event. Then, when
each new ICE candidate becomes available, the ICE Agent will supply each new ICE candidate becomes available, the ICE Agent will supply
it to the application via an additional event; these candidates will it to the application via an additional event; these candidates will
also automatically be added to the local session description. also automatically be added to the current and/or pending local
session description. Finally, when all candidates have been
Finally, when all candidates have been gathered, an event will be gathered, an event will be dispatched to signal that the gathering
dispatched to signal that the gathering process is complete. process is complete.
Note that gathering phases only gather the candidates needed by Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= lines; other m= lines continue to use new/recycled/restarting m= lines; other m= lines continue to use
their existing candidates. their existing candidates. Also, when bundling is active, candidates
are only gathered (and exchanged) for the m= lines referenced in
BUNDLE-tags, as described in
[I-D.ietf-mmusic-sdp-bundle-negotiation].
3.4.2. ICE Candidate Trickling 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-ice-trickle]. This process allows the callee to begin
begin acting upon the call and setting up the ICE (and perhaps DTLS) 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, as JSEP supports optional candidate trickling by providing APIs, as
described above, that provide control and feedback on the ICE described above, that provide control and feedback on the ICE
candidate gathering process. Applications that support candidate candidate gathering process. Applications that support candidate
trickling can send the initial offer immediately and send individual trickling can send the initial offer immediately and send individual
candidates when they get the notified of a new candidate; candidates when they get the notified of a new candidate;
skipping to change at page 12, line 26 skipping to change at page 12, line 43
Typically, when gathering ICE candidates, the browser will gather all Typically, when gathering ICE candidates, the browser will gather all
possible forms of initial candidates - host, server reflexive, and possible forms of initial candidates - host, server reflexive, and
relay. However, in certain cases, applications may want to have more relay. However, in certain cases, applications may want to have more
specific control over the gathering process, due to privacy or specific control over the gathering process, due to privacy or
related concerns. For example, one may want to suppress the use of related concerns. For example, one may want to suppress the use of
host candidates, to avoid exposing information about the local host candidates, to avoid exposing information about the local
network, or go as far as only using relay candidates, to leak as network, or go as far as only using relay candidates, to leak as
little location information as possible (note that these choices come little location information as possible (note that these choices come
with corresponding operational costs). To accomplish this, the with corresponding operational costs). To accomplish this, the
browser MUST allow the application to restrict which ICE candidates browser MUST allow the application to restrict which ICE candidates
are used in a session. In addition, administrators may also wish to are used in a session. Note that this filtering is applied on top of
control the set of ICE candidates, and so the browser SHOULD also any restrictions the browser chooses to enforce regarding which IP
allow control via local policy, with the most restrictive policy addresses are permitted for the application, as discussed in
prevailing. [I-D.shieh-rtcweb-ip-handling].
There may also be cases where the application wants to change which There may also be cases where the application wants to change which
types of candidates are used while the session is active. A prime types of candidates are used while the session is active. A prime
example is where a callee may initially want to use only relay example is where a callee may initially want to use only relay
candidates, to avoid leaking location information to an arbitrary candidates, to avoid leaking location information to an arbitrary
caller, but then change to use all candidates (for lower operational caller, but then change to use all candidates (for lower operational
cost) once the user has indicated they want to take the call. For cost) once the user has indicated they want to take the call. For
this scenario, the browser MUST allow the candidate policy to be this scenario, the browser MUST allow the candidate policy to be
changed in mid-session, subject to the aforementioned interactions changed in mid-session, subject to the aforementioned interactions
with local policy. with local policy.
skipping to change at page 14, line 42 skipping to change at page 15, line 12
specific "a=imageattr" attributes MUST be inserted for each payload specific "a=imageattr" attributes MUST be inserted for each payload
type. type.
As an example, consider a system with a HD-capable, multiformat video As an example, consider a system with a HD-capable, multiformat video
decoder, where the application has constrained the received track to decoder, where the application has constrained the received track to
at most 360p. In this case, the implemention would generate this at most 360p. In this case, the implemention would generate this
attribute: attribute:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]
This declaration indicates that the receiver is capable of decoding
any image resolution from 16x16 up to 640x360 pixels.
3.5.2. Interpreting an imageattr Attribute 3.5.2. Interpreting an imageattr Attribute
[RFC6236] defines "a=imageattr" to be an advisory field. This means [RFC6236] defines "a=imageattr" to be an advisory field. This means
that it does not absolutely constrain the video formats that the that it does not absolutely constrain the video formats that the
sender can use, but gives an indication of the preferred values. sender can use, but gives an indication of the preferred values.
This specification prescribes more specific behavior. When a sender This specification prescribes more specific behavior. When a sender
of a given MediaStreamTrack, which is producing video of a certain of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first resolution, receives an "a=imageattr recv" attribute, it MUST check
check to see if the original resolution meets the criteria specified to see if the original resolution meets the size criteria specified
in the attribute, and transmit it untouched if so. If the original in the attribute, and adapt the resolution accordingly by scaling (if
resolution is too large for the attribute criteria, the sender SHOULD appropriate). Note that when considering a MediaStreamTrack that is
apply downscaling to the output of the MediaStreamTrack in order to producing rotated video, the unrotated resolution MUST be used. This
satisfy the criteria. is required regardless of whether the receiver supports performing
receive-side rotation (e.g., through CVO), as it significantly
simplifies the matching logic.
If the receiver requires a minimum resolution which is greater than For an "a=imageattr recv" attribute, only size limits are considered.
the native resolution of the video, upscaling is needed, but this may Any other values, e.g. aspect ratio, MUST be ignored.
not be appropriate in all cases. To address this concern, the
application can set an upscaling policy for each sent track. For When communicating with a non-JSEP endpoint, multiple relevant
this case, if upscaling is permitted by policy, the sender SHOULD "a=imageattr recv" attributes may be received. If this occurs,
apply upscaling in order to provide the desired resolution. attributes other than the one with the highest "q=" value MUST be
Otherwise, the sender MUST NOT apply upscaling. The sender SHOULD ignored.
NOT upscale in other cases, even if the policy permits it.
If an "a=imageattr recv" attribute references a different video codec
than what has been selected for the MediaStreamTrack, it MUST be
ignored.
If the original resolution matches the size limits in the attribute,
the track MUST be transmitted untouched.
If the original resolution exceeds the size limits in the attribute,
the sender SHOULD apply downscaling to the output of the
MediaStreamTrack in order to satisfy the limits. Downscaling MUST
NOT change the track aspect ratio.
If the original resolution is less than the size limits in the
attribute, upscaling is needed, but this may not be appropriate in
all cases. To address this concern, the application can set an
upscaling policy for each sent track. For this case, if upscaling is
permitted by policy, the sender SHOULD apply upscaling in order to
provide the desired resolution. Otherwise, the sender MUST NOT apply
upscaling. The sender SHOULD NOT upscale in other cases, even if the
policy permits it. Upscaling MUST NOT change the track aspect ratio.
If there is no appropriate and permitted scaling mechanism that If there is no appropriate and permitted scaling mechanism that
allows the received criteria to be satisfied, the sender MUST NOT allows the received size limits to be satisfied, the sender MUST NOT
transmit the track. transmit the track.
In the special case of receiving a maximum resolution of [0, 0], as In the special case of receiving a maximum resolution of [0, 0], as
described above, the sender MUST NOT transmit the track. described above, the sender MUST NOT transmit the track.
3.6. Interactions With Forking 3.6. 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".
skipping to change at page 16, line 20 skipping to change at page 17, line 16
a final answer, ending the setup flow. a final answer, ending the setup flow.
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. pending remote description as a final answer.
3.6.2. Parallel Forking 3.6.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
skipping to change at page 17, line 25 skipping to change at page 18, line 22
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, as well as servers and credentials to use when gathering candidates, as well as
the initial ICE candidate policy and pool size, and also the BUNDLE the initial ICE candidate policy and pool size, and also the bundle
policy to use. policy to use.
If an ICE candidate policy is specified, it functions as described in If an ICE candidate policy is specified, it functions as described in
Section 3.4.3, causing the browser to only surface the permitted Section 3.4.3, causing the browser to only surface the permitted
candidates to the application, and only use those candidates for candidates (including any internal browser filtering) to the
connectivity checks. The set of available policies is as follows: 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 all: All candidates permitted by browser policy will be gathered and
filtered out. This prevents exposure of internal network details, used.
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. relay: All candidates except relay candidates will be filtered out.
This obfuscates the location information that might be ascertained This obfuscates the location information that might be ascertained
by the remote peer from the received candidates. Depending on how by the remote peer from the received candidates. Depending on how
the application deploys its relay servers, this could obfuscate the application deploys its relay servers, this could obfuscate
location to a metro or possibly even global level. location to a metro or possibly even global level.
Although it can be overridden by local policy, the default ICE The default ICE candidate policy MUST be set to "all" as this is
candidate policy MUST be set to allow all candidates, as this generally the desired policy, and also typically reduces use of
minimizes use of application STUN/TURN server resources. application TURN server resources significantly.
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]. Regardless of policy, the [I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the
application will always try to negotiate BUNDLE onto a single application will always try to negotiate bundle onto a single
transport, and will offer a single BUNDLE group across all media transport, and will offer a single bundle group across all media
section; use of this single transport is contingent upon the answerer section; use of this single transport is contingent upon the answerer
accepting BUNDLE. However, by specifying a policy from the list accepting bundle. However, by specifying a policy from the list
below, the application can control exactly how aggressively it will below, the application can control exactly how aggressively it will
try to BUNDLE media streams together, which affects how it will try to bundle media streams together, which affects how it will
interoperate with a non-BUNDLE-aware endpoint. When negotiating with interoperate with a non-bundle-aware endpoint. When negotiating with
a non-BUNDLE-aware endpoint, only the streams not marked as bundle- a non-bundle-aware endpoint, only the streams not marked as bundle-
only streams will be established. The set of available policies is only streams will be established.
as follows:
The set of available policies is as follows:
balanced: The first media section of each type (audio, video, or balanced: The first media section of each type (audio, video, or
application) will contain transport parameters, which will allow application) will contain transport parameters, which will allow
an answerer to unbundle that section. The second and any an answerer to unbundle that section. The second and any
subsequent media section of each type will be marked bundle-only. subsequent media section of each type will be marked bundle-only.
The result is that if there are N distinct media types, then The result is that if there are N distinct media types, then
candidates will be gathered for for N media streams. This policy candidates will be gathered for for N media streams. This policy
balances desire to multiplex with the need to ensure basic audio balances desire to multiplex with the need to ensure basic audio
and video can still be negotiated in legacy cases. and video can still be negotiated in legacy cases.
max-compat: All media sections will contain transport parameters; max-compat: All media sections will contain transport parameters;
none will be marked as bundle-only. This policy will allow all none will be marked as bundle-only. This policy will allow all
streams to be received by non-BUNDLE-aware endpoints, but require streams to be received by non-bundle-aware endpoints, but require
separate candidates to be gathered for each media stream. separate candidates to be gathered for each media stream.
max-bundle: Only the first media section will contain transport max-bundle: Only the first media section will contain transport
parameters; all streams other than the first will be marked as parameters; all streams other than the first will be marked as
bundle-only. This policy aims to minimize candidate gathering and bundle-only. This policy aims to minimize candidate gathering and
maximize multiplexing, at the cost of less compatibility with maximize multiplexing, at the 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. This halves require: The browser will only gather RTP candidates. This halves
the number of candidates that the offerer needs to gather. When the number of candidates that the offerer needs to gather. When
acting as answerer, the browser will reject any m= section that acting as answerer, the browser will reject any m= section that
does not provide an "a=rtcp-mux" attribute. does not provide an "a=rtcp-mux" attribute.
The default multiplexing policy MUST be set to "require".
Implementations MAY choose to reject attempts by the application to
set the multiplexing policy to "negotiate".
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
allow for the following manipulations to be performed: allow for the following manipulations to be performed:
skipping to change at page 22, line 51 skipping to change at page 23, line 44
call is ongoing, and one side wants to change some of the session call is ongoing, and one side wants to change some of the session
parameters; that side generates an updated offer and then calls parameters; that side generates an updated offer and then calls
setLocalDescription. However, the remote side, either before or setLocalDescription. However, the remote side, either before or
after setRemoteDescription, decides it does not want to accept the after setRemoteDescription, decides it does not want to accept the
new parameters, and sends a reject message back to the offerer. Now, new parameters, and sends a reject message back to the offerer. Now,
the offerer, and possibly the answerer as well, need to return to a the offerer, and possibly the answerer as well, need to return to a
stable state and the previous local/remote description. To support stable state and the previous local/remote description. To support
this, we introduce the concept of "rollback". this, we introduce the concept of "rollback".
A rollback discards any proposed changes to the session, returning A rollback discards any proposed changes to the session, returning
the state machine to the stable state, and setting the modified local the state machine to the stable state, and setting the pending local
and/or remote description back to their previous values. Any and/or remote description back to null. Any resources or candidates
resources or candidates that were allocated by the abandoned local that were allocated by the abandoned local description are discarded;
description are discarded; any media that is received will be any media that is received will be processed according to the
processed according to the previous local and remote descriptions. previous local and remote descriptions. Rollback can only be used to
Rollback can only be used to cancel proposed changes; there is no cancel proposed changes; there is no support for rolling back from a
support for rolling back from a stable state to a previous stable stable state to a previous stable state. Note that this implies that
state. Note that this implies that once the answerer has performed once the answerer has performed setLocalDescription with his answer,
setLocalDescription with his answer, this cannot be rolled back. this cannot be rolled back.
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
skipping to change at page 23, line 32 skipping to change at page 24, line 27
type field indicates whether the description should be processed as type field indicates whether the description should be processed as
an offer, provisional answer, or final answer; offers and answers are an offer, provisional answer, or final answer; offers and answers are
checked differently, using the various rules that exist for each SDP checked differently, using the various rules that exist for each SDP
line. 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 current and pending local descriptions (e.g. support codecs that
both descriptions) until a final answer is received, at which point exist in both descriptions) until a final answer is received, at
the PeerConnection can fully adopt the new local description, or roll which point the PeerConnection can fully adopt the pending local
back to the old description if the remote side denied the change. description, or roll back to the current description if the remote
side denied the change.
This API indirectly controls the candidate gathering process. When a This API indirectly controls the candidate gathering process. When a
local description is supplied, and the number of transports currently local description is supplied, and the number of transports currently
in use does not match the number of transports needed by the local in use does not match the number of transports needed by the local
description, the PeerConnection will create transports as needed and description, the PeerConnection will create transports as needed and
begin gathering candidates for them. begin gathering candidates for them.
If setRemoteDescription was previous called with an offer, and If setRemoteDescription was previously 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 session description as the desired remote configuration. the supplied session description as the desired remote configuration.
As in setLocalDescription, the type field of the description As in setLocalDescription, the type field of the description
indicates how it 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. currentLocalDescription
The localDescription method returns a copy of the current local The currentLocalDescription method returns a copy of the current
configuration, i.e. what was most recently passed to negotiated local description - i.e., the local description from the
setLocalDescription, plus any local candidates that have been last successful offer/answer exchange - in addition to any local
generated by the ICE Agent. candidates that have been generated by the ICE Agent since the local
description was set.
[[OPEN ISSUE: Do we need to expose accessors for both the current and A null object will be returned if an offer/answer exchange has not
proposed local description? https://github.com/rtcweb-wg/jsep/ yet been completed.
issues/16]]
A null object will be returned if the local description has not yet 4.1.8. pendingLocalDescription
been established.
4.1.8. remoteDescription The pendingLocalDescription method returns a copy of the local
description currently in negotiation - i.e., a local offer set
without any corresponding remote answer - in addition to any local
candidates that have been generated by the ICE Agent since the local
description was set.
The remoteDescription method returns a copy of the current remote A null object will be returned if the state of the PeerConnection is
configuration, i.e. what was most recently passed to "stable" or "have-remote-offer".
setRemoteDescription, plus any remote candidates that have been
supplied via processIceMessage.
[[OPEN ISSUE: Do we need to expose accessors for both the current and 4.1.9. currentRemoteDescription
proposed remote description? https://github.com/rtcweb-wg/jsep/
issues/16]]
A null object will be returned if the remote description has not yet The currentRemoteDescription method returns a copy of the current
been established. negotiated remote description - i.e., the remote description from the
last successful offer/answer exchange - in addition to any remote
candidates that have been supplied via processIceMessage since the
remote description was set.
4.1.9. canTrickleIceCandidates A null object will be returned if an offer/answer exchange has not
yet been completed.
4.1.10. pendingRemoteDescription
The pendingRemoteDescription method returns a copy of the remote
description currently in negotiation - i.e., a remote offer set
without any corresponding local answer - in addition to any remote
candidates that have been supplied via processIceMessage since the
remote description was set.
A null object will be returned if the state of the PeerConnection is
"stable" or "have-local-offer".
4.1.11. canTrickleIceCandidates
The canTrickleIceCandidates property indicates whether the remote The canTrickleIceCandidates property indicates whether the remote
side supports receiving trickled candidates. There are three side supports receiving trickled candidates. There are three
potential values: potential values:
null: No SDP has been received from the other side, so it is not null: No SDP has been received from the other side, so it is not
known if it can handle trickle. This is the initial value before known if it can handle trickle. This is the initial value before
setRemoteDescription() is called. setRemoteDescription() is called.
true: SDP has been received from the other side indicating that it true: SDP has been received from the other side indicating that it
skipping to change at page 25, line 27 skipping to change at page 26, line 36
needed for Trickle ICE. However, applications can use the needed for Trickle ICE. However, applications can use the
canTrickleIceCandidates property to determine whether their peer can canTrickleIceCandidates property to determine whether their peer can
actually do Trickle ICE, i.e., whether it is safe to send an initial actually do Trickle ICE, i.e., whether it is safe to send an initial
offer or answer followed later by candidates as they are gathered. offer or answer followed later by candidates as they are gathered.
As "true" is the only value that definitively indicates remote As "true" is the only value that definitively indicates remote
Trickle ICE support, an application which compares Trickle ICE support, an application which compares
canTrickleIceCandidates against "true" will by default attempt Half canTrickleIceCandidates against "true" will by default attempt Half
Trickle on initial offers and Full Trickle on subsequent interactions Trickle on initial offers and Full Trickle on subsequent interactions
with a Trickle ICE-compatible agent. with a Trickle ICE-compatible agent.
4.1.10. setConfiguration 4.1.12. setConfiguration
The setConfiguration method allows the global configuration of the The setConfiguration method allows the global configuration of the
PeerConnection, which was initially set by constructor parameters, to PeerConnection, which was initially set by constructor parameters, to
be changed during the session. The effects of this method call be changed during the session. The effects of this method call
depend on when it is invoked, and differ depending on which specific depend on when it is invoked, and differ depending on which specific
parameters are changed: parameters are changed:
o Any changes to the STUN/TURN servers to use affect the next o Any changes to the STUN/TURN servers to use affect the next
gathering phase. If gathering has already occurred, this will gathering phase. If an ICE gathering phase has already started or
cause the next call to createOffer to generate new ICE completed, the 'needs-ice-restart' bit mentioned in Section 3.4.1
credentials, for the purpose of forcing an ICE restart and kicking will be set. This will cause the next call to createOffer to
off a new gathering phase, in which the new servers will be used. generate new ICE credentials, for the purpose of forcing an ICE
If the ICE candidate pool has a nonzero size, any existing restart and kicking off a new gathering phase, in which the new
candidates will be discarded, and new candidates will be gathered servers will be used. If the ICE candidate pool has a nonzero
from the new servers. 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 o Any change to the ICE candidate policy affects the next gathering
gathering phase, in similar fashion to the server changes phase. If an ICE gathering phase has already started or
described above. Note though that changes to the policy have no completed, the 'needs-ice-restart' bit will be set. Either way,
effect on the candidate pool, because pooled candidates are not changes to the policy have no effect on the candidate pool,
surfaced to the application until a gathering phase occurs, and so because pooled candidates are not surfaced to the application
any necessary filtering can still be done on any pooled until a gathering phase occurs, and so any necessary filtering can
candidates. still be done on any pooled candidates.
o Any changes to the ICE candidate pool size take effect o Any changes to the ICE candidate pool size take effect
immediately; if increased, additional candidates are pre-gathered; immediately; if increased, additional candidates are pre-gathered;
if decreased, the now-superfluous candidates are discarded. if decreased, the now-superfluous candidates are discarded.
o The BUNDLE and RTCP-multiplexing policies MUST NOT be changed o The bundle and RTCP-multiplexing policies MUST NOT be changed
after the construction of the PeerConnection. after the construction of the PeerConnection.
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.11. addIceCandidate 4.1.13. 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 current
description according to the rules defined for Trickle ICE. and/or pending remote description according to the rules defined for
Connectivity checks will be sent to the new candidate. Trickle ICE. 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.
5. SDP Interaction Procedures 5. SDP Interaction Procedures
This section describes the specific procedures to be followed when This section describes the specific procedures to be followed when
creating and parsing SDP objects. creating and parsing SDP objects.
skipping to change at page 27, line 6 skipping to change at page 28, line 14
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
[RFC5764] and TCP/DTLS/RTP/SAVPF [RFC5764], TCP/DTLS/RTP/SAVPF
[I-D.nandakumar-mmusic-proto-iana-registration] RTP profiles. [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/
SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP"
[I-D.ietf-mmusic-sctp-sdp] 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
skipping to change at page 30, line 26 skipping to change at page 31, line 39
Time Zones ("z=") lines are not useful in this context and SHOULD Time Zones ("z=") lines are not useful in this context and SHOULD
NOT be included. NOT be included.
o Encryption Keys ("k=") lines do not provide sufficient security o Encryption Keys ("k=") lines do not provide sufficient security
and MUST NOT be included. and MUST NOT be included.
o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9;
both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0 both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0
0". 0".
o An "a=msid-semantic:WMS" line MUST be added, as specified in o An "a=ice-options" line with the "trickle" option MUST be added,
[I-D.ietf-mmusic-msid], Section 4. as specified in [I-D.ietf-ice-trickle], Section 4.
The next step is to generate m= sections, as specified in [RFC4566] The next step is to generate m= sections, as specified in [RFC4566]
Section 5.14, for each MediaStreamTrack that has been added to the Section 5.14, for each MediaStreamTrack that has been added to the
PeerConnection via the addStream method. (Note that this method PeerConnection via the addStream method. (Note that this method
takes a MediaStream, which can contain multiple MediaStreamTracks, takes a MediaStream, which can contain multiple MediaStreamTracks,
and therefore multiple m= sections can be generated even if addStream and therefore multiple m= sections can be generated even if addStream
is only called once.) m=sections MUST be sorted first by the order in is only called once.) m=sections MUST be sorted first by the order in
which the MediaStreams were added to the PeerConnection, and then by which the MediaStreams were added to the PeerConnection, and then by
the alphabetical ordering of the media type for the MediaStreamTrack. the alphabetical ordering of the media type for the MediaStreamTrack.
For example, if a MediaStream containing both an audio and a video For example, if a MediaStream containing both an audio and a video
MediaStreamTrack is added to a PeerConnection, the resultant m=audio MediaStreamTrack is added to a PeerConnection, the resultant m=audio
section will precede the m=video section. If a second MediaStream section will precede the m=video section. If a second MediaStream
containing an audio MediaStreamTrack was added, it would follow the containing an audio MediaStreamTrack was added, it would follow the
m=video section. m=video section.
Each m= section, provided it is not being bundled into another m= Each m= section, provided it is not marked as bundle-only, MUST
section, MUST generate a unique set of ICE credentials and gather its generate a unique set of ICE credentials and gather its own unique
own unique set of ICE candidates. Otherwise, it MUST use the same set of ICE candidates. Bundle-only m= sections MUST NOT contain any
ICE credentials and candidates as the m= section into which it is ICE credentials and MUST NOT gather any candidates.
being bundled. Note that this means that for offers, any m= sections
which are not bundle-only MUST have unique ICE credentials and
candidates, since it is possible that the answerer will accept 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, but given that no candidates have yet been this m= section, but given that no candidates have yet been
gathered, the "dummy" port value of 9 (Discard) MUST be used, as gathered, the "dummy" port value of 9 (Discard) MUST be used, as
indicated in [I-D.ietf-mmusic-trickle-ice], Section 5.1. indicated in [I-D.ietf-ice-trickle], Section 5.1.
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, if the "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the
default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the
default candidate uses TCP transport. default candidate uses TCP transport.
The m= line MUST be followed immediately by a "c=" line, as specified 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 in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP4 gathered, the "c=" line must contain the "dummy" value "IN IP4
0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.
[[NOTE: This has not yet changed in the trickle ICE draft.]]
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. When o An "a=mid" line, as specified in [RFC5888], Section 4. When
generating mid values, it is RECOMMENDED that the values be 3 generating mid values, it is RECOMMENDED that the values be 3
bytes or less, to allow them to efficiently fit into the RTP bytes or less, to allow them to efficiently fit into the RTP
header extension defined in header extension defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
skipping to change at page 32, line 29 skipping to change at page 33, line 36
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-pwd" 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
in [I-D.ietf-mmusic-trickle-ice], Section 4.
o An "a=fingerprint" line for each of the endpoint's certificates, o An "a=fingerprint" line for each of the endpoint's certificates,
as specified in [RFC4572], Section 5; the digest algorithm used as specified in [RFC4572], Section 5; the digest algorithm used
for the fingerprint MUST match that used in the certificate for the fingerprint MUST match that used in the certificate
signature. 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.
skipping to change at page 33, line 27 skipping to change at page 34, line 29
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
are supported, the FEC SSRC MUST be the same as the RTX SSRC. are supported, the FEC SSRC MUST be the same as the RTX SSRC.
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 "balanced", 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 "UDP/DTLS/SCTP" if the default and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default
candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt" candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt"
value MUST be set to "webrtc-datachannel" as specified in value MUST be set to "webrtc-datachannel" as specified in
[I-D.ietf-mmusic-sctp-sdp], Section 4.1. [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
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-pwd",
passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=fingerprint", and "a=setup" lines MUST be included as mentioned
"a=setup" lines MUST be included as mentioned above, along with an above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-
"a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line port" line referencing the SCTP port number as defined in
referencing the SCTP port number as defined in
[I-D.ietf-mmusic-sctp-sdp], Section 4.1. [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
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 The next step is to generate session-level lip sync groups as defined
in [RFC5888], Section 7. For each MediaStream with more than one in [RFC5888], Section 7. For each MediaStream with more than one
MediaStreamTrack, a group of type "LS" MUST be added that contains MediaStreamTrack, a group of type "LS" MUST be added that contains
the mid values for each MediaStreamTrack in that MediaStream. 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.
skipping to change at page 34, line 26 skipping to change at page 35, line 28
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:
o "a=crypto" o "a=crypto"
o "a=key-mgmt" o "a=key-mgmt"
o "a=ice-lite" o "a=ice-lite"
Note that when BUNDLE is used, any additional attributes that are Note that when bundle is used, any additional attributes that are
added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes]
on how those attributes interact with BUNDLE. on how those attributes interact with bundle.
Note that these requirements are in some cases stricter than those of Note that these requirements are in some cases stricter than those of
SDP. Implementations MUST be prepared to accept compliant SDP even SDP. Implementations MUST be prepared to accept compliant SDP even
if it would not conform to the requirements for generating SDP in if it would not conform to the requirements for generating SDP in
this specification. this specification.
5.2.2. Subsequent Offers 5.2.2. Subsequent Offers
When createOffer is called a second (or later) time, or is called When createOffer is called a second (or later) time, or is called
after a local description has already been installed, the processing after a local description has already been installed, the processing
skipping to change at page 35, line 32 skipping to change at page 36, line 35
default RTCP candidate MUST be used, as indicated in [RFC5761], default RTCP candidate MUST be used, as indicated in [RFC5761],
section 5.1.3. In each case, if no candidates of the desired type 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 have yet been gathered, dummy values MUST be used, as described
above. above.
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 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (Section 5.2.3.3 was specified. "IceRestart" option (Section 5.2.3.3 was specified. If the m=
section is bundled into another m= section, it still MUST NOT
contain any ICE credentials.
o Within each m= section, for each candidate that has been gathered o If the m= section is not bundled into another m= section, for each
during the most recent gathering phase (see Section 3.4.1), an candidate that has been gathered during the most recent gathering
"a=candidate" line MUST be added, as specified in [RFC5245], phase (see Section 3.4.1), an "a=candidate" line MUST be added, as
Section 4.3., paragraph 3. If candidate gathering for the section defined in [RFC5245], Section 4.3., paragraph 3. If candidate
has completed, an "a=end-of-candidates" attribute MUST be added, gathering for the section has completed, an "a=end-of-candidates"
as described in [I-D.ietf-mmusic-trickle-ice], Section 9.3. attribute MUST be added, as described in [I-D.ietf-ice-trickle],
Section 9.3. If the m= section is bundled into another m=
section, both "a=candidate" and "a=end-of-candidates" MUST be
omitted.
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.
skipping to change at page 36, line 18 skipping to change at page 37, line 25
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:
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
skipping to change at page 37, line 15 skipping to change at page 38, line 21
o The RTCP feedback extensions MUST only include those that are o The RTCP feedback extensions MUST only include those that are
present in the remote description. present in the remote description.
o The "a=rtcp-mux" line MUST only be added if present in the remote o The "a=rtcp-mux" line MUST only be added if present in the remote
description. description.
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. 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.
skipping to change at page 39, line 7 skipping to change at page 40, line 11
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.
If the "VoiceActivityDetection" option is specified, with a value of
"false", the browser MUST NOT emit "CN" codecs. For codecs that have
their own internal silence suppression support, the appropriate fmtp
parameters for that codec MUST be specified to indicate that silence
suppression for received audio is not desired. For example, when
using the Opus codec, the "usedtx=0" parameter would be specified in
the offer.
Note that setting the "VoiceActivityDetection" parameter when
generating an offer is a request to receive audio with silence
suppression. It has no impact on whether the local endpoint does
silence suppression for the audio it sends.
The "VoiceActivityDetection" option does not have any impact on the
setting of the "vad" value in the signaling of the client to mixer
audio level header extension described in [RFC6464], Section 4.
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 39, line 31 skipping to change at page 41, line 4
Note that the remote description SDP may not have been created by a Note that the remote description SDP may not have been created by a
JSEP endpoint and may not conform to all the requirements listed in JSEP endpoint and may not conform to all the requirements listed in
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, except that the
"a=ice-options" line, with the "trickle" option as specified in
[I-D.ietf-ice-trickle], Section 4, is only included if such an option
was present in the offer.
The next step is to generate lip sync groups as defined in [RFC5888], The next step is to generate lip sync groups as defined in [RFC5888],
Section 7. For each MediaStream with more than one MediaStreamTrack, Section 7. For each MediaStream with more than one MediaStreamTrack,
a group of type "LS" MUST be added that contains the mid values for a group of type "LS" MUST be added that contains the mid values for
each MediaStreamTrack in that MediaStream. In some cases this may 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 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 group in the associated offer. Although this is not allowed by
[RFC5888], it is allowed when implementing this specification. [RFC5888], it is allowed when implementing this specification.
[[OPEN ISSUE: This is still under discussion. See: [[OPEN ISSUE: This is still under discussion. See:
https://github.com/rtcweb-wg/jsep/issues/162.]] https://github.com/rtcweb-wg/jsep/issues/162.]]
skipping to change at page 40, line 29 skipping to change at page 42, line 5
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. For the m= then be generated as specified in [RFC3264], Section 6.1. For the m=
line itself, the following rules must be followed: line itself, the following rules must be followed:
o The port value would normally be set to the port of the default o The port value would normally be set to the port of the default
ICE candidate for this m= section, but given that no candidates ICE candidate for this m= section, but given that no candidates
have yet been gathered, the "dummy" port value of 9 (Discard) MUST have yet been gathered, the "dummy" port value of 9 (Discard) MUST
be used, as indicated in [I-D.ietf-mmusic-trickle-ice], be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.
Section 5.1.
o The <proto> field MUST be set to exactly match the <proto> field o The <proto> field MUST be set to exactly match the <proto> field
for the corresponding m= line in the offer. for the corresponding m= line in the offer.
The m= line MUST be followed immediately by a "c=" line, as specified 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 in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP4 gathered, the "c=" line must contain the "dummy" value "IN IP4
0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.
If the offer supports BUNDLE, all m= sections to be BUNDLEd must use If the offer supports bundle, all m= sections to be bundled must use
the same ICE credentials and candidates; all m= sections not being the same ICE credentials and candidates; all m= sections not being
BUNDLEd must use unique ICE credentials and candidates. Each m= bundled must use unique ICE credentials and candidates. Each m=
section MUST include the following: section MUST include the following:
o If present in the offer, an "a=mid" line, as specified in o If and only if present in the offer, an "a=mid" line, as specified
[RFC5888], Section 9.1. The "mid" value MUST match that specified in [RFC5888], Section 9.1. The "mid" value MUST match that
in the offer. specified in the offer.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP4 0.0.0.0", because no containing the dummy value "9 IN IP4 0.0.0.0", because no
candidates have yet been gathered. 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 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
skipping to change at page 41, line 25 skipping to change at page 42, line 48
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. The audio and video codecs that MUST be [RFC3264], Section 6.1. The audio and video codecs that MUST be
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).
simplicity, the answerer MAY use different payload types for
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, and there are known o If this m= section is for video media, and there are known
limitations on the size of images which can be decoded, an limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in Section 3.5. "a=imageattr" line, as specified in Section 3.5.
skipping to change at page 41, line 50 skipping to change at page 43, line 23
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
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 If the "trickle" ICE option is present in the offer, an "a=ice-
options" line, with the "trickle" option, as specified in
[I-D.ietf-mmusic-trickle-ice], Section 4.
o An "a=fingerprint" line for each of the endpoint's certificates, o An "a=fingerprint" line for each of the endpoint's certificates,
as specified in [RFC4572], Section 5; the digest algorithm used as specified in [RFC4572], Section 5; the digest algorithm used
for the fingerprint MUST match that used in the certificate for the fingerprint MUST match that used in the certificate
signature. 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.
skipping to change at page 43, line 17 skipping to change at page 44, line 36
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"
and including the primary and FEC SSRCs, as specified in and including the primary and FEC SSRCs, as specified in
[RFC5956], section 4.3. For simplicity, if both RTX and FEC are [RFC5956], section 4.3. For simplicity, if both RTX and FEC are
supported, the FEC SSRC MUST be the same as the RTX SSRC. supported, the FEC SSRC MUST be the same as the RTX SSRC.
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> and "fmt" fields MUST be set to exactly "application" and the <proto> and "fmt" fields MUST be set to exactly
match the fields in the offer. match the fields in the offer.
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-pwd",
passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included
"a=setup" lines MUST be included as mentioned above, along with an as mentioned above, along with an "a=fmtp:webrtc-datachannel" line
"a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line and an "a=sctp-port" line referencing the SCTP port number as defined
referencing the SCTP port number as defined in in [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
[I-D.ietf-mmusic-sctp-sdp], Section 4.1.
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
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
skipping to change at page 44, line 24 skipping to change at page 45, line 43
need not match the default candidate, because this protocol value need not match the default candidate, because this protocol value
must instead match what was supplied in the offer, as described must instead match what was supplied in the offer, as described
above. Each "a=rtcp" attribute line MUST also be filled in with above. Each "a=rtcp" attribute line MUST also be filled in with
the port and address of the appropriate default candidate, either the port and address of the appropriate default candidate, either
the default RTP or RTCP candidate, depending on whether RTCP the default RTP or RTCP candidate, depending on whether RTCP
multiplexing is enabled in the answer. In each case, if no multiplexing is enabled in the answer. In each case, if no
candidates of the desired type have yet been gathered, dummy candidates of the desired type have yet been gathered, dummy
values MUST be used, as described in the initial answer section values MUST be used, as described in the initial answer section
above. above.
o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the m= section is restarting, in which case new ICE credentials
must be created as specified in [RFC5245], Section 9.2.1.1. If
the m= section is bundled into another m= section, it still MUST
NOT contain any ICE credentials.
o Within each m= section, for each candidate that has been gathered o If the m= section is not bundled into another m= section, for each
during the most recent gathering phase (see Section 3.4.1), an candidate that has been gathered during the most recent gathering
"a=candidate" line MUST be added, as specified in [RFC5245], phase (see Section 3.4.1), an "a=candidate" line MUST be added, as
Section 4.3., paragraph 3. If candidate gathering for the section defined in [RFC5245], Section 4.3., paragraph 3. If candidate
has completed, an "a=end-of-candidates" attribute MUST be added, gathering for the section has completed, an "a=end-of-candidates"
as described in [I-D.ietf-mmusic-trickle-ice], Section 9.3. attribute MUST be added, as described in [I-D.ietf-ice-trickle],
Section 9.3. If the m= section is bundled into another m=
section, both "a=candidate" and "a=end-of-candidates" MUST be
omitted.
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.
5.3.3. Options Handling 5.3.3. Options Handling
The createAnswer method takes as a parameter an RTCAnswerOptions The createAnswer method takes as a parameter an RTCAnswerOptions
object. The set of parameters for RTCAnswerOptions is different than object. The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions; the OfferToReceiveAudio, those supported in RTCOfferOptions; the OfferToReceiveAudio,
OfferToReceiveVideo, and IceRestart options mentioned in OfferToReceiveVideo, and IceRestart options mentioned in
Section 5.2.3 are meaningless in the context of generating an answer, Section 5.2.3 are meaningless in the context of generating an answer,
as there is no need to generate extra m= lines in an answer, and ICE as there is no need to generate extra m= lines in an answer, and ICE
credentials will automatically be changed for all m= lines where the credentials will automatically be changed for all m= lines where the
offerer chose to perform ICE restart. offerer chose to perform ICE restart.
The following options are supported in RTCAnswerOptions. The following options are supported in RTCAnswerOptions.
5.3.3.1. VoiceActivityDetection 5.3.3.1. VoiceActivityDetection
Silence suppression in the answer is handled as described in Silence suppression in the answer is handled as described in
Section 5.2.3.4. Section 5.2.3.4, with one exception: if support for silence
suppression was not indicated in the offer, the
VoiceActivityDetection parameter has no effect, and the answer should
be generated as if VoiceActivityDetection was set to false. This is
done on a per-codec basis (e.g., if the offerer somehow offered
support for CN but set "usedtx=0" for Opus, setting
VoiceActivityDetection to true would result in an answer with CN
codecs and "usedtx=0").
5.4. Processing a Local Description 5.4. Processing a Local Description
When a SessionDescription is supplied to setLocalDescription, the When a SessionDescription is supplied to setLocalDescription, the
following steps MUST be performed: following steps MUST be performed:
o First, the type of the SessionDescription is checked against the o First, the type of the SessionDescription is checked against the
current state of the PeerConnection: current state of the PeerConnection:
* If the type is "offer", the PeerConnection state MUST be either * If the type is "offer", the PeerConnection state MUST be either
skipping to change at page 46, line 14 skipping to change at page 47, line 41
o Next, the SessionDescription is parsed into a data structure, as o Next, the SessionDescription is parsed into a data structure, as
described in the Section 5.6 section below. If parsing fails for described in the Section 5.6 section below. If parsing fails for
any reason, processing MUST stop and an error MUST be returned. any reason, processing MUST stop and an error MUST be returned.
o Finally, the parsed SessionDescription is applied as described in o Finally, the parsed SessionDescription is applied as described in
the Section 5.8 section below. the Section 5.8 section below.
5.6. Parsing a Session Description 5.6. Parsing a Session Description
[The behavior described herein is a draft version, and needs more
discussion to resolve various open issues.]
When a SessionDescription of any type is supplied to setLocal/ When a SessionDescription of any type is supplied to setLocal/
RemoteDescription, the implementation must parse it and reject it if RemoteDescription, the implementation must parse it and reject it if
it is invalid. The exact details of this process are explained it is invalid. The exact details of this process are explained
below. below.
The SDP contained in the session description object consists of a The SDP contained in the session description object consists of a
sequence of text lines, each containing a key-value expression, as sequence of text lines, each containing a key-value expression, as
described in [RFC4566], Section 5. The SDP is read, line-by-line, described in [RFC4566], Section 5. The SDP is read, line-by-line,
and converted to a data structure that contains the deserialized and converted to a data structure that contains the deserialized
information. However, SDP allows many types of lines, not all of information. However, SDP allows many types of lines, not all of
which are relevant to JSEP applications. For each line, the which are relevant to JSEP applications. For each line, the
implementation will first ensure it is syntactically correct implementation will first ensure it is syntactically correct
according its defining ABNF [TODO: reference], check that it conforms according its defining ABNF, check that it conforms to [RFC4566] and
to [RFC4566] and [RFC3264] semantics, and then either parse and store [RFC3264] semantics, and then either parse and store or discard the
or discard the provided value, as described below. [TODO: ensure provided value, as described below. A partial list of ABNF
that every line is listed below.] If the line is not well-formed, or definitions for SDP attributes can found in:
cannot be parsed as described, the parser MUST stop with an error and
reject the session description. This ensures that implementations do +---------------------------+------------------------------------+
not accidentally misinterpret ambiguous SDP. | Attribute | Reference |
+---------------------------+------------------------------------+
| ptime | [RFC4566] Section 9 |
| maxptime | [RFC4566] Section 9 |
| rtpmap | [RFC4566] Section 9 |
| recvonly | [RFC4566] Section 9 |
| sendrecv | [RFC4566] Section 9 |
| sendonly | [RFC4566] Section 9 |
| inactive | [RFC4566] Section 9 |
| framerate | [RFC4566] Section 9 |
| fmtp | [RFC4566] Section 9 |
| quality | [RFC4566] Section 9 |
| msid | [I-D.ietf-mmusic-msid] Section 2 |
| rtcp | [RFC3605] Section 2.1 |
| setup | [RFC4145] Section 3, 4, and 5 |
| connection | [RFC4145] Section 3, 4, and 5 |
| fingerprint | [RFC4572] Section 5 |
| rtcp-fb | [RFC4585] Section 4.2 |
| candidate | [RFC5245] Section 15 |
| extmap | [RFC5285] Section 7 |
| mid | [RFC5888] Section 4 and 5 |
| group | [RFC5888] Section 4 and 5 |
| imageattr | [RFC6236] Section 3.1 |
| extmap (encrypt option) | [RFC6904] Section 4 |
+---------------------------+------------------------------------+
Table 1: SDP ABNF References
[TODO: ensure that every line is listed below.]
If the line is not well-formed, or cannot be parsed as described, the
parser MUST stop with an error and reject the session description.
This ensures that implementations do not accidentally misinterpret
ambiguous SDP.
5.6.1. Session-Level Parsing 5.6.1. Session-Level Parsing
First, the session-level lines are checked and parsed. These lines First, the session-level lines are checked and parsed. These lines
MUST occur in a specific order, and with a specific syntax, as MUST occur in a specific order, and with a specific syntax, as
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.
skipping to change at page 47, line 8 skipping to change at page 49, line 18
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 The "c=" line MUST be checked for syntax but its value is not
used. This supersedes the guidance in [RFC5245], Section 6.1, to used. This supersedes the guidance in [RFC5245], Section 6.1, to
use "ice-mismatch" to indicate mismatches between "c=" and the use "ice-mismatch" to indicate mismatches between "c=" and the
candidate lines; because JSEP always uses ICE, "ice-mismatch" is candidate lines; because JSEP always uses ICE, "ice-mismatch" is
not useful in this context. not useful in this context.
TODO The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are
not used by this specification; they MUST be checked for syntax
but their values are not used.
The remaining lines are processed as follows: The remaining lines are processed as follows:
The "v=" line MUST have a version of 0, as specified in [RFC4566],
Section 5.1.
The "o=" line MUST be parsed as specified in [RFC4566],
Section 5.2.
The "b=" line, if present, MUST be parsed as specified in 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.
[OPEN ISSUE: is this WG consensus? Are there other non-a= lines
that we need to do more than just syntactical validation, e.g.
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.
o If present, a single "a=ice-lite" line is parsed as specified in 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 [RFC5245], Section 15.3, and a value indicating the presence of
ice-lite is stored. ice-lite is stored.
skipping to change at page 47, line 50 skipping to change at page 50, line 19
o Any "a=fingerprint" lines are parsed as specified in [RFC4572], o Any "a=fingerprint" lines are parsed as specified in [RFC4572],
Section 5, and the set of fingerprint and algorithm values is Section 5, and the set of fingerprint and algorithm values is
stored. stored.
o If present, a single "a=setup" line is parsed as specified in o If present, a single "a=setup" line is parsed as specified in
[RFC4145], Section 4, and the setup value is stored. [RFC4145], Section 4, and the setup value is stored.
o Any "a=extmap" lines are parsed as specified in [RFC5285], o Any "a=extmap" lines are parsed as specified in [RFC5285],
Section 5, and their values are stored. Section 5, and their values are stored.
o TODO: msid-semantic, identity, rtcp-rsize, rtcp-mux, and any other o TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid
attribs valid at session level. at session level.
Once all the session-level lines have been parsed, processing Once all the session-level lines have been parsed, processing
continues with the lines in media sections. continues with the lines in media sections.
5.6.2. Media Section Parsing 5.6.2. Media Section Parsing
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.
skipping to change at page 49, line 14 skipping to change at page 51, line 29
o The "m=" fmt value MUST be parsed as specified in [RFC4566], o The "m=" fmt value MUST be parsed as specified in [RFC4566],
Section 5.14, and the individual values stored. Section 5.14, and the individual values stored.
o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in
[RFC4566], Section 6, and their values stored. [RFC4566], Section 6, and their values stored.
o If present, a single "a=ptime" line MUST be parsed as described in o If present, a single "a=ptime" line MUST be parsed as described in
[RFC4566], Section 6, and its value stored. [RFC4566], Section 6, and its value stored.
o If present, a single "a=maxptime" line MUST be parsed as described
in [RFC4566], Section 6, and its value stored.
o If present, a single direction attribute line (e.g. "a=sendrecv") o If present, a single direction attribute line (e.g. "a=sendrecv")
MUST be parsed as described in [RFC4566], Section 6, and its value MUST be parsed as described in [RFC4566], Section 6, and its value
stored. stored.
o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as
specified in [RFC5576], Sections 4.1-4.2, and their values stored. specified in [RFC5576], Sections 4.1-4.2, and their values stored.
o Any "a=extmap" attributes MUST be parsed as specified in o Any "a=extmap" attributes MUST be parsed as specified in
[RFC5285], Section 5, and their values stored. [RFC5285], Section 5, and their values stored.
o Any "a=rtcp-fb" attributes MUST be parsed as specified in o Any "a=rtcp-fb" attributes MUST be parsed as specified in
[RFC4585], Section 4.2., and their values stored. [RFC4585], Section 4.2., and their values stored.
o If present, a single "a=rtcp-mux" line MUST be parsed as specified o If present, a single "a=rtcp-mux" attribute MUST be parsed as
in [RFC5761], Section 5.1.1, and its presence or absence flagged specified in [RFC5761], Section 5.1.1, and its presence or absence
and stored. flagged and stored.
o TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of- o If present, a single "a=rtcp-rsize" attribute MUST be parsed as
candidates specified in [RFC5506], Section 5, and its presence or absence
flagged and stored.
Otherwise, if the "m=" proto value indicats use of SCTP, the o If present, a single "a=rtcp" attribute MUST be parsed as
specified in [RFC3605], Section 2.1, but its value is ignored.
o If present, a single "a=msid" attribute MUST be parsed as
specified in [I-D.ietf-mmusic-msid], Section 3.2, and its value
stored.
o Any "a=candidate" attributes MUST be parsed as specified in
[RFC5245], Section 4.3, and their values stored.
o Any "a=remote-candidates" attributes MUST be parsed as specified
in [RFC5245], Section 4.3, but their values are ignored.
o If present, a single "a=end-of-candidates" attribute MUST be
parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
its presence or absence flagged and stored.
o Any "a=imageattr" attributes MUST be parsed as specified in
[RFC6236], Section 3, and their values stored.
Otherwise, if the "m=" proto value indicates use of SCTP, the
following attribute lines MUST be processed: following attribute lines MUST be processed:
o The "m=" fmt value MUST be parsed as specified in o The "m=" fmt value MUST be parsed as specified in
[I-D.ietf-mmusic-sctp-sdp], Section 4.3, and the application [I-D.ietf-mmusic-sctp-sdp], Section 4.3, and the application
protocol value stored. protocol value stored.
o An "a=sctp-port" attribute MUST be present, and it MUST be parsed o An "a=sctp-port" attribute MUST be present, and it MUST be parsed
as specified in [I-D.ietf-mmusic-sctp-sdp], Section 5.2, and the as specified in [I-D.ietf-mmusic-sctp-sdp], Section 5.2, and the
value stored. value stored.
o TODO: max message size o If present, a single "a=max-message-size" attribute MUST be parsed
as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the
value stored. Otherwise, use the specified default.
5.6.3. Semantics Verification 5.6.3. Semantics Verification
Assuming parsing completes successfully, the parsed description is Assuming parsing completes successfully, the parsed description is
then evaluated to ensure internal consistency as well as proper then evaluated to ensure internal consistency as well as proper
support for mandatory features. Specifically, the following checks support for mandatory features. Specifically, the following checks
are performed: are performed:
o For each m= section, valid values for each of the mandatory-to-use o For each m= section, valid values for each of the mandatory-to-use
features enumerated in Section 5.1.2 MUST be present. These features enumerated in Section 5.1.2 MUST be present. These
skipping to change at page 51, line 22 skipping to change at page 54, line 15
Section 9.1.1.1, unless it has been marked as bundle-only. Section 9.1.1.1, unless it has been marked as bundle-only.
o If the media section proto value indicates use of RTP: o If the media section proto value indicates use of RTP:
* If RTCP mux is indicated, prepare to demux RTP and RTCP from * If RTCP mux is indicated, prepare to demux RTP and RTCP from
the RTP ICE component, as specified in [RFC5761], the RTP ICE component, as specified in [RFC5761],
Section 5.1.1. If RTCP mux is not indicated, but was indicated Section 5.1.1. If RTCP mux is not indicated, but was indicated
in a previous description, this MUST result in an error. in a previous description, this MUST result in an error.
* For each specified RTP header extension, establish a mapping * For each specified RTP header extension, establish a mapping
between the extension ID and URI. If any indicated RTP header between the extension ID and URI, as described in section 6 of
extension is unknown, this MUST result in an error. [TODO: [RFC5285]. If any indicated RTP header extension is unknown,
ref] this MUST result in an error.
* If the MID header extension is supported, prepare to demux RTP * If the MID header extension is supported, prepare to demux RTP
data intended for this media section based on the MID header data intended for this media section based on the MID header
extension. [TODO: ref] extension, as described in [I-D.ietf-mmusic-msid], Section 3.2.
* For each specified payload type, establish a mapping between * For each specified payload type, establish a mapping between
the payload type ID and the actual media format. [TODO: ref] the payload type ID and the actual media format, as descibed in
If any indicated payload type is unknown, this MUST result in [RFC3264]. If any indicated payload type is unknown, this MUST
an error. result in an error.
* For each specified "rtx" media format, establish a mapping * For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload between the RTX payload type and its associated primary payload
type. [TODO: ref] If any referenced primary payload types are type, as described in [RFC4588], Sections 8.6 and 8.7. If any
not present, this MUST result in an error. referenced primary payload types are not present, this MUST
result in an error.
* If the directional attribute is of type "sendrecv" or * If the directional attribute is of type "sendrecv" or
"recvonly", enable receipt and decoding of media. "recvonly", enable receipt and decoding of media.
Finally, if this description is of type "pranswer" or "answer", Finally, if this description is of type "pranswer" or "answer",
follow the processing defined in the Section 5.9 section below. follow the processing defined in the Section 5.9 section below.
5.8. Applying a Remote Description 5.8. Applying a Remote Description
If the answer contains any "a=ice-options" attributes where "trickle"
is listed as an attribute, update the PeerConnection canTrickle
property to be true. Otherwise, set this property to false.
The following steps are performed at the media engine level to apply The following steps are performed at the media engine level to apply
a remote description. a remote description.
The following steps MUST be performed for attributes at the session
level; if any parameters are out of bounds, or cannot be applied,
processing MUST stop and an error MUST be returned.
o For any specified "CT" bandwidth value, set this as the limit for
the maximum total bitrate for all m= sections, as specified in
Section 5.8 of [RFC4566]. The implementation can decide how to
allocate the available bandwidth between m= sections to
simultaneously meet any limits on individual m= sections, as well
as this overall session limit.
o For any specified "RR" or "RS" bandwidth values, handle as
specified in [RFC3556], Section 2.
o Any "AS" bandwidth value MUST be ignored, as the meaning of this
construct at the session level is not well defined.
For each media section, the following steps MUST be performed; if any For each media section, the following steps MUST be performed; if any
parameters are out of bounds, or cannot be applied, processing MUST parameters are out of bounds, or cannot be applied, processing MUST
stop and an error MUST be returned. stop and an error MUST be returned.
o If the description is of type "offer", and the ICE ufrag or o If the description is of type "offer", and the ICE ufrag or
password changed from the previous remote description, [TODO: password changed from the previous remote description, as
ref], mark that an ICE restart is needed. described in Section 9.1.1.1 of [RFC5245], mark that an ICE
restart is needed.
o Configure the ICE components associated with this media section to o Configure the ICE components associated with this media section to
use the supplied ICE remote ufrag and password for their use the supplied ICE remote ufrag and password for their
connectivity checks. connectivity checks.
o Pair any supplied ICE candidates with any gathered local o Pair any supplied ICE candidates with any gathered local
candidates, as described in [TODO: ref] and start connectivity candidates, as described in Section 5.7 of [RFC5245] and start
checks with the appropriate credentials. connectivity checks with the appropriate credentials.
o If the media section proto value indicates use of RTP: o If the media section proto value indicates use of RTP:
* [TODO: header extensions] * [TODO: header extensions]
* For each specified payload type that is also supported by the * For each specified payload type that is also supported by the
local implementation, establish a mapping between the payload local implementation, establish a mapping between the payload
type ID and the actual media format. [TODO: ref] If any type ID and the actual media format. [TODO - Justin to add
indicated payload type is unknown, it MUST be ignored. [TODO: more to explain mapping.] If any indicated payload type is
should fail on answers] unknown, it MUST be ignored. [TODO: should fail on answers]
* For each specified "rtx" media format, establish a mapping * For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload between the RTX payload type and its associated primary payload
type. [TODO: ref] If any referenced primary payload types are type, as described in [RFC4588]. If any referenced primary
not present, this MUST result in an error. payload types are not present, this MUST result in an error.
* For each specified fmtp parameter that is supported by the * For each specified fmtp parameter that is supported by the
local implementation, enable them on the associated payload local implementation, enable them on the associated payload
types. types.
* For each specified RTCP feedback mechanism that is supported by * For each specified RTCP feedback mechanism that is supported by
the local implementation, enable them on the associated payload the local implementation, enable them on the associated payload
types. types.
* For any specified "TIAS" bandwidth value, set this value as the * For any specified "TIAS" bandwidth value, set this value as a
maximum RTP bitrate to be used when sending media. If a "TIAS" constraint on the maximum RTP bitrate to be used when sending
value is not present, but an "AS" value is, generate a TIAS a media, as specified in [RFC3890]. If a "TIAS" value is not
value using this formula: [TODO: convert AS to TIAS]. present, but an "AS" value is specified, generate a "TIAS"
value using this formula:
TIAS = AS * 0.95 - 50 * 40 * 8
The 50 is based on 50 packets per second, the 40 is based on an
estimate of total header size, and the 0.95 is to allocate 5%
to RTCP. If more accurate control of bandwidth is needed,
"TIAS" should be used instead of "AS".
* For any "RR" or "RS" bandwidth values, handle as specified in
[RFC3556], Section 2.
* Any specified "CT" bandwidth value MUST be ignored, as the
meaning of this construct at the media level is not well
defined.
* [TODO: handling of CN, telephone-event, "red"] * [TODO: handling of CN, telephone-event, "red"]
* If the media section if of type audio: * If the media section if of type audio:
+ For any specified "ptime" value, configure the available + For any specified "ptime" value, configure the available
payload types to use the specified packet size. If the payload types to use the specified packet size. If the
specified size is not supported for a payload type, use the specified size is not supported for a payload type, use the
next closest value instead. next closest value instead.
skipping to change at page 53, line 23 skipping to change at page 56, line 51
5.9. Applying an Answer 5.9. Applying an Answer
In addition to the steps mentioned above for processing a local or In addition to the steps mentioned above for processing a local or
remote description, the following steps are performed when processing remote description, the following steps are performed when processing
a description of type "pranswer" or "answer". a description of type "pranswer" or "answer".
For each media section, the following steps MUST be performed: For each media section, the following steps MUST be performed:
o If the media section has been rejected (i.e. port is set to zero o If the media section has been rejected (i.e. port is set to zero
in the answer), stop any reception or transmission of media for in the answer), stop any reception or transmission of media for
this section, and discard any associated ICE components. [TODO: this section, and discard any associated ICE components, as
ref] described in Section 9.2.1.3 of [RFC5245].
o If the remote DTLS fingerprint has been changed, tear down the o If the remote DTLS fingerprint has been changed, tear down the
existing DTLS connection. existing DTLS connection.
o If no valid DTLS connection exists, prepare to start a DTLS o If no valid DTLS connection exists, prepare to start a DTLS
connection, using the specified roles and fingerprints, on any connection, using the specified roles and fingerprints, on any
underlying ICE components, once they are active. underlying ICE components, once they are active.
o If the media section proto value indicates use of RTP: o If the media section proto value indicates use of RTP:
* If the media section has RTCP mux enabled, discard any RTCP * If the media section has RTCP mux enabled, discard any RTCP
component, and begin or continue muxing RTCP over the RTP component, and begin or continue muxing RTCP over the RTP
component, as specified in [RFC5761], Section 5.1.3. component, as specified in [RFC5761], Section 5.1.3.
Otherwise, transmit RTCP over the RTCP component; if no RTCP Otherwise, transmit RTCP over the RTCP component; if no RTCP
component exists, because RTCP mux was previously enabled, this component exists, because RTCP mux was previously enabled, this
MUST result in an error. MUST result in an error.
* If the media section has reduced-size RTCP enabled, configure * If the media section has reduced-size RTCP enabled, configure
the RTCP transmission for this media section to use reduced- the RTCP transmission for this media section to use reduced-
size RTCP, as specified in [TODO: ref] size RTCP, as specified in [RFC5506].
* If the directional attribute in the answer is of type * If the directional attribute in the answer is of type
"sendrecv" or "sendonly", prepare to start transmitting media "sendrecv" or "sendonly", prepare to start transmitting media
using the specified primary SSRC and one of the selected using the specified primary SSRC and one of the selected
payload types, once the underlying transport layers have been payload types, once the underlying transport layers have been
established. Otherwise, stop transmitting RTP media, although established. Otherwise, stop transmitting RTP media, although
RTCP should still be sent. [TODO: ref] RTCP should still be sent, as described in [RFC3264],
Section 5.1.
o If the media section proto value indicates use of SCTP: o If the media section proto value indicates use of SCTP:
* If no SCTP association yet exists, prepare to initiate a SCTP * If no SCTP association yet exists, prepare to initiate a SCTP
association over the associated ICE component and DTLS association over the associated ICE component and DTLS
connection, using the local SCTP port value from the local connection, using the local SCTP port value from the local
description, and the remote SCTP port value from the remote description, and the remote SCTP port value from the remote
description. [TODO: ref] description, as described in [I-D.ietf-mmusic-sctp-sdp],
Section 10.2.
If the answer contains valid BUNDLE groups, discard any ICE If the answer contains valid bundle groups, discard any ICE
components for the m= sections that will be bundled onto the primary components for the m= sections that will be bundled onto the primary
ICE components in each BUNDLE, and begin muxing these m= sections ICE components in each bundle, and begin muxing these m= sections
accordingly. [TODO: ref] accordingly, as described in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2.
If the answer contains any "a=ice-options" attributes where "trickle"
is listed as an attribute, update the PeerConnection canTrickle
property to be true. Otherwise, set this property to false.
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.
skipping to change at page 54, line 48 skipping to change at page 58, line 25
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).
o The contents of BUNDLE groups, bundle-only parameters, or "a=rtcp- o The contents of bundle groups, bundle-only parameters, or "a=rtcp-
mux" parameters. mux" parameters.
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 options passed into The following parameters may be controlled by options passed into
createOffer/createAnswer. As an open issue, these changes may also createOffer/createAnswer. As an open issue, these changes may also
skipping to change at page 57, line 14 skipping to change at page 60, line 14
// set up local media state // set up local media state
AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: create new PeerConnection
AliceJS->AliceUA: addStream with stream containing audio and video AliceJS->AliceUA: addStream with stream containing audio and video
AliceJS->AliceUA: createOffer to get offer AliceJS->AliceUA: createOffer to get offer
AliceJS->AliceUA: setLocalDescription with offer AliceJS->AliceUA: setLocalDescription with offer
AliceUA->AliceJS: multiple onicecandidate events with candidates AliceUA->AliceJS: multiple onicecandidate events with candidates
// wait for ICE gathering to complete // wait for ICE gathering to complete
AliceUA->AliceJS: onicecandidate event with null candidate AliceUA->AliceJS: onicecandidate event with null candidate
AliceJS->AliceUA: get |offer-A1| from value of localDescription AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription
// |offer-A1| is sent over signaling protocol to Bob // |offer-A1| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |offer-A1| AliceJS->WebServer: signaling with |offer-A1|
WebServer->BobJS: signaling with |offer-A1| WebServer->BobJS: signaling with |offer-A1|
// |offer-A1| arrives at Bob // |offer-A1| arrives at Bob
BobJS->BobUA: create a PeerConnection BobJS->BobUA: create a PeerConnection
BobJS->BobUA: setRemoteDescription with |offer-A1| BobJS->BobUA: setRemoteDescription with |offer-A1|
BobUA->BobJS: onaddstream event with remoteStream BobUA->BobJS: onaddstream event with remoteStream
// Bob accepts call // Bob accepts call
BobJS->BobUA: addStream with local media BobJS->BobUA: addStream with local media
BobJS->BobUA: createAnswer BobJS->BobUA: createAnswer
BobJS->BobUA: setLocalDescription with answer BobJS->BobUA: setLocalDescription with answer
BobUA->BobJS: multiple onicecandidate events with candidates BobUA->BobJS: multiple onicecandidate events with candidates
// wait for ICE gathering to complete // wait for ICE gathering to complete
BobUA->BobJS: onicecandidate event with null candidate BobUA->BobJS: onicecandidate event with null candidate
BobJS->BobUA: get |answer-A1| from value of localDescription BobJS->BobUA: get |answer-A1| from currentLocalDescription
// |answer-A1| is sent over signaling protocol to Alice // |answer-A1| is sent over signaling protocol to Alice
BobJS->WebServer: signaling with |answer-A1| BobJS->WebServer: signaling with |answer-A1|
WebServer->AliceJS: signaling with |answer-A1| WebServer->AliceJS: signaling with |answer-A1|
// |answer-A1| arrives at Alice // |answer-A1| arrives at Alice
AliceJS->AliceUA: setRemoteDescription with |answer-A1| AliceJS->AliceUA: setRemoteDescription with |answer-A1|
AliceUA->AliceJS: onaddstream event with remoteStream AliceUA->AliceJS: onaddstream event with remoteStream
// media flows // media flows
BobUA->AliceUA: media sent from Bob to Alice BobUA->AliceUA: media sent from Bob to Alice
AliceUA->BobUA: media sent from Alice to Bob AliceUA->BobUA: media sent from Alice to Bob
The SDP for |offer-A1| looks like: The SDP for |offer-A1| looks like:
v=0 v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0 o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=ice-options:trickle
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=mid:a1 a=mid:a1
a=rtcp:56501 IN IP4 192.0.2.1 a=rtcp:56501 IN IP4 192.0.2.1
a=msid:47017fee-b6c1-4162-929c-a25110252400 a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
a=ice-ufrag:ETEn1v9DoTMB9J4r a=ice-ufrag:ETEn1v9DoTMB9J4r
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7 a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
skipping to change at page 58, line 49 skipping to change at page 61, line 48
a=rtcp:56503 IN IP4 192.0.2.1 a=rtcp:56503 IN IP4 192.0.2.1
a=mid:v1 a=mid:v1
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=ice-ufrag:BGKkWnG5GmiUpdIV a=ice-ufrag:BGKkWnG5GmiUpdIV
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7 a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7 a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
skipping to change at page 59, line 28 skipping to change at page 62, line 25
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
typ host typ host
a=end-of-candidates a=end-of-candidates
The SDP for |answer-A1| looks like: The SDP for |answer-A1| looks like:
v=0 v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0 o=- 6729291447651054566 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS a=group:BUNDLE a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 20000 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=mid:a1 a=mid:a1
a=rtcp:20000 IN IP4 192.0.2.2 a=rtcp:20000 IN IP4 192.0.2.2
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
skipping to change at page 60, line 4 skipping to change at page 62, line 50
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host typ host
a=end-of-candidates a=end-of-candidates
m=video 20000 UDP/TLS/RTP/SAVPF 100 101
m=video 20001 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=rtcp 20001 IN IP4 192.0.2.2 a=rtcp 20001 IN IP4 192.0.2.2
a=mid:v1 a=mid:v1
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 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 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 3229706345 3229706346 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 7.2. Normal Examples
This section shows a typical example of a session between two This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel. Trickle ICE browsers setting up an audio channel and a data channel. Trickle ICE
is used in full trickle mode with a bundle policy of max-bundle, an is used in full trickle mode with a bundle policy of max-bundle, an
RTCP mux policy of require, and a single TURN server. Later, two RTCP mux policy of require, and a single TURN server. Later, two
video flows, one for the presenter and one for screen sharing, are video flows, one for the presenter and one for screen sharing, are
added to the session. This example shows Alice's browser initiating 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 the session to Bob's browser. The messages from Alice's JS to Bob's
skipping to change at page 61, line 11 skipping to change at page 64, line 4
AliceJS->AliceUA: setLocalDescription with |offer-B1| AliceJS->AliceUA: setLocalDescription with |offer-B1|
// |offer-B1| is sent over signaling protocol to Bob // |offer-B1| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |offer-B1| AliceJS->WebServer: signaling with |offer-B1|
WebServer->BobJS: signaling with |offer-B1| WebServer->BobJS: signaling with |offer-B1|
// |offer-B1| arrives at Bob // |offer-B1| arrives at Bob
BobJS->BobUA: create a PeerConnection BobJS->BobUA: create a PeerConnection
BobJS->BobUA: setRemoteDescription with |offer-B1| BobJS->BobUA: setRemoteDescription with |offer-B1|
BobUA->BobJS: onaddstream with audio track from Alice BobUA->BobJS: onaddstream with audio track from Alice
// candidates are sent to Bob // candidates are sent to Bob
AliceUA->AliceJS: onicecandidate event with |candidate-B1| (host) AliceUA->AliceJS: onicecandidate event with |candidate-B1| (host)
AliceJS->WebServer: signaling with |candidate-B1| AliceJS->WebServer: signaling with |candidate-B1|
AliceUA->AliceJS: onicecandidate event with |candidate-B2| (srflx) AliceUA->AliceJS: onicecandidate event with |candidate-B2| (srflx)
AliceJS->WebServer: signaling with |candidate-B2| AliceJS->WebServer: signaling with |candidate-B2|
AliceUA->AliceJS: onicecandidate event with |candidate-B3| (relay)
AliceJS->WebServer: signaling with |candidate-B3|
WebServer->BobJS: signaling with |candidate-B1| WebServer->BobJS: signaling with |candidate-B1|
BobJS->BobUA: addIceCandidate with |candidate-B1| BobJS->BobUA: addIceCandidate with |candidate-B1|
WebServer->BobJS: signaling with |candidate-B2| WebServer->BobJS: signaling with |candidate-B2|
BobJS->BobUA: addIceCandidate with |candidate-B2| BobJS->BobUA: addIceCandidate with |candidate-B2|
WebServer->BobJS: signaling with |candidate-B3|
BobJS->BobUA: addIceCandidate with |candidate-B3|
// Bob accepts call // Bob accepts call
BobJS->BobUA: addStream with local audio stream BobJS->BobUA: addStream with local audio stream
BobJS->BobUA: createDataChannel to get data channel BobJS->BobUA: createDataChannel to get data channel
BobJS->BobUA: createAnswer to get |answer-B1| BobJS->BobUA: createAnswer to get |answer-B1|
BobJS->BobUA: setLocalDescription with |answer-B1| BobJS->BobUA: setLocalDescription with |answer-B1|
// |answer-B1| is sent to Alice // |answer-B1| is sent to Alice
BobJS->WebServer: signaling with |answer-B1| BobJS->WebServer: signaling with |answer-B1|
WebServer->AliceJS: signaling with |answer-B1| WebServer->AliceJS: signaling with |answer-B1|
AliceJS->AliceUA: setRemoteDescription with |answer-B1| AliceJS->AliceUA: setRemoteDescription with |answer-B1|
AliceUA->AliceJS: onaddstream event with audio track from Bob AliceUA->AliceJS: onaddstream event with audio track from Bob
// candidates are sent to Alice // candidates are sent to Alice
BobUA->BobJS: onicecandidate event with |candidate-B4| (host) BobUA->BobJS: onicecandidate event with |candidate-B3| (host)
BobJS->WebServer: signaling with |candidate-B3|
BobUA->BobJS: onicecandidate event with |candidate-B4| (srflx)
BobJS->WebServer: signaling with |candidate-B4| BobJS->WebServer: signaling with |candidate-B4|
BobUA->BobJS: onicecandidate event with |candidate-B5| (srflx)
BobJS->WebServer: signaling with |candidate-B5|
BobUA->BobJS: onicecandidate event with |candidate-B6| (relay)
BobJS->WebServer: signaling with |candidate-B6|
WebServer->AliceJS: signaling with |candidate-B3|
AliceJS->AliceUA: addIceCandidate with |candidate-B3|
WebServer->AliceJS: signaling with |candidate-B4| WebServer->AliceJS: signaling with |candidate-B4|
AliceJS->AliceUA: addIceCandidate 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 // data channel opens
BobUA->BobJS: ondatachannel event BobUA->BobJS: ondatachannel event
AliceUA->AliceJS: ondatachannel event AliceUA->AliceJS: ondatachannel event
BobUA->BobJS: onopen BobUA->BobJS: onopen
AliceUA->AliceJS: onopen AliceUA->AliceJS: onopen
// media is flowing between browsers // media is flowing between browsers
BobUA->AliceUA: audio+data sent from Bob to Alice BobUA->AliceUA: audio+data sent from Bob to Alice
AliceUA->BobUA: audio+data sent from Alice to Bob AliceUA->BobUA: audio+data sent from Alice to Bob
// some time later Bob adds two video streams // some time later Bob adds two video streams
// note, no candidates exchanged, because of BUNDLE // note, no candidates exchanged, because of bundle
BobJS->BobUA: addStream with first video stream BobJS->BobUA: addStream with first video stream
BobJS->BobUA: addStream with second video stream BobJS->BobUA: addStream with second video stream
BobJS->BobUA: createOffer to get |offer-B2| BobJS->BobUA: createOffer to get |offer-B2|
BobJS->BobUA: setLocalDescription with |offer-B2| BobJS->BobUA: setLocalDescription with |offer-B2|
// |offer-B2| is sent to Alice // |offer-B2| is sent to Alice
BobJS->WebServer: signaling with |offer-B2| BobJS->WebServer: signaling with |offer-B2|
WebServer->AliceJS: signaling with |offer-B2| WebServer->AliceJS: signaling with |offer-B2|
AliceJS->AliceUA: setRemoteDescription with |offer-B2| AliceJS->AliceUA: setRemoteDescription with |offer-B2|
AliceUA->AliceJS: onaddstream event with first video stream AliceUA->AliceJS: onaddstream event with first video stream
skipping to change at page 63, line 9 skipping to change at page 66, line 9
// media is flowing between browsers // media is flowing between browsers
BobUA->AliceUA: audio+video+data sent from Bob to Alice BobUA->AliceUA: audio+video+data sent from Bob to Alice
AliceUA->BobUA: audio+video+data sent from Alice to Bob AliceUA->BobUA: audio+video+data sent from Alice to Bob
The SDP for |offer-B1| looks like: The SDP for |offer-B1| looks like:
v=0 v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0 o=- 4962303333179871723 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 a=group:BUNDLE a1 d1
a=ice-options:trickle
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0
a=mid:a1 a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400 a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
m=application 9 UDP/DTLS/SCTP webrtc-datachannel m=application 0 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=bundle-only
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 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 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
The SDP for |candidate-B1| looks like: The SDP for |candidate-B1| looks like:
candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
The SDP for |candidate-B2| looks like: The SDP for |candidate-B2| looks like:
candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556 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: The SDP for |answer-B1| looks like:
v=0 v=0
o=- 7729291447651054566 1 IN IP4 0.0.0.0 o=- 7729291447651054566 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 a=group:BUNDLE a1 d1
a=ice-options:trickle
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0
a=mid:a1 a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 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 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
m=application 9 UDP/DTLS/SCTP webrtc-datachannel m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 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 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
The SDP for |candidate-B4| looks like: The SDP for |candidate-B3| looks like:
candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
The SDP for |candidate-B4| looks like:
The SDP for |candidate-B5| looks like:
candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665 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 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 number in the o= line, and the c= and a=rtcp lines, which indicate
the local candidate that was selected) the local candidate that was selected)
v=0 v=0
o=- 7729291447651054566 2 IN IP4 0.0.0.0 o=- 7729291447651054566 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=ice-options:trickle
m=audio 64532 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 64532 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 55.66.77.88 c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88 a=rtcp:64532 IN IP4 55.66.77.88
a=mid:a1 a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 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 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 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 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
skipping to change at page 67, line 4 skipping to change at page 68, line 48
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 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 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665 raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532 raddr 55.66.77.88 rport 64532
a=end-of-candidates a=end-of-candidates
m=application 64532 UDP/DTLS/SCTP webrtc-datachannel m=application 64532 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 55.66.77.88 c=IN IP4 55.66.77.88
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 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 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:actpass a=setup:actpass
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 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 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665 raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532 raddr 55.66.77.88 rport 64532
a=end-of-candidates a=end-of-candidates
m=video 64532 UDP/TLS/RTP/SAVPF 100 101 m=video 0 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88 c=IN IP4 55.66.77.88
a=bundle-only
a=rtcp:64532 IN IP4 55.66.77.88 a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1 a=mid:v1
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 1366781083 1366781084 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 m=video 0 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88 c=IN IP4 55.66.77.88
a=bundle-only
a=rtcp:64532 IN IP4 55.66.77.88 a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1 a=mid:v1
a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5 a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 2366781083 2366781084 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 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 maintain the existing DTLS roles, and the use of a=recvonly to
indicate that the video streams are one-way) indicate that the video streams are one-way)
v=0 v=0
o=- 4962303333179871723 2 IN IP4 0.0.0.0 o=- 4962303333179871723 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=ice-options:trickle
m=audio 52546 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 52546 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 11.22.33.44 c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44 a=rtcp:52546 IN IP4 11.22.33.44
a=mid:a1 a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400 a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv a=sendrecv
a=rtpmap:96 opus/48000/2 a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000 a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive a=setup:passive
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
skipping to change at page 69, line 40 skipping to change at page 71, line 18
raddr 192.168.1.2 rport 51556 raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546 raddr 11.22.33.44 rport 52546
a=end-of-candidates a=end-of-candidates
m=application 52546 UDP/DTLS/SCTP webrtc-datachannel m=application 52546 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 11.22.33.44 c=IN IP4 11.22.33.44
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 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 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive a=setup:passive
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 m=video 52546 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 11.22.33.44 c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44 a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v1 a=mid:v1
a=recvonly a=recvonly
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive a=setup:passive
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli 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 m=video 52546 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 11.22.33.44 c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44 a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v2 a=mid:v2
a=recvonly a=recvonly
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 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 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive a=setup:passive
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli 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 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
skipping to change at page 71, line 49 skipping to change at page 72, line 50
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.
9. IANA Considerations 9. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
10. 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 Peter Thatcher, Taylor Brandstetter, Harald Alvestrand
Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton, and Suhas Nandakumar. Dan Burnett, Neil Stratford, Anant Narayanan,
Richard Ejzak, Adam Bergkvist and Matthew Kaufman all provided Andrew Hutton, Richard Ejzak, Adam Bergkvist and Matthew Kaufman all
valuable feedback on this proposal. provided valuable feedback on this proposal.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE)
Protocol".
[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", draft-ietf-mmusic- the Session Description Protocol", 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.
skipping to change at page 72, line 33 skipping to change at page 73, line 39
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", draft-ietf-mmusic-sdp- Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-04 (work in progress), June 2013. bundle-negotiation-04 (work in 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]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Protocol", draft-ietf-rtcweb-data-protocol-04 (work in
progress), February 2013.
[I-D.ietf-rtcweb-fec] [I-D.ietf-rtcweb-fec]
Uberti, J., "WebRTC Forward Error Correction Uberti, J., "WebRTC Forward Error Correction
Requirements", draft-ietf-rtcweb-fec-00 (work in Requirements", draft-ietf-rtcweb-fec-00 (work in
progress), February 2015. progress), February 2015.
[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.
skipping to change at page 74, line 5 skipping to change at page 74, line 49
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, July Text on Security Considerations", BCP 72, RFC 3552, July
2003. 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)",
RFC 3890, DOI 10.17487/RFC3890, September 2004,
<http://www.rfc-editor.org/info/rfc3890>.
[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, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006. 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(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, April Traversal for Offer/Answer Protocols", RFC 5245, 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.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", RFC Attributes in the Session Description Protocol (SDP)",
6236, May 2011. 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,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.
11.2. Informative References 11.2. Informative References
[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), July draft-nandakumar-rtcweb-sdp-02 (work in progress), July
2013. 2013.
[I-D.shieh-rtcweb-ip-handling]
Shieh, G. and J. Uberti, "WebRTC IP Address Handling
Recommendations", draft-shieh-rtcweb-ip-handling-00 (work
in progress), October 2015.
[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", RFC Modifiers for RTP Control Protocol (RTCP) Bandwidth",
3556, July 2003. RFC 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 76, line 5 skipping to change at page 77, line 5
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
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.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, September the Session Description Protocol", RFC 5956, September
2010. 2010.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>.
[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. 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-13:
o Clarified which SDP lines can be ignored.
o Clarified how to handle various received attributes.
o Revised how atttributes should be generated for bundled m= lines.
o Remove unused references.
o Remove text advocating use of unilateral PTs.
o Trigger an ICE restart even if the ICE candidate policy is being
made more strict.
o Remove the 'public' ICE candidate policy.
o Move open issues/TODOs into GitHub issues.
o Split local/remote description accessors into current/pending.
o Clarify a=imageattr handling.
o Add more detail on VoiceActivityDetection handling.
o Reference draft-shieh-rtcweb-ip-handling.
o Make it clear when an ICE restart should occur.
o Resolve reference TODOs.
o Remove MSID semantics.
o ice-options are now at session level.
o Default RTCP mux policy is now 'require'.
Changes in draft-12: Changes in draft-12:
o Filled in sections on applying local and remote descriptions. o Filled in sections on applying local and remote descriptions.
o Discussed downscaling and upscaling to fulfill imageattr o Discussed downscaling and upscaling to fulfill imageattr
requirements. requirements.
o Updated what SDP can be modified by the application. o Updated what SDP can be modified by the application.
o Updated to latest datachannel SDP. o Updated to latest datachannel SDP.
 End of changes. 180 change blocks. 
435 lines changed or deleted 571 lines changed or added

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