draft-ietf-rtcweb-jsep-24.txt   draft-ietf-rtcweb-jsep-25.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 13, 2018 Cisco Expires: April 25, 2019 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
October 10, 2017 October 22, 2018
JavaScript Session Establishment Protocol JavaScript Session Establishment Protocol
draft-ietf-rtcweb-jsep-24 draft-ietf-rtcweb-jsep-25
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 13, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 27 skipping to change at page 2, line 27
3.4. Session Description Control . . . . . . . . . . . . . . . 11 3.4. Session Description Control . . . . . . . . . . . . . . . 11
3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11
3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12
3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12
3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12
3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13
3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13
3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14
3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15
3.5.5. ICE Versions . . . . . . . . . . . . . . . . . . . . 16
3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16
3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16
3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17 3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20
3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20
3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22
4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 25
4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25
4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25
4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26
4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27
4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 28 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 28
4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28
4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29
4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 29 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 30
4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30
4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30
4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30
4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 30 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 31
4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31
4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31
4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32
4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33
4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33
4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 33 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 34
4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34
4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 34 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 35
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 34 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35
5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35
5.1.2. Profile Names and Interoperability . . . . . . . . . 35 5.1.2. Profile Names and Interoperability . . . . . . . . . 35
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 36 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 37
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 37
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47
5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47
5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57
5.5. Processing a Local Description . . . . . . . . . . . . . 57 5.5. Processing a Local Description . . . . . . . . . . . . . 57
5.6. Processing a Remote Description . . . . . . . . . . . . . 58 5.6. Processing a Remote Description . . . . . . . . . . . . . 58
5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58
5.8. Parsing a Session Description . . . . . . . . . . . . . . 59 5.8. Parsing a Session Description . . . . . . . . . . . . . . 59
5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60
5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61
5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64
5.9. Applying a Local Description . . . . . . . . . . . . . . 65 5.9. Applying a Local Description . . . . . . . . . . . . . . 65
5.10. Applying a Remote Description . . . . . . . . . . . . . . 66 5.10. Applying a Remote Description . . . . . . . . . . . . . . 67
5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 70 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 70
6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74
7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78
7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88
8. Security Considerations . . . . . . . . . . . . . . . . . . . 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96
11.2. Informative References . . . . . . . . . . . . . . . . . 101 11.2. Informative References . . . . . . . . . . . . . . . . . 100
Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 104 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
1. Introduction 1. Introduction
This document describes how the W3C WEBRTC RTCPeerConnection This document describes how the W3C WEBRTC RTCPeerConnection
interface [W3C.webrtc] is used to control the setup, management and interface [W3C.webrtc] is used to control the setup, management and
teardown of a multimedia session. teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
WebRTC call setup has been designed to focus on controlling the media WebRTC call setup has been designed to focus on controlling the media
skipping to change at page 5, line 13 skipping to change at page 5, line 15
using the setRemoteDescription() API. using the setRemoteDescription() API.
To complete the offer/answer exchange, the remote party uses the To complete the offer/answer exchange, the remote party uses the
createAnswer() API to generate an appropriate answer, applies it createAnswer() API to generate an appropriate answer, applies it
using the setLocalDescription() API, and sends the answer back to the using the setLocalDescription() API, and sends the answer back to the
initiator over the signaling channel. When the initiator gets that initiator over the signaling channel. When the initiator gets that
answer, it installs it using the setRemoteDescription() API, and answer, it installs it using the setRemoteDescription() API, and
initial setup is complete. This process can be repeated for initial setup is complete. This process can be repeated for
additional offer/answer exchanges. additional offer/answer exchanges.
Regarding ICE [RFC5245], JSEP decouples the ICE state machine from Regarding ICE [RFC8445], JSEP decouples the ICE state machine from
the overall signaling state machine, as the ICE state machine must the overall signaling state machine, as the ICE state machine must
remain in the JSEP implementation, because only the implementation remain in the JSEP implementation, because only the implementation
has the necessary knowledge of candidates and other transport has the necessary knowledge of candidates and other transport
information. Performing this separation provides additional information. Performing this separation provides additional
flexibility in protocols that decouple session descriptions from flexibility in protocols that decouple session descriptions from
transport. For instance, in traditional SIP, each offer or answer is transport. For instance, in traditional SIP, each offer or answer is
self-contained, including both the session descriptions and the self-contained, including both the session descriptions and the
transport information. However, [I-D.ietf-mmusic-trickle-ice-sip] transport information. However, [I-D.ietf-mmusic-trickle-ice-sip]
allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle], in allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle], in
which the session description can be sent immediately and the which the session description can be sent immediately and the
skipping to change at page 14, line 7 skipping to change at page 14, line 7
using the new remote candidates for connectivity checks. using the new remote candidates for connectivity checks.
3.5.2.1. ICE Candidate Format 3.5.2.1. ICE Candidate Format
In JSEP, ICE candidates are abstracted by an IceCandidate object, and In JSEP, ICE candidates are abstracted by an IceCandidate object, and
as with session descriptions, SDP syntax is used for the internal as with session descriptions, SDP syntax is used for the internal
representation. representation.
The candidate details are specified in an IceCandidate field, using The candidate details are specified in an IceCandidate field, using
the same SDP syntax as the "candidate-attribute" field defined in the same SDP syntax as the "candidate-attribute" field defined in
[RFC5245], Section 15.1. Note that this field does not contain an [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. Note that this field
"a=" prefix, as indicated in the following example: does not contain an "a=" prefix, as indicated in the following
example:
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
The IceCandidate object contains a field to indicate which ICE ufrag The IceCandidate object contains a field to indicate which ICE ufrag
it is associated with, as defined in [RFC5245], Section 15.4. This it is associated with, as defined in [I-D.ietf-mmusic-ice-sip-sdp],
value is used to determine which session description (and thereby Section 4.4. This value is used to determine which session
which gathering phase) this IceCandidate belongs to, which helps description (and thereby which gathering phase) this IceCandidate
resolve ambiguities during ICE restarts. If this field is absent in belongs to, which helps resolve ambiguities during ICE restarts. If
a received IceCandidate (perhaps when communicating with a non-JSEP this field is absent in a received IceCandidate (perhaps when
endpoint), the most recently received session description is assumed. communicating with a non-JSEP endpoint), the most recently received
session description is assumed.
The IceCandidate object also contains fields to indicate which m= The IceCandidate object also contains fields to indicate which m=
section it is associated with, which can be identified in one of two section it is associated with, which can be identified in one of two
ways, either by a m= section index, or a MID. The m= section index ways, either by a m= section index, or a MID. The m= section index
is a zero-based index, with index N referring to the N+1th m= section is a zero-based index, with index N referring to the N+1th m= section
in the session description referenced by this IceCandidate. The MID in the session description referenced by this IceCandidate. The MID
is a "media stream identification" value, as defined in [RFC5888], is a "media stream identification" value, as defined in [RFC5888],
Section 4, which provides a more robust way to identify the m= Section 4, which provides a more robust way to identify the m=
section in the session description, using the MID of the associated section in the session description, using the MID of the associated
RtpTransceiver object (which may have been locally generated by the RtpTransceiver object (which may have been locally generated by the
skipping to change at page 16, line 12 skipping to change at page 16, line 15
One example of where this concept is useful is an application that One example of where this concept is useful is an application that
expects an incoming call at some point in the future, and wants to expects an incoming call at some point in the future, and wants to
minimize the time it takes to establish connectivity, to avoid minimize the time it takes to establish connectivity, to avoid
clipping of initial media. By pre-gathering candidates into the clipping of initial media. By pre-gathering candidates into the
pool, it can exchange and start sending connectivity checks from pool, it can exchange and start sending connectivity checks from
these candidates almost immediately upon receipt of a call. Note these candidates almost immediately upon receipt of a call. Note
though that by holding on to these pre-gathered candidates, which though that by holding on to these pre-gathered candidates, which
will be kept alive as long as they may be needed, the application will be kept alive as long as they may be needed, the application
will consume resources on the STUN/TURN servers it is using. will consume resources on the STUN/TURN servers it is using.
3.5.5. ICE Versions
While this specification formally relies on [RFC8445], at the time of
its publication, the majority of WebRTC implementations support the
version of ICE described in [RFC5245]. The use of the "ice2"
attribute defined in [RFC8445] can be used to detect the version in
use by a remote endpoint and to provide a smooth transition from the
older specification to the newer one. Implementations MUST be able
to accept remote descriptions that do not have the "ice2" attribute.
3.6. Video Size Negotiation 3.6. Video Size Negotiation
Video size negotiation is the process through which a receiver can Video size negotiation is the process through which a receiver can
use the "a=imageattr" SDP attribute [RFC6236] to indicate what video use the "a=imageattr" SDP attribute [RFC6236] to indicate what video
frame sizes it is capable of receiving. A receiver may have hard frame sizes it is capable of receiving. A receiver may have hard
limits on what its video decoder can process, or it may have some limits on what its video decoder can process, or it may have some
maximum set by policy. By specifying these limits in an maximum set by policy. By specifying these limits in an
"a=imageattr" attribute, JSEP endpoints can attempt to ensure that "a=imageattr" attribute, JSEP endpoints can attempt to ensure that
the remote sender transmits video at an acceptable resolution. the remote sender transmits video at an acceptable resolution.
However, when communicating with a non-JSEP endpoint that does not However, when communicating with a non-JSEP endpoint that does not
skipping to change at page 35, line 12 skipping to change at page 35, line 22
JSEP implementations must comply with the specifications listed below JSEP implementations must comply with the specifications listed below
that govern the creation and processing of offers and answers. that govern the creation and processing of offers and answers.
5.1.1. Usage Requirements 5.1.1. Usage Requirements
All session descriptions handled by JSEP implementations, both local All session descriptions handled by JSEP implementations, both local
and remote, MUST indicate support for the following specifications. and remote, MUST indicate support for the following specifications.
If any of these are absent, this omission MUST be treated as an If any of these are absent, this omission MUST be treated as an
error. error.
o ICE, as specified in [RFC5245], MUST be used. Note that the o ICE, as specified in [RFC8445], MUST be used. Note that the
remote endpoint may use a Lite implementation; implementations remote endpoint may use a Lite implementation; implementations
MUST properly handle remote endpoints which do ICE-Lite. MUST properly handle remote endpoints which do ICE-Lite.
o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as
appropriate for the media type, as specified in appropriate for the media type, as specified in
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as
discussed in [I-D.ietf-rtcweb-security-arch]. discussed in [I-D.ietf-rtcweb-security-arch].
5.1.2. Profile Names and Interoperability 5.1.2. Profile Names and Interoperability
For media m= sections, JSEP implementations MUST support the For media m= sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate
this profile for each media m= line they produce in an offer. For this profile for each media m= line they produce in an offer. For
data m= sections, implementations MUST support the "UDP/DTLS/SCTP" data m= sections, implementations MUST support the "UDP/DTLS/SCTP"
profile and MUST indicate this profile for each data m= line they profile and MUST indicate this profile for each data m= line they
produce in an offer. Although these profiles are formally associated produce in an offer. Although these profiles are formally associated
with UDP, ICE can select either UDP [RFC5245] or TCP [RFC6544] with UDP, ICE can select either UDP [RFC8445] or TCP [RFC6544]
transport depending on network conditions, even when advertising a transport depending on network conditions, even when advertising a
UDP profile. UDP profile.
Unfortunately, in an attempt at compatibility, some endpoints Unfortunately, in an attempt at compatibility, some endpoints
generate other profile strings even when they mean to support one of generate other profile strings even when they mean to support one of
these profiles. For instance, an endpoint might generate "RTP/AVP" these profiles. For instance, an endpoint might generate "RTP/AVP"
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its
willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF".
In order to simplify compatibility with such endpoints, JSEP In order to simplify compatibility with such endpoints, JSEP
implementations MUST follow the following rules when processing the implementations MUST follow the following rules when processing the
skipping to change at page 37, line 44 skipping to change at page 38, line 9
Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=")
lines are not useful in this context and SHOULD NOT be included. lines are not useful in this context and SHOULD 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=ice-options" line with the "trickle" option MUST be added, o An "a=ice-options" line with the "trickle" and "ice2" options MUST
as specified in [I-D.ietf-ice-trickle], Section 4. be added, as specified in [I-D.ietf-ice-trickle], Section 3 and
[RFC8445], Section 10.
o If WebRTC identity is being used, an "a=identity" line as o If WebRTC identity is being used, an "a=identity" line as
described in [I-D.ietf-rtcweb-security-arch], Section 5. described in [I-D.ietf-rtcweb-security-arch], Section 5.
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. An m= section is generated for each RtpTransceiver Section 5.14. An m= section is generated for each RtpTransceiver
that has been added to the PeerConnection, excluding any stopped that has been added to the PeerConnection, excluding any stopped
RtpTransceivers; this is done in the order the RtpTransceivers were RtpTransceivers; this is done in the order the RtpTransceivers were
added to the PeerConnection. If there are no such RtpTransceivers, added to the PeerConnection. If there are no such RtpTransceivers,
no m= sections are generated; more can be added later, as discussed no m= sections are generated; more can be added later, as discussed
skipping to change at page 40, line 21 skipping to change at page 40, line 38
o For each supported RTCP feedback mechanism, an "a=rtcp-fb" line, o For each supported RTCP feedback mechanism, an "a=rtcp-fb" line,
as specified in [RFC4585], Section 4.2. The list of RTCP feedback as specified in [RFC4585], Section 4.2. The list of RTCP feedback
mechanisms that SHOULD/MUST be supported is specified in mechanisms that SHOULD/MUST be supported is specified in
[I-D.ietf-rtcweb-rtp-usage], Section 5.1. [I-D.ietf-rtcweb-rtp-usage], Section 5.1.
o If the RtpTransceiver has a sendrecv or sendonly direction: o If the RtpTransceiver has a sendrecv or sendonly direction:
* For each MediaStream that was associated with the transceiver * For each MediaStream that was associated with the transceiver
when it was created via addTrack or addTransceiver, an "a=msid" when it was created via addTrack or addTransceiver, an "a=msid"
line, as specified in [I-D.ietf-mmusic-msid], Section 2. If a line, as specified in [I-D.ietf-mmusic-msid], Section 2, but
MediaStreamTrack is attached to the transceiver's RtpSender, omitting the "appdata" field.
the "a=msid" lines MUST use that track's ID. If no
MediaStreamTrack is attached, a valid ID MUST be generated, in
the same way that the implementation generates IDs for local
tracks.
* If no MediaStream is associated with the transceiver, a single
"a=msid" line with the special value "-" in place of the
MediaStream ID, as specified in [I-D.ietf-mmusic-msid],
Section 3. The track ID MUST be selected as described above.
o If the RtpTransceiver has a sendrecv or sendonly direction, and o If the RtpTransceiver has a sendrecv or sendonly direction, and
the application has specified RID values or has specified more the application has specified RID values or has specified more
than one encoding in the RtpSenders's parameters, an "a=rid" line than one encoding in the RtpSenders's parameters, an "a=rid" line
for each encoding specified. The "a=rid" line is specified in for each encoding specified. The "a=rid" line is specified in
[I-D.ietf-mmusic-rid], and its direction MUST be "send". If the [I-D.ietf-mmusic-rid], and its direction MUST be "send". If the
application has chosen a RID value, it MUST be used as the rid- application has chosen a RID value, it MUST be used as the rid-
identifier; otherwise a RID value MUST be generated by the identifier; otherwise a RID value MUST be generated by the
implementation. RID values MUST be generated in a fashion that implementation. RID values MUST be generated in a fashion that
does not leak user information, e.g., randomly or using a per- does not leak user information, e.g., randomly or using a per-
skipping to change at page 41, line 18 skipping to change at page 41, line 25
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.
The following attributes, which are of category IDENTICAL or The following attributes, which are of category IDENTICAL or
TRANSPORT, MUST appear only in "m=" sections which either have a TRANSPORT, MUST appear only in "m=" sections which either have a
unique address or which are associated with the bundle-tag. (In unique address or which are associated with the bundle-tag. (In
initial offers, this means those "m=" sections which do not contain initial offers, this means those "m=" sections which do not contain
an "a=bundle-only" attribute.) an "a=bundle-only" attribute.)
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
Section 15.4. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4.
o For each desired digest algorithm, one or more "a=fingerprint" o For each desired digest algorithm, one or more "a=fingerprint"
lines for each of the endpoint's certificates, as specified in lines for each of the endpoint's certificates, as specified in
[RFC8122], Section 5. [RFC8122], Section 5.
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=tls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp], o An "a=tls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp],
skipping to change at page 44, line 37 skipping to change at page 44, line 47
o For RtpTransceivers that are not stopped, the "a=msid" line(s) o For RtpTransceivers that are not stopped, the "a=msid" line(s)
MUST stay the same if they are present in the current description, MUST stay the same if they are present in the current description,
regardless of changes to the transceiver's direction or track. If regardless of changes to the transceiver's direction or track. If
no "a=msid" line is present in the current description, "a=msid" no "a=msid" line is present in the current description, "a=msid"
line(s) MUST be generated according to the same rules as for an line(s) MUST be generated according to the same rules as for an
initial offer. initial offer.
o Each "m=" and c=" line MUST be filled in with the port, protocol, o Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as and address of the default candidate for the m= section, as
described in [RFC5245], Section 4.3. If ICE checking has already described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. If
completed for one or more candidate pairs and a candidate pair is ICE checking has already completed for one or more candidate pairs
in active use, then that pair MUST be used, even if ICE has not and a candidate pair is in active use, then that pair MUST be
yet completed. Note that this differs from the guidance in used, even if ICE has not yet completed. Note that this differs
[RFC5245], Section 9.1.2.2, which only refers to offers created from the guidance in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.3.4,
when ICE has completed. In each case, if no RTP candidates have which only refers to offers created when ICE has completed. In
yet been gathered, dummy values MUST be used, as described above. each case, if no RTP candidates have yet been gathered, dummy
values MUST be used, as described 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.1 was specified. If the m= "IceRestart" option ( Section 5.2.3.1 was specified. If the m=
section is bundled into another m= section, it still MUST NOT section is bundled into another m= section, it still MUST NOT
contain any ICE credentials. contain any ICE credentials.
o If the m= section is not bundled into another m= section, its o If the m= section is not bundled into another m= section, its
"a=rtcp" attribute line MUST be filled in with the port and "a=rtcp" attribute line MUST be filled in with the port and
address of the default RTCP candidate, as indicated in [RFC5761], address of the default RTCP candidate, as indicated in [RFC5761],
Section 5.1.3. If no RTCP candidates have yet been gathered, Section 5.1.3. If no RTCP candidates have yet been gathered,
dummy values MUST be used, as described in the initial offer dummy values MUST be used, as described in the initial offer
section above. section above.
o If the m= section is not bundled into another m= section, for each o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If
gathering for the section has completed, an "a=end-of-candidates" candidate gathering for the section has completed, an "a=end-of-
attribute MUST be added, as described in [I-D.ietf-ice-trickle], candidates" attribute MUST be added, as described in
Section 9.3. If the m= section is bundled into another m= [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled
section, both "a=candidate" and "a=end-of-candidates" MUST be into another m= section, both "a=candidate" and "a=end-of-
omitted. candidates" MUST be omitted.
o For RtpTransceivers that are still present, the "a=rid" lines MUST o For RtpTransceivers that are still present, the "a=rid" lines MUST
stay the same. stay the same.
o For RtpTransceivers that are still present, any "a=simulcast" line o For RtpTransceivers that are still present, any "a=simulcast" line
MUST stay the same. MUST stay the same.
If the previous offer was applied using setLocalDescription, and a If the previous offer was applied using setLocalDescription, and a
corresponding answer from the remote side has been applied using corresponding answer from the remote side has been applied using
setRemoteDescription, meaning the PeerConnection is in the "have- setRemoteDescription, meaning the PeerConnection is in the "have-
skipping to change at page 47, line 21 skipping to change at page 47, line 31
5.2.3. Options Handling 5.2.3. Options Handling
The createOffer method takes as a parameter an RTCOfferOptions The createOffer method takes as a parameter an RTCOfferOptions
object. Special processing is performed when generating a SDP object. Special processing is performed when generating a SDP
description if the following options are present. description if the following options are present.
5.2.3.1. IceRestart 5.2.3.1. IceRestart
If the "IceRestart" option is specified, with a value of "true", the If the "IceRestart" option is specified, with a value of "true", the
offer MUST indicate an ICE restart by generating new ICE ufrag and offer MUST indicate an ICE restart by generating new ICE ufrag and
pwd attributes, as specified in [RFC5245], Section 9.1.1.1. If this pwd attributes, as specified in [I-D.ietf-mmusic-ice-sip-sdp],
option is specified on an initial offer, it has no effect (since a Section 3.4.1.1.1. If this option is specified on an initial offer,
new ICE ufrag and pwd are already generated). Similarly, if the ICE it has no effect (since a new ICE ufrag and pwd are already
configuration has changed, this option has no effect, since new ufrag generated). Similarly, if the ICE configuration has changed, this
and pwd attributes will be generated automatically. This option is option has no effect, since new ufrag and pwd attributes will be
primarily useful for reestablishing connectivity in cases where generated automatically. This option is primarily useful for
failures are detected by the application. reestablishing connectivity in cases where failures are detected by
the application.
5.2.3.2. VoiceActivityDetection 5.2.3.2. VoiceActivityDetection
Silence suppression, also known as discontinuous transmission Silence suppression, also known as discontinuous transmission
("DTX"), can reduce the bandwidth used for audio by switching to a ("DTX"), can reduce the bandwidth used for audio by switching to a
special encoding when voice activity is not detected, at the cost of special encoding when voice activity is not detected, at the cost of
some fidelity. some fidelity.
If the "VoiceActivityDetection" option is specified, with a value of If the "VoiceActivityDetection" option is specified, with a value of
"true", the offer MUST indicate support for silence suppression in "true", the offer MUST indicate support for silence suppression in
skipping to change at page 48, line 43 skipping to change at page 49, line 5
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, except that the indicated in the initial offers section above, except that the
"a=ice-options" line, with the "trickle" option as specified in "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 [I-D.ietf-ice-trickle], Section 3, and the "ice2" option as specified
was present in the offer. in [RFC8445], Section 10, is only included if such an option was
present in the offer.
The next step is to generate session-level lip sync groups, as The next step is to generate session-level lip sync groups, as
defined in [RFC5888], Section 7. For each group of type "LS" present defined in [RFC5888], Section 7. For each group of type "LS" present
in the offer, select the local RtpTransceivers that are referenced by in the offer, select the local RtpTransceivers that are referenced by
the MID values in the specified group, and determine which of them the MID values in the specified group, and determine which of them
either reference a common local MediaStream (specified in the calls either reference a common local MediaStream (specified in the calls
to addTrack/addTransceiver used to create them), or have no to addTrack/addTransceiver used to create them), or have no
MediaStream to reference because they were not created by addTrack/ MediaStream to reference because they were not created by addTrack/
addTransceiver. If at least two such RtpTransceivers exist, a group addTransceiver. If at least two such RtpTransceivers exist, a group
of type "LS" with the mid values of these RtpTransceivers MUST be of type "LS" with the mid values of these RtpTransceivers MUST be
skipping to change at page 49, line 19 skipping to change at page 49, line 30
As a simple example, consider the following offer of a single audio As a simple example, consider the following offer of a single audio
and single video track contained in the same MediaStream. SDP lines and single video track contained in the same MediaStream. SDP lines
not relevant to this example have been removed for clarity. As not relevant to this example have been removed for clarity. As
explained in Section 5.2, a group of type "LS" has been added that explained in Section 5.2, a group of type "LS" has been added that
references each track's RtpTransceiver. references each track's RtpTransceiver.
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 10000 UDP/TLS/RTP/SAVPF 0 m=audio 10000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=msid:ms1 mst1a a=msid:ms1
m=video 10001 UDP/TLS/RTP/SAVPF 96 m=video 10001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=msid:ms1 mst1v a=msid:ms1
If the answerer uses a single MediaStream when it adds its tracks, If the answerer uses a single MediaStream when it adds its tracks,
both of its transceivers will reference this stream, and so the both of its transceivers will reference this stream, and so the
subsequent answer will contain a "LS" group identical to that in the subsequent answer will contain a "LS" group identical to that in the
offer, as shown below: offer, as shown below:
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 0 m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=msid:ms2 mst2a a=msid:ms2
m=video 20001 UDP/TLS/RTP/SAVPF 96 m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=msid:ms2 mst2v a=msid:ms2
However, if the answerer groups its tracks into separate However, if the answerer groups its tracks into separate
MediaStreams, its transceivers will reference different streams, and MediaStreams, its transceivers will reference different streams, and
so the subsequent answer will not contain a "LS" group. so the subsequent answer will not contain a "LS" group.
m=audio 20000 UDP/TLS/RTP/SAVPF 0 m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=msid:ms2a mst2a a=msid:ms2a
m=video 20001 UDP/TLS/RTP/SAVPF 96 m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=msid:ms2b mst2v a=msid:ms2b
Finally, if the answerer does not add any tracks, its transceivers Finally, if the answerer does not add any tracks, its transceivers
will not reference any MediaStreams, causing the preferences of the will not reference any MediaStreams, causing the preferences of the
offerer to be maintained, and so the subsequent answer will contain offerer to be maintained, and so the subsequent answer will contain
an identical "LS" group. an identical "LS" group.
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 0 m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=recvonly a=recvonly
skipping to change at page 51, line 12 skipping to change at page 51, line 15
o None of the offered media formats are supported and, if o None of the offered media formats are supported and, if
applicable, allowed by codec preferences. applicable, allowed by codec preferences.
o The bundle policy is "max-bundle", and this is not the first m= o The bundle policy is "max-bundle", and this is not the first m=
section or in the same bundle group as the first m= section. section or in the same bundle group as the first m= section.
o The bundle policy is "balanced", and this is not the first m= o The bundle policy is "balanced", and this is not the first m=
section for this media type or in the same bundle group as the section for this media type or in the same bundle group as the
first m= section for this media type. first m= section for this media type.
o This m= section is in a bundle group, and the group's offerer
tagged m= section is being rejected due to one of the above
reasons. This requires all m= sections in the bundle group to be
rejected, as specified in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 7.3.3.
Otherwise, each m= section in the answer should then be generated as Otherwise, each m= section in the answer should then be generated as
specified in [RFC3264], Section 6.1. For the m= line itself, the specified in [RFC3264], Section 6.1. For the m= line itself, the
following rules must be followed: 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
are available yet, the "dummy" port value of 9 (Discard) MUST be are available yet, the "dummy" port value of 9 (Discard) MUST be
used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. used, as indicated in [I-D.ietf-ice-trickle], 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
skipping to change at page 53, line 9 skipping to change at page 53, line 17
o For each supported RTCP feedback mechanism that is present in the o For each supported RTCP feedback mechanism that is present in the
offer, an "a=rtcp-fb" line, as specified in [RFC4585], offer, an "a=rtcp-fb" line, as specified in [RFC4585],
Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ Section 4.2. The list of RTCP feedback mechanisms that SHOULD/
MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage],
Section 5.1. Section 5.1.
o If the RtpTransceiver has a sendrecv or sendonly direction: o If the RtpTransceiver has a sendrecv or sendonly direction:
* For each MediaStream that was associated with the transceiver * For each MediaStream that was associated with the transceiver
when it was created via addTrack or addTransceiver, an "a=msid" when it was created via addTrack or addTransceiver, an "a=msid"
line, as specified in [I-D.ietf-mmusic-msid], Section 2. If a line, as specified in [I-D.ietf-mmusic-msid], Section 2, but
MediaStreamTrack is attached to the transceiver's RtpSender, omitting the "appdata" field.
the "a=msid" lines MUST use that track's ID. If no
MediaStreamTrack is attached, a valid ID MUST be generated, in
the same way that the implementation generates IDs for local
tracks.
* If no MediaStream is associated with the transceiver, a single
"a=msid" line with the special value "-" in place of the
MediaStream ID, as specified in [I-D.ietf-mmusic-msid],
Section 3. The track ID MUST be selected as described above.
Each m= section which is not bundled into another m= section, MUST Each m= section which is not bundled into another m= section, MUST
contain the following attributes (which are of category IDENTICAL or contain the following attributes (which are of category IDENTICAL or
TRANSPORT): TRANSPORT):
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
Section 15.4. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4.
o For each desired digest algorithm, one or more "a=fingerprint" o For each desired digest algorithm, one or more "a=fingerprint"
lines for each of the endpoint's certificates, as specified in lines for each of the endpoint's certificates, as specified in
[RFC8122], Section 5. [RFC8122], Section 5.
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". When The role value in the answer MUST be "active" or "passive". When
the offer contains the "actpass" value, as will always be the case the offer contains the "actpass" value, as will always be the case
with JSEP endpoints, the answerer SHOULD use the "active" role. with JSEP endpoints, the answerer SHOULD use the "active" role.
skipping to change at page 55, line 29 skipping to change at page 55, line 29
answer. answer.
If any session description was previously supplied to If any session description was previously supplied to
setLocalDescription, an answer is generated by following the steps in setLocalDescription, an answer is generated by following the steps in
the "have-remote-offer" state above, along with these exceptions: the "have-remote-offer" state above, along with these exceptions:
o The "s=" and "t=" lines MUST stay the same. o The "s=" and "t=" lines MUST stay the same.
o Each "m=" and c=" line MUST be filled in with the port and address o Each "m=" and c=" line MUST be filled in with the port and address
of the default candidate for the m= section, as described in of the default candidate for the m= section, as described in
[RFC5245], Section 4.3. Note, however, that the m= line protocol [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Note, however,
need not match the default candidate, because this protocol value that the m= line protocol need not match the default candidate,
must instead match what was supplied in the offer, as described because this protocol value must instead match what was supplied
above. in the offer, as described above.
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 m= section is restarting, in which case new ICE credentials the m= section is restarting, in which case new ICE credentials
must be created as specified in [RFC5245], Section 9.2.1.1. If must be created as specified in [I-D.ietf-mmusic-ice-sip-sdp],
the m= section is bundled into another m= section, it still MUST Section 3.4.1.1.1. If the m= section is bundled into another m=
NOT contain any ICE credentials. section, it still MUST NOT contain any ICE credentials.
o Each "a=tls-id" line MUST stay the same unless the offerer's o Each "a=tls-id" line MUST stay the same unless the offerer's
"a=tls-id" line changed, in which case a new "a=tls-id" value MUST "a=tls-id" line changed, in which case a new "a=tls-id" value MUST
be created, as described in [I-D.ietf-mmusic-dtls-sdp], be created, as described in [I-D.ietf-mmusic-dtls-sdp],
Section 5.2. Section 5.2.
o Each "a=setup" line MUST use an "active" or "passive" role value o Each "a=setup" line MUST use an "active" or "passive" role value
consistent with the existing DTLS association, if the association consistent with the existing DTLS association, if the association
is being continued by the offerer. is being continued by the offerer.
skipping to change at page 56, line 14 skipping to change at page 56, line 14
o If the m= section is not bundled into another m= section and RTCP o If the m= section is not bundled into another m= section and RTCP
multiplexing is not active, an "a=rtcp" attribute line MUST be multiplexing is not active, an "a=rtcp" attribute line MUST be
filled in with the port and address of the default RTCP candidate. filled in with the port and address of the default RTCP candidate.
If no RTCP candidates have yet been gathered, dummy values MUST be If no RTCP candidates have yet been gathered, dummy values MUST be
used, as described in the initial answer section above. used, as described in the initial answer section above.
o If the m= section is not bundled into another m= section, for each o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If
gathering for the section has completed, an "a=end-of-candidates" candidate gathering for the section has completed, an "a=end-of-
attribute MUST be added, as described in [I-D.ietf-ice-trickle], candidates" attribute MUST be added, as described in
Section 9.3. If the m= section is bundled into another m= [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled
section, both "a=candidate" and "a=end-of-candidates" MUST be into another m= section, both "a=candidate" and "a=end-of-
omitted. candidates" MUST be omitted.
o For RtpTransceivers that are not stopped, the "a=msid" line(s) o For RtpTransceivers that are not stopped, the "a=msid" line(s)
MUST stay the same, regardless of changes to the transceiver's MUST stay the same, regardless of changes to the transceiver's
direction or track. If no "a=msid" line is present in the current direction or track. If no "a=msid" line is present in the current
description, "a=msid" line(s) MUST be generated according to the description, "a=msid" line(s) MUST be generated according to the
same rules as for an initial answer. same rules as for an initial answer.
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
skipping to change at page 60, line 17 skipping to change at page 60, line 17
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. same type (typically "a=") can occur in any order.
The following non-attribute lines are not meaningful in the JSEP The following non-attribute lines are not meaningful in the JSEP
context and MAY be discarded once they have been checked. context and MAY be discarded once they have been checked.
The "c=" line MUST be checked for syntax but its value is only The "c=" line MUST be checked for syntax but its value is only
used for ICE mismatch detection, as defined in [RFC5245], used for ICE mismatch detection, as defined in [RFC8445],
Section 6.1. Note that JSEP implementations should never Section 5.4. Note that JSEP implementations should never
encounter this condition because ICE is required for WebRTC. encounter this condition because ICE is required for WebRTC.
The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are
not used by this specification; they MUST be checked for syntax not used by this specification; they MUST be checked for syntax
but their values are not used. but their values are not used.
The remaining non-attribute lines are processed as follows: The remaining non-attribute lines are processed as follows:
The "v=" line MUST have a version of 0, as specified in [RFC4566], The "v=" line MUST have a version of 0, as specified in [RFC4566],
Section 5.1. Section 5.1.
skipping to change at page 60, line 44 skipping to change at page 60, line 44
[RFC4566], Section 5.8, and the bwtype and bandwidth values [RFC4566], Section 5.8, and the bwtype and bandwidth values
stored. stored.
Finally, the attribute lines are processed. Specific processing MUST Finally, the attribute lines are processed. Specific processing MUST
be applied for the following session-level attribute ("a=") lines: be applied for the following session-level 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 [I-D.ietf-mmusic-ice-sip-sdp], Section 4.3, and a value indicating
ice-lite is stored. the presence of ice-lite is stored.
o If present, a single "a=ice-ufrag" line is parsed as specified in o If present, a single "a=ice-ufrag" line is parsed as specified in
[RFC5245], Section 15.4, and the ufrag value is stored. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the ufrag value is
stored.
o If present, a single "a=ice-pwd" line is parsed as specified in o If present, a single "a=ice-pwd" line is parsed as specified in
[RFC5245], Section 15.4, and the password value is stored. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the password value
is stored.
o If present, a single "a=ice-options" line is parsed as specified o If present, a single "a=ice-options" line is parsed as specified
in [RFC5245], Section 15.5, and the set of specified options is in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.6, and the set of
stored. specified options is stored.
o Any "a=fingerprint" lines are parsed as specified in [RFC8122], o Any "a=fingerprint" lines are parsed as specified in [RFC8122],
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 If present, a single "a=tls-id" line is parsed as specified in o If present, a single "a=tls-id" line is parsed as specified in
[I-D.ietf-mmusic-dtls-sdp] Section 5, and the tls-id value is [I-D.ietf-mmusic-dtls-sdp] Section 5, and the tls-id value is
skipping to change at page 62, line 13 skipping to change at page 62, line 17
used. used.
o The "b=" line, if present, MUST be parsed as specified in o The "b=" line, if present, MUST be parsed as specified in
[RFC4566], Section 5.8, and the bwtype and bandwidth values [RFC4566], Section 5.8, and the bwtype and bandwidth values
stored. stored.
Specific processing MUST also be applied for the following attribute Specific processing MUST also be applied for the following attribute
lines: lines:
o If present, a single "a=ice-ufrag" line is parsed as specified in o If present, a single "a=ice-ufrag" line is parsed as specified in
[RFC5245], Section 15.4, and the ufrag value is stored. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the ufrag value is
stored.
o If present, a single "a=ice-pwd" line is parsed as specified in o If present, a single "a=ice-pwd" line is parsed as specified in
[RFC5245], Section 15.4, and the password value is stored. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the password value
is stored.
o If present, a single "a=ice-options" line is parsed as specified o If present, a single "a=ice-options" line is parsed as specified
in [RFC5245], Section 15.5, and the set of specified options is in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.6, and the set of
stored. specified options is stored.
o Any "a=candidate" attributes MUST be parsed as specified in o Any "a=candidate" attributes MUST be parsed as specified in
[RFC5245], Section 15.1, and their values stored. [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1, and their values
stored.
o Any "a=remote-candidates" attributes MUST be parsed as specified o Any "a=remote-candidates" attributes MUST be parsed as specified
in [RFC5245], Section 15.2, but their values are ignored. in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.2, but their values
are ignored.
o If present, a single "a=end-of-candidates" attribute MUST be 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 parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
its presence or absence flagged and stored. its presence or absence flagged and stored.
o Any "a=fingerprint" lines are parsed as specified in [RFC8122], o Any "a=fingerprint" lines are parsed as specified in [RFC8122],
Section 5, and the set of fingerprint and algorithm values is Section 5, and the set of fingerprint and algorithm values is
stored. stored.
If the "m=" proto value indicates use of RTP, as described in If the "m=" proto value indicates use of RTP, as described in
skipping to change at page 63, line 35 skipping to change at page 63, line 41
o If present, a single "a=rtcp-rsize" attribute MUST be parsed as o If present, a single "a=rtcp-rsize" attribute MUST be parsed as
specified in [RFC5506], Section 5, and its presence or absence specified in [RFC5506], Section 5, and its presence or absence
flagged and stored. flagged and stored.
o If present, a single "a=rtcp" attribute MUST be parsed as o If present, a single "a=rtcp" attribute MUST be parsed as
specified in [RFC3605], Section 2.1, but its value is ignored, as specified in [RFC3605], Section 2.1, but its value is ignored, as
this information is superfluous when using ICE. this information is superfluous when using ICE.
o If present, "a=msid" attributes MUST be parsed as specified in o If present, "a=msid" attributes MUST be parsed as specified in
[I-D.ietf-mmusic-msid], Section 3.2, and their values stored. [I-D.ietf-mmusic-msid], Section 3.2, and their values stored,
ignoring any "appdata" field.
o Any "a=imageattr" attributes MUST be parsed as specified in o Any "a=imageattr" attributes MUST be parsed as specified in
[RFC6236], Section 3, and their values stored. [RFC6236], Section 3, and their values stored.
o Any "a=rid" lines MUST be parsed as specified in o Any "a=rid" lines MUST be parsed as specified in
[I-D.ietf-mmusic-rid], Section 10, and their values stored. [I-D.ietf-mmusic-rid], Section 10, and their values stored.
o If present, a single "a=simulcast" line MUST be parsed as o If present, a single "a=simulcast" line MUST be parsed as
specified in [I-D.ietf-mmusic-sdp-simulcast], and its values specified in [I-D.ietf-mmusic-sdp-simulcast], and its values
stored. stored.
skipping to change at page 64, line 31 skipping to change at page 64, line 38
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.1 MUST be present. These features enumerated in Section 5.1.1 MUST be present. These
values MAY either be present at the media level, or inherited from values MAY either be present at the media level, or inherited from
the session level. the session level.
* ICE ufrag and password values, which MUST comply with the size * ICE ufrag and password values, which MUST comply with the size
limits specified in [RFC5245], Section 15.4. limits specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4.
* tls-id value, which MUST be set according to * tls-id value, which MUST be set according to
[I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer
or a response to a re-offer and the tls-id value is different or a response to a re-offer and the tls-id value is different
from that presently in use, the DTLS connection is not being from that presently in use, the DTLS connection is not being
continued and the remote description MUST be part of an ICE continued and the remote description MUST be part of an ICE
restart, together with new ufrag and password values. restart, together with new ufrag and password values.
* DTLS setup value, which MUST be set according to the rules * DTLS setup value, which MUST be set according to the rules
specified in [RFC5763], Section 5 and MUST be consistent with specified in [RFC5763], Section 5 and MUST be consistent with
skipping to change at page 65, line 40 skipping to change at page 65, line 49
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 local description. If an error is returned, the session MUST be a local description. If an error is returned, the session MUST be
restored to the state it was in before performing these steps. restored to the state it was in before performing these steps.
First, m= sections are processed. For each m= section, the following First, m= sections are processed. For each m= section, the following
steps MUST be performed; if any parameters are out of bounds, or steps MUST be performed; if any parameters are out of bounds, or
cannot be applied, processing MUST stop and an error MUST be cannot be applied, processing MUST stop and an error MUST be
returned. returned.
o If this m= section is new, begin gathering candidates for it, as o If this m= section is new, begin gathering candidates for it, as
defined in [RFC5245], Section 4.1.1, unless it is definitively defined in [RFC8445], Section 5.1.1, unless it is definitively
being bundled (either this is an offer and the m= section is being bundled (either this is an offer and the m= section is
marked bundle-only, or it is an answer and the m= section is marked bundle-only, or it is an answer and the m= section is
bundled into into another m= section.) bundled into into another m= section.)
o Or, if the ICE ufrag and password values have changed, trigger the o Or, if the ICE ufrag and password values have changed, trigger the
ICE agent to start an ICE restart, and begin gathering new ICE agent to start an ICE restart as described in [RFC8445],
candidates for the m= section as described in [RFC5245], Section 9, and begin gathering new candidates for the m= section.
Section 9.1.1.1. If this description is an answer, also start If this description is an answer, also start checks on that media
checks on that media section as defined in [RFC5245], section.
Section 9.3.1.1.
o If the m= section proto value indicates use of RTP: o If the m= section proto value indicates use of RTP:
* If there is no RtpTransceiver associated with this m= section, * If there is no RtpTransceiver associated with this m= section,
find one and associate it with this m= section according to the find one and associate it with this m= section according to the
following steps. Note that this situation will only occur when following steps. Note that this situation will only occur when
applying an offer. applying an offer.
+ Find the RtpTransceiver that corresponds to this m= section, + Find the RtpTransceiver that corresponds to this m= section,
using the mapping between transceivers and m= section using the mapping between transceivers and m= section
skipping to change at page 67, line 31 skipping to change at page 67, line 40
specified in [RFC3556], Section 2. specified in [RFC3556], Section 2.
o Any "AS" bandwidth value MUST be ignored, as the meaning of this o Any "AS" bandwidth value MUST be ignored, as the meaning of this
construct at the session level is not well defined. construct at the session level is not well defined.
For each m= section, the following steps MUST be performed; if any For each m= 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 ICE ufrag or password changed from the previous remote o If the ICE ufrag or password changed from the previous remote
description: [RFC5245]. description:
* If the description is of type "offer", the implementation MUST * If the description is of type "offer", the implementation MUST
note that an ICE restart is needed, as described in [RFC5245], note that an ICE restart is needed, as described in
Section 9.1.1.1. [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1
* If the description is of type "answer" or "pranswer", then * If the description is of type "answer" or "pranswer", then
check to see if the current local description is an ICE check to see if the current local description is an ICE
restart, and if not, generate an error. If the PeerConnection restart, and if not, generate an error. If the PeerConnection
state is "have-remote-pranswer", and the ICE ufrag or password state is "have-remote-pranswer", and the ICE ufrag or password
changed from the previous provisional answer, then signal the changed from the previous provisional answer, then signal the
ICE agent to discard any previous ICE check list state for the ICE agent to discard any previous ICE check list state for the
m= section. Finally, signal the ICE agent to begin checks as m= section. Finally, signal the ICE agent to begin checks.
described in [RFC5245], Section 9.3.1.1.
o If the current local description indicates an ICE restart, and o If the current local description indicates an ICE restart, and
either the ICE ufrag or password has not changed from the previous either the ICE ufrag or password has not changed from the previous
remote description, as prescribed by [RFC5245], Section 9.2.1.1, remote description, as prescribed by [RFC8445], Section 9,
generate an error. generate an error.
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 [RFC5245], Section 5.7, and start candidates, as described in [RFC8445], Section 6.1.2, and start
connectivity checks with the appropriate credentials. connectivity checks with the appropriate credentials.
o If an "a=end-of-candidates" attribute is present, process the end- o If an "a=end-of-candidates" attribute is present, process the end-
of-candidates indication as described in [I-D.ietf-ice-trickle], of-candidates indication as described in [I-D.ietf-ice-trickle],
Section 11. Section 11.
o If the m= section proto value indicates use of RTP: o If the m= section proto value indicates use of RTP:
* If the m= section is being recycled (see Section 5.2.2), * If the m= section is being recycled (see Section 5.2.2),
dissociate the currently associated RtpTransceiver by setting dissociate the currently associated RtpTransceiver by setting
skipping to change at page 70, line 51 skipping to change at page 71, line 6
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 m= section, the following steps MUST be performed: For each m= section, the following steps MUST be performed:
o If the m= section has been rejected (i.e. port is set to zero in o If the m= section has been rejected (i.e. port is set to zero in
the answer), stop any reception or transmission of media for this the answer), stop any reception or transmission of media for this
section, and, unless a non-rejected m= section is bundled with section, and, unless a non-rejected m= section is bundled with
this m= section, discard any associated ICE components, as this m= section, discard any associated ICE components, as
described in [RFC5245], Section 9.2.1.3. described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.3.1.
o If the remote DTLS fingerprint has been changed or the tls-id has o If the remote DTLS fingerprint has been changed or the tls-id has
changed, tear down the DTLS connection. This includes the case changed, tear down the DTLS connection. This includes the case
when the PeerConnection state is "have-remote-pranswer". If a when the PeerConnection state is "have-remote-pranswer". If a
DTLS connection needs to be torn down but the answer does not DTLS connection needs to be torn down but the answer does not
indicate an ICE restart or, in the case of "have-remote-pranswer", indicate an ICE restart or, in the case of "have-remote-pranswer",
new ICE credentials, an error MUST be generated. If an ICE new ICE credentials, an error MUST be generated. If an ICE
restart is performed without a change in tls-id or fingerprint, restart is performed without a change in tls-id or fingerprint,
then the same DTLS connection is continued over the new ICE then the same DTLS connection is continued over the new ICE
channel. Note that although JSEP requires that answerers change channel. Note that although JSEP requires that answerers change
skipping to change at page 76, line 6 skipping to change at page 76, line 6
// 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=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 203.0.113.100 c=IN IP4 203.0.113.100
a=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:47017fee-b6c1-4162-929c-a25110252400 a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=ice-ufrag:ETEn a=ice-ufrag:ETEn
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
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=tls-id:91bbf309c0990a6bec11e38ba2933cee a=tls-id:91bbf309c0990a6bec11e38ba2933cee
a=rtcp:10101 IN IP4 203.0.113.100 a=rtcp:10101 IN IP4 203.0.113.100
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 77, line 9 skipping to change at page 77, line 8
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:47017fee-b6c1-4162-929c-a25110252400 a=msid:47017fee-b6c1-4162-929c-a25110252400
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=ice-ufrag:BGKk a=ice-ufrag:BGKk
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
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=tls-id:91bbf309c0990a6bec11e38ba2933cee a=tls-id:91bbf309c0990a6bec11e38ba2933cee
a=rtcp:10103 IN IP4 203.0.113.100 a=rtcp:10103 IN IP4 203.0.113.100
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host
a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10103 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=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 203.0.113.200 c=IN IP4 203.0.113.200
a=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
5a7b57b8-f043-4bd1-a45d-09d4dfa31226
a=ice-ufrag:6sFv a=ice-ufrag:6sFv
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 a=fingerprint:sha-256
6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 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=tls-id:eec3392ab83e11ceb6a0990c903fbb19 a=tls-id:eec3392ab83e11ceb6a0990c903fbb19
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host
skipping to change at page 78, line 34 skipping to change at page 78, line 30
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
4ea4d4a1-2fda-4511-a9cc-1b32c2e59552
7.2. Detailed Example 7.2. Detailed Example
This section shows a more involved example of a session between two This section shows a more involved example of a session between two
JSEP endpoints. Trickle ICE is used in full trickle mode, with a JSEP endpoints. Trickle ICE is used in full trickle mode, with a
bundle policy of "max-bundle", an RTCP mux policy of "require", and a bundle policy of "max-bundle", an RTCP mux policy of "require", and a
single TURN server. Initially, both Alice and Bob establish an audio single TURN server. Initially, both Alice and Bob establish an audio
channel and a data channel. Later, Bob adds two video flows, one for channel and a data channel. Later, Bob adds two video flows, one for
his video feed, and one for screensharing, both supporting FEC, and his video feed, and one for screensharing, both supporting FEC, and
with the video feed configured for simulcast. Alice accepts these with the video feed configured for simulcast. Alice accepts these
skipping to change at page 81, line 9 skipping to change at page 81, line 9
// media is flowing between endpoints // media is flowing between endpoints
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=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 a=group:BUNDLE a1 d1
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=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:57017fee-b6c1-4162-929c-a25110252400 a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=ice-ufrag:ATEn a=ice-ufrag:ATEn
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256 a=fingerprint:sha-256
29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 29: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=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 83, line 9 skipping to change at page 83, line 9
mid a1 mid a1
attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay
raddr 198.51.100.100 rport 11100 raddr 198.51.100.100 rport 11100
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=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 a=group:BUNDLE a1 d1
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=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
6a7b57b8-f043-4bd1-a45d-09d4dfa31226
a=ice-ufrag:7sFv a=ice-ufrag:7sFv
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 a=fingerprint:sha-256
7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 7B: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=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 84, line 37 skipping to change at page 84, line 31
sections for video, both of which are offering FEC, and one of which sections for video, both of which are offering FEC, and one of which
is offering simulcast, note the increment of the version number in is offering simulcast, note the increment of the version number in
the o= line, changes to the c= line, indicating the local candidate the o= line, changes to the c= line, indicating the local candidate
that was selected, and the inclusion of gathered candidates as that was selected, and the inclusion of gathered candidates as
a=candidate lines. a=candidate lines.
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=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.200 c=IN IP4 192.0.2.200
a=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
6a7b57b8-f043-4bd1-a45d-09d4dfa31226
a=ice-ufrag:7sFv a=ice-ufrag:7sFv
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 a=fingerprint:sha-256
7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 7B: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=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 86, line 7 skipping to change at page 85, line 48
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=rtpmap:104 flexfec/90000 a=rtpmap:104 flexfec/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
5ea4d4a1-2fda-4511-a9cc-1b32c2e59552
a=rid:1 send a=rid:1 send
a=rid:2 send a=rid:2 send
a=rid:3 send a=rid:3 send
a=simulcast:send 1;2;3 a=simulcast:send 1;2;3
m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104
c=IN IP4 192.0.2.200 c=IN IP4 192.0.2.200
a=mid:v2 a=mid:v2
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 H264/90000 a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
skipping to change at page 86, line 31 skipping to change at page 86, line 22
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=rtpmap:104 flexfec/90000 a=rtpmap:104 flexfec/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:81317484-2ed4-49d7-9eb7-1414322a7aae a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae
6ea4d4a1-2fda-4511-a9cc-1b32c2e59552
The SDP for |answer-B2| is shown below. In addition to the The SDP for |answer-B2| is shown below. In addition to the
acceptance of the video m= sections, the use of a=recvonly to acceptance of the video m= sections, the use of a=recvonly to
indicate one-way video, and the use of a=imageattr to limit the indicate one-way video, and the use of a=imageattr to limit the
received resolution, note the use of setup:passive to maintain the received resolution, note the use of setup:passive to maintain the
existing DTLS roles. existing DTLS roles.
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=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.100 c=IN IP4 192.0.2.100
a=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:57017fee-b6c1-4162-929c-a25110252400 a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=ice-ufrag:ATEn a=ice-ufrag:ATEn
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256 a=fingerprint:sha-256
29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 29: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=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 90, line 30 skipping to change at page 90, line 20
AliceJS->WebServer: signaling with |answer-C2| AliceJS->WebServer: signaling with |answer-C2|
WebServer->BobJS: signaling with |answer-C2| WebServer->BobJS: signaling with |answer-C2|
BobJS->BobUA: setRemoteDescription with |answer-C2| BobJS->BobUA: setRemoteDescription with |answer-C2|
The SDP for |offer-C1| looks like: The SDP for |offer-C1| looks like:
v=0 v=0
o=- 1070771854436052752 1 IN IP4 0.0.0.0 o=- 1070771854436052752 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
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=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce
e80098db-7159-3c06-229a-00df2a9b3dbc
a=ice-ufrag:4ZcD a=ice-ufrag:4ZcD
a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD
a=fingerprint:sha-256 a=fingerprint:sha-256
C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4:
0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF
a=setup:actpass a=setup:actpass
a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=tls-id:9e5b948ade9c3d41de6617b68f769e55
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 91, line 33 skipping to change at page 91, line 21
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce
ac701365-eb06-42df-cc93-7f22bc308789
a=bundle-only a=bundle-only
|offer-C1-candidate-1| looks like: |offer-C1-candidate-1| looks like:
ufrag 4ZcD ufrag 4ZcD
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay
raddr 0.0.0.0 rport 0 raddr 0.0.0.0 rport 0
The SDP for |answer-C1| looks like: The SDP for |answer-C1| looks like:
v=0 v=0
o=- 6386516489780559513 1 IN IP4 0.0.0.0 o=- 6386516489780559513 1 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
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=mid:a1 a=mid:a1
a=sendonly a=sendonly
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=msid:751f239e-4ae0-c549-aa3d-890de772998b
04b5a445-82cc-c9e8-9ffe-c24d0ef4b0ff
a=ice-ufrag:TpaA a=ice-ufrag:TpaA
a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/
a=fingerprint:sha-256 a=fingerprint:sha-256
A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC:
3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D
a=setup:active a=setup:active
a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=tls-id:55e967f86b7166ed14d3c9eda849b5e9
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 93, line 5 skipping to change at page 92, line 40
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:751f239e-4ae0-c549-aa3d-890de772998b a=msid:751f239e-4ae0-c549-aa3d-890de772998b
39292672-c102-d075-f580-5826f31ca958
|answer-C1-candidate-1| looks like: |answer-C1-candidate-1| looks like:
ufrag TpaA ufrag TpaA
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay
raddr 0.0.0.0 rport 0 raddr 0.0.0.0 rport 0
The SDP for |offer-C2| looks like: The SDP for |offer-C2| looks like:
v=0 v=0
o=- 6386516489780559513 2 IN IP4 0.0.0.0 o=- 6386516489780559513 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.200 c=IN IP4 192.0.2.200
a=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=msid:751f239e-4ae0-c549-aa3d-890de772998b
04b5a445-82cc-c9e8-9ffe-c24d0ef4b0ff
a=ice-ufrag:TpaA a=ice-ufrag:TpaA
a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/
a=fingerprint:sha-256 a=fingerprint:sha-256
A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC:
3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D
a=setup:actpass a=setup:actpass
a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=tls-id:55e967f86b7166ed14d3c9eda849b5e9
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 94, line 28 skipping to change at page 94, line 13
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:751f239e-4ae0-c549-aa3d-890de772998b a=msid:751f239e-4ae0-c549-aa3d-890de772998b
39292672-c102-d075-f580-5826f31ca958
The SDP for |answer-C2| looks like: The SDP for |answer-C2| looks like:
v=0 v=0
o=- 1070771854436052752 2 IN IP4 0.0.0.0 o=- 1070771854436052752 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle a=ice-options:trickle ice2
a=group:BUNDLE a1 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.100 c=IN IP4 192.0.2.100
a=mid:a1 a=mid:a1
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=fmtp:97 0-15 a=fmtp:97 0-15
a=fmtp:98 0-15 a=fmtp:98 0-15
a=maxptime:120 a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce
e80098db-7159-3c06-229a-00df2a9b3dbc
a=ice-ufrag:4ZcD a=ice-ufrag:4ZcD
a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD
a=fingerprint:sha-256 a=fingerprint:sha-256
C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4:
0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF
a=setup:passive a=setup:passive
a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=tls-id:9e5b948ade9c3d41de6617b68f769e55
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 95, line 41 skipping to change at page 95, line 24
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce
ac701365-eb06-42df-cc93-7f22bc308789
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 application JavaScript being it as an Internet protocol, with the application JavaScript being
untrustworthy from the perspective of the JSEP implementation. Thus, untrustworthy from the perspective of the JSEP implementation. Thus,
the threat model of [RFC3552] applies. In particular, JavaScript can the threat model of [RFC3552] applies. In particular, JavaScript can
call the API in any order and with any inputs, including malicious call the API in any order and with any inputs, including malicious
ones. This is particularly relevant when we consider the SDP which ones. This is particularly relevant when we consider the SDP which
is passed to setLocalDescription(). While correct API usage requires is passed to setLocalDescription(). While correct API usage requires
that the application pass in SDP which was derived from createOffer() that the application pass in SDP which was derived from createOffer()
or createAnswer(), there is no guarantee that applications do so. or createAnswer(), there is no guarantee that applications do so.
The JSEP implementation MUST be prepared for the JavaScript to pass The JSEP implementation MUST be prepared for the JavaScript to pass
in bogus data instead. in bogus data instead.
skipping to change at page 97, line 9 skipping to change at page 96, line 36
[I-D.ietf-avtext-rid] [I-D.ietf-avtext-rid]
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
Identifier Source Description (SDES)", draft-ietf-avtext- Identifier Source Description (SDES)", draft-ietf-avtext-
rid-09 (work in progress), October 2016. rid-09 (work in progress), October 2016.
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-14 (work in progress), Protocol", draft-ietf-ice-trickle-21 (work in progress),
September 2017. April 2018.
[I-D.ietf-mmusic-dtls-sdp] [I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-31 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
[I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in
progress), June 2018.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-16 Session Description Protocol", draft-ietf-mmusic-msid-16
(work in progress), February 2017. (work in progress), February 2017.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-rid] [I-D.ietf-mmusic-rid]
Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., Roach, A., "RTP Payload Format Restrictions", draft-ietf-
Roach, A., and B. Campen, "RTP Payload Format mmusic-rid-15 (work in progress), May 2018.
Restrictions", draft-ietf-mmusic-rid-11 (work in
progress), July 2017.
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
Procedures For Stream Control Transmission Protocol (SCTP) Procedures For Stream Control Transmission Protocol (SCTP)
over Datagram Transport Layer Security (DTLS) Transport.", over Datagram Transport Layer Security (DTLS) Transport.",
draft-ietf-mmusic-sctp-sdp-26 (work in progress), April draft-ietf-mmusic-sctp-sdp-26 (work in progress), April
2017. 2017.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-39 (work in progress), August 2017. negotiation-53 (work in progress), September 2018.
[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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), December 2016. (work in progress), February 2018.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-10 (work in progress), July 2017. mmusic-sdp-simulcast-13 (work in progress), June 2018.
[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-06 (work in Requirements", draft-ietf-rtcweb-fec-08 (work in
progress), July 2017. progress), March 2018.
[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-26 (work in progress), March draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016. 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-10 (work in progress), January 2018.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-12 (work in progress), June 2016. rtcweb-security-arch-15 (work in progress), July 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 99, line 40 skipping to change at page 99, line 20
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[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, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <https://www.rfc-editor.org/info/rfc5285>. 2008, <https://www.rfc-editor.org/info/rfc5285>.
[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, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<https://www.rfc-editor.org/info/rfc5761>. <https://www.rfc-editor.org/info/rfc5761>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
skipping to change at page 101, line 20 skipping to change at page 100, line 39
"Sending Multiple RTP Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
RFC 8108, DOI 10.17487/RFC8108, March 2017, RFC 8108, DOI 10.17487/RFC8108, March 2017,
<https://www.rfc-editor.org/info/rfc8108>. <https://www.rfc-editor.org/info/rfc8108>.
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) usage for Trickle ICE", Session Initiation Protocol (SIP) Usage for Incremental
draft-ietf-mmusic-trickle-ice-sip-08 (work in progress), Provisioning of Candidates for the Interactive
July 2017. Connectivity Establishment (Trickle ICE)", draft-ietf-
mmusic-trickle-ice-sip-18 (work in progress), June 2018.
[I-D.ietf-rtcweb-ip-handling] [I-D.ietf-rtcweb-ip-handling]
Uberti, J. and G. Shieh, "WebRTC IP Address Handling Uberti, J., "WebRTC IP Address Handling Requirements",
Requirements", draft-ietf-rtcweb-ip-handling-04 (work in draft-ietf-rtcweb-ip-handling-10 (work in progress),
progress), July 2017. October 2018.
[I-D.ietf-rtcweb-sdp] [I-D.ietf-rtcweb-sdp]
Nandakumar, S. and C. Jennings, "Annotated Example SDP for Nandakumar, S. and C. Jennings, "Annotated Example SDP for
WebRTC", draft-ietf-rtcweb-sdp-07 (work in progress), WebRTC", draft-ietf-rtcweb-sdp-11 (work in progress),
October 2017. October 2018.
[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, DOI 10.17487/RFC3389, Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
September 2002, <https://www.rfc-editor.org/info/rfc3389>. September 2002, <https://www.rfc-editor.org/info/rfc3389>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth",
RFC 3556, DOI 10.17487/RFC3556, July 2003, RFC 3556, DOI 10.17487/RFC3556, July 2003,
<https://www.rfc-editor.org/info/rfc3556>. <https://www.rfc-editor.org/info/rfc3556>.
skipping to change at page 102, line 20 skipping to change at page 101, line 44
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<https://www.rfc-editor.org/info/rfc4588>. <https://www.rfc-editor.org/info/rfc4588>.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006, DOI 10.17487/RFC4733, December 2006,
<https://www.rfc-editor.org/info/rfc4733>. <https://www.rfc-editor.org/info/rfc4733>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <https://www.rfc-editor.org/info/rfc5506>. 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
skipping to change at page 104, line 23 skipping to change at page 104, line 23
| sendonly | [RFC4566] Section 9 | | sendonly | [RFC4566] Section 9 |
| inactive | [RFC4566] Section 9 | | inactive | [RFC4566] Section 9 |
| framerate | [RFC4566] Section 9 | | framerate | [RFC4566] Section 9 |
| fmtp | [RFC4566] Section 9 | | fmtp | [RFC4566] Section 9 |
| quality | [RFC4566] Section 9 | | quality | [RFC4566] Section 9 |
| rtcp | [RFC3605] Section 2.1 | | rtcp | [RFC3605] Section 2.1 |
| setup | [RFC4145] Sections 3, 4, and 5 | | setup | [RFC4145] Sections 3, 4, and 5 |
| connection | [RFC4145] Sections 3, 4, and 5 | | connection | [RFC4145] Sections 3, 4, and 5 |
| fingerprint | [RFC8122] Section 5 | | fingerprint | [RFC8122] Section 5 |
| rtcp-fb | [RFC4585] Section 4.2 | | rtcp-fb | [RFC4585] Section 4.2 |
| candidate | [RFC5245] Section 15.1 |
| remote-candidates | [RFC5245] Section 15.2 |
| ice-lite | [RFC5245] Section 15.3 |
| ice-ufrag | [RFC5245] Section 15.4 |
| ice-pwd | [RFC5245] Section 15.4 |
| ice-options | [RFC5245] Section 15.5 |
| extmap | [RFC5285] Section 7 | | extmap | [RFC5285] Section 7 |
| mid | [RFC5888] Sections 4 and 5 | | mid | [RFC5888] Sections 4 and 5 |
| group | [RFC5888] Sections 4 and 5 | | group | [RFC5888] Sections 4 and 5 |
| imageattr | [RFC6236] Section 3.1 | | imageattr | [RFC6236] Section 3.1 |
| extmap (encrypt | [RFC6904] Section 4 | | extmap (encrypt | [RFC6904] Section 4 |
| option) | | | option) | |
| candidate | [I-D.ietf-mmusic-ice-sip-sdp] Section |
| | 4.1 |
| remote-candidates | [I-D.ietf-mmusic-ice-sip-sdp] Section |
| | 4.2 |
| ice-lite | [I-D.ietf-mmusic-ice-sip-sdp] Section |
| | 4.3 |
| ice-ufrag | [I-D.ietf-mmusic-ice-sip-sdp] Section |
| | 4.4 |
| ice-pwd | [I-D.ietf-mmusic-ice-sip-sdp] Section |
| | 4.4 |
| ice-options | [I-D.ietf-mmusic-ice-sip-sdp] Section |
| | 4.6 |
| msid | [I-D.ietf-mmusic-msid] Section 2 | | msid | [I-D.ietf-mmusic-msid] Section 2 |
| rid | [I-D.ietf-mmusic-rid] Section 10 | | rid | [I-D.ietf-mmusic-rid] Section 10 |
| simulcast | [I-D.ietf-mmusic-sdp-simulcast] Section | | simulcast | [I-D.ietf-mmusic-sdp-simulcast] Section |
| | 6.1 | | | 6.1 |
| tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 | | tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
Table 1: SDP ABNF References Table 1: SDP ABNF References
Appendix B. Change log Appendix B. Change log
Note to RFC Editor: Please remove this section before publication. Note to RFC Editor: Please remove this section before publication.
Changes in draft-25:
o Remove MSID track ID from offers and answers.
o Add note about rejecting all m= sections in a BUNDLE group.
o Update ICE references to RFC 8445 and mention ice2.
Changes in draft-24: Changes in draft-24:
o Clarify that rounding is permitted when trying to maintain aspect o Clarify that rounding is permitted when trying to maintain aspect
ratio. ratio.
o Update tls-id handling to match what is specified in dtls-sdp. o Update tls-id handling to match what is specified in dtls-sdp.
Changes in draft-23: Changes in draft-23:
o Clarify rollback handling, and treat it similarly to other o Clarify rollback handling, and treat it similarly to other
 End of changes. 109 change blocks. 
194 lines changed or deleted 210 lines changed or added

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