draft-ietf-rtcweb-jsep-19.txt   draft-ietf-rtcweb-jsep-20.txt 
Network Working Group J. Uberti Network Working Group J. Uberti
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: September 11, 2017 Cisco Expires: September 30, 2017 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
March 10, 2017 March 29, 2017
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-19 draft-ietf-rtcweb-jsep-20
Abstract Abstract
This document describes the mechanisms for allowing a Javascript This document describes the mechanisms for allowing a Javascript
application to control the signaling plane of a multimedia session application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API, and via the interface specified in the W3C RTCPeerConnection API, and
discusses how this relates to existing signaling protocols. discusses how this relates to existing signaling protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2017. This Internet-Draft will expire on September 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4
1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6
3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Session Descriptions and State Machine . . . . . . . . . 7 3.2. Session Descriptions and State Machine . . . . . . . . . 7
3.3. Session Description Format . . . . . . . . . . . . . . . 11 3.3. Session Description Format . . . . . . . . . . . . . . . 10
3.4. Session Description Control . . . . . . . . . . . . . . . 11 3.4. Session Description Control . . . . . . . . . . . . . . . 10
3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10
3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11
3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 11
3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 11
3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . 13
3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14
3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 15
3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15
3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 17 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8. Interactions With Forking . . . . . . . . . . . . . . . . 19 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18
3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 19
3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 20 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 21 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 21 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 23 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 23
4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 23
4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 24 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 23
4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 24 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 23
4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 25 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 24
4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 26 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 25
4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 27 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 26
4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 27
4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 28
4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 29 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 28
4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 29
4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 29
4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 29
4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 30 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 29
4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 30
4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 30
4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 31
4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 32
4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 32
4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 33 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 32
4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 33
4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 33
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 34 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 33
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 34
5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 34
5.1.2. Profile Names and Interoperability . . . . . . . . . 35 5.1.2. Profile Names and Interoperability . . . . . . . . . 34
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 36 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 35
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 35
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 42
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 46
5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 46
5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 46
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 47
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 47
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 54 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 53
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 55 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 54
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 55
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 56 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 55
5.5. Processing a Local Description . . . . . . . . . . . . . 57 5.5. Processing a Local Description . . . . . . . . . . . . . 56
5.6. Processing a Remote Description . . . . . . . . . . . . . 57 5.6. Processing a Remote Description . . . . . . . . . . . . . 56
5.7. Parsing a Session Description . . . . . . . . . . . . . . 58 5.7. Parsing a Session Description . . . . . . . . . . . . . . 57
5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 58 5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 57
5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 60 5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 59
5.7.3. Semantics Verification . . . . . . . . . . . . . . . 62 5.7.3. Semantics Verification . . . . . . . . . . . . . . . 61
5.8. Applying a Local Description . . . . . . . . . . . . . . 64 5.8. Applying a Local Description . . . . . . . . . . . . . . 63
5.9. Applying a Remote Description . . . . . . . . . . . . . . 65 5.9. Applying a Remote Description . . . . . . . . . . . . . . 64
5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 69 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 68
6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 71 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 70
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 72 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 71
7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 77 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 76
7.3. Early Transport Warmup Example . . . . . . . . . . . . . 86 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 85
8. Security Considerations . . . . . . . . . . . . . . . . . . . 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 93
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.1. Normative References . . . . . . . . . . . . . . . . . . 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 94
11.2. Informative References . . . . . . . . . . . . . . . . . 99 11.2. Informative References . . . . . . . . . . . . . . . . . 98
Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 101 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 100
Appendix B. Appendix B . . . . . . . . . . . . . . . . . . . . . 102 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 101
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116
1. Introduction 1. Introduction
This document describes how the W3C WEBRTC RTCPeerConnection This document describes how the W3C WEBRTC RTCPeerConnection
interface [W3C.WD-webrtc-20140617] is used to control the setup, interface [W3C.WD-webrtc-20140617] is used to control the setup,
management and teardown of a multimedia session. management and teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
The thinking behind WebRTC call setup has been to fully specify and The thinking behind WebRTC call setup has been to fully specify and
skipping to change at page 6, line 50 skipping to change at page 6, line 48
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Semantics and Syntax 3. Semantics and Syntax
3.1. Signaling Model 3.1. Signaling Model
JSEP does not specify a particular signaling model or state machine, JSEP does not specify a particular signaling model or state machine,
other than the generic need to exchange session descriptions in the other than the generic need to exchange session descriptions in the
fashion described by [RFC3264](offer/answer) in order for both sides fashion described by [RFC3264] (offer/answer) in order for both sides
of the session to know how to conduct the session. JSEP provides of the session to know how to conduct the session. JSEP provides
mechanisms to create offers and answers, as well as to apply them to mechanisms to create offers and answers, as well as to apply them to
a session. However, the JSEP implementation is totally decoupled a session. However, the JSEP implementation is totally decoupled
from the actual mechanism by which these offers and answers are from the actual mechanism by which these offers and answers are
communicated to the remote side, including addressing, communicated to the remote side, including addressing,
retransmission, forking, and glare handling. These issues are left retransmission, forking, and glare handling. These issues are left
entirely up to the application; the application has complete control entirely up to the application; the application has complete control
over which offers and answers get handed to the implementation, and over which offers and answers get handed to the implementation, and
when. when.
skipping to change at page 23, line 18 skipping to change at page 22, line 20
maximize multiplexing, at the cost of less compatibility with maximize multiplexing, at the cost of less compatibility with
legacy endpoints. When acting as answerer, the implementation legacy endpoints. When acting as answerer, the implementation
will reject any m= sections other than the first m= section, will reject any m= sections other than the first m= section,
unless they are in the same bundle group as that m= section. unless they are in the same bundle group as that m= section.
As it provides the best tradeoff between performance and As it provides the best tradeoff between performance and
compatibility with legacy endpoints, the default bundle policy MUST compatibility with legacy endpoints, the default bundle policy MUST
be set to "balanced". be set to "balanced".
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding use of
RTP/RTCP multiplexing [RFC5761] using one of the following policies: RTP/RTCP multiplexing [RFC5761] using one of the following policies:
negotiate: The JSEP implementation will gather both RTP and RTCP negotiate: The JSEP implementation will gather both RTP and RTCP
candidates but also will offer "a=rtcp-mux", thus allowing for candidates but also will offer "a=rtcp-mux", thus allowing for
compatibility with either multiplexing or non-multiplexing compatibility with either multiplexing or non-multiplexing
endpoints. endpoints.
require: The JSEP implementation will only gather RTP candidates and require: The JSEP implementation will only gather RTP candidates and
will insert an "a=rtcp-mux-only" indication into any new m= will insert an "a=rtcp-mux-only" indication into any new m=
sections in offers it generates. This halves the number of sections in offers it generates. This halves the number of
candidates that the offerer needs to gather. Applying a candidates that the offerer needs to gather. Applying a
skipping to change at page 38, line 28 skipping to change at page 37, line 28
media formats MUST be generated in the corresponding order, and media formats MUST be generated in the corresponding order, and
MUST exclude any codecs not present in the codec preferences. MUST exclude any codecs not present in the codec preferences.
o The media formats in the answer MAY include codecs present in the o The media formats in the answer MAY include codecs present in the
offer that were discarded in a previous offer/answer exchange. offer that were discarded in a previous offer/answer exchange.
This is necessary for compatibility with third- party call control This is necessary for compatibility with third- party call control
and SIP use cases. and SIP use cases.
o Unless excluded by the above restrictions, the media formats MUST o Unless excluded by the above restrictions, the media formats MUST
include the mandatory audio/video codecs as specified in include the mandatory audio/video codecs as specified in
[I-D.ietf-rtcweb-audio](see Section 3) and [I-D.ietf-rtcweb-audio] (see Section 3) and
[I-D.ietf-rtcweb-video](see Section 5). [I-D.ietf-rtcweb-video] (see Section 5).
The m= line MUST be followed immediately by a "c=" line, as specified The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates are available in [RFC4566], Section 5.7. Again, as no candidates are available
yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
as defined in [I-D.ietf-ice-trickle], Section 5.1. as defined in [I-D.ietf-ice-trickle], Section 5.1.
[I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into [I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into
different categories. To avoid unnecessary duplication when different categories. To avoid unnecessary duplication when
bundling, Section 8.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation] bundling, Section 8.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation]
specifies that attributes of category IDENTICAL or TRANSPORT should specifies that attributes of category IDENTICAL or TRANSPORT should
skipping to change at page 51, line 21 skipping to change at page 50, line 21
media formats MUST be generated in the corresponding order, and media formats MUST be generated in the corresponding order, and
MUST exclude any codecs not present in the codec preferences or MUST exclude any codecs not present in the codec preferences or
not present in the offer. Note that non-JSEP endpoints are not not present in the offer. Note that non-JSEP endpoints are not
subject to this restriction, and might add media formats in the subject to this restriction, and might add media formats in the
answer that are not present in the offer, as specified in answer that are not present in the offer, as specified in
[RFC3264], Section 6.1. Therefore, JSEP implementations MUST be [RFC3264], Section 6.1. Therefore, JSEP implementations MUST be
prepared to receive such answers. prepared to receive such answers.
o Unless excluded by the above restrictions, the media formats MUST o Unless excluded by the above restrictions, the media formats MUST
include the mandatory audio/video codecs as specified in include the mandatory audio/video codecs as specified in
[I-D.ietf-rtcweb-audio](see Section 3) and [I-D.ietf-rtcweb-audio] (see Section 3) and
[I-D.ietf-rtcweb-video](see Section 5). [I-D.ietf-rtcweb-video] (see Section 5).
The m= line MUST be followed immediately by a "c=" line, as specified The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates are available in [RFC4566], Section 5.7. Again, as no candidates are available
yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
as defined in [I-D.ietf-ice-trickle], Section 5.1. as defined in [I-D.ietf-ice-trickle], Section 5.1.
If the offer supports bundle, all m= sections to be bundled must use If the offer supports bundle, all m= sections to be bundled must use
the same ICE credentials and candidates; all m= sections not being the same ICE credentials and candidates; all m= sections not being
bundled must use unique ICE credentials and candidates. Each m= bundled must use unique ICE credentials and candidates. Each m=
section MUST contain the following attributes (which are of attribute section MUST contain the following attributes (which are of attribute
skipping to change at page 71, line 35 skipping to change at page 70, line 35
ICE components in each bundle, and begin muxing these m= sections ICE components in each bundle, and begin muxing these m= sections
accordingly, as described in accordingly, as described in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2.
If the description is of type "answer", and there are still remaining If the description is of type "answer", and there are still remaining
candidates in the ICE candidate pool, discard them. candidates in the ICE candidate pool, discard them.
6. Processing RTP/RTCP 6. Processing RTP/RTCP
When bundling, associating incoming RTP/RTCP with the proper m= When bundling, associating incoming RTP/RTCP with the proper m=
section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. [The section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. When
BUNDLE draft does not currently contain the necessary text to not bundling, the proper m= section is clear from the ICE component
describe this demux, but when it does it will contain text like that over which the RTP/RTCP is received.
contained in Appendix B.] When not bundling, the proper m= section
is clear from the ICE component over which the RTP/RTCP is received.
Once the proper m= section(s) are known, RTP/RTCP is delivered to the Once the proper m= section(s) are known, RTP/RTCP is delivered to the
RtpTransceiver(s) associated with the m= section(s) and further RtpTransceiver(s) associated with the m= section(s) and further
processing of the RTP/RTCP is done at the RtpTransceiver level. This processing of the RTP/RTCP is done at the RtpTransceiver level. This
includes using RID [I-D.ietf-mmusic-rid] to distinguish between includes using RID [I-D.ietf-mmusic-rid] to distinguish between
multiple Encoded Streams, as well as determine which Source RTP multiple Encoded Streams, as well as determine which Source RTP
stream should be repaired by a given Redundancy RTP stream. stream should be repaired by a given Redundancy RTP stream.
7. Examples 7. Examples
skipping to change at page 87, line 45 skipping to change at page 86, line 45
BobJS->BobUA: setRemoteDescription with |offer-C1| BobJS->BobUA: setRemoteDescription with |offer-C1|
BobUA->BobJS: ontrack events for audio and video BobUA->BobJS: ontrack events for audio and video
// a relay candidate is sent to Bob // a relay candidate is sent to Bob
AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1| AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1|
AliceJS->WebServer: signaling with |offer-C1-candidate-1| AliceJS->WebServer: signaling with |offer-C1-candidate-1|
WebServer->BobJS: signaling with |offer-C1-candidate-1| WebServer->BobJS: signaling with |offer-C1-candidate-1|
BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1|
// Bob prepares an early answer to warm up the transport // Bob prepares an early answer to warmup the transport
BobJS->BobUA: addTransceiver with null audio and video tracks BobJS->BobUA: addTransceiver with null audio and video tracks
BobJS->BobUA: transceiver.setDirection(sendonly) for both BobJS->BobUA: transceiver.setDirection(sendonly) for both
BobJS->BobUA: createAnswer BobJS->BobUA: createAnswer
BobJS->BobUA: setLocalDescription with answer BobJS->BobUA: setLocalDescription with answer
// |answer-C1| is sent over signaling protocol to Alice // |answer-C1| is sent over signaling protocol to Alice
BobJS->WebServer: signaling with |answer-C1| BobJS->WebServer: signaling with |answer-C1|
WebServer->AliceJS: signaling with |answer-C1| WebServer->AliceJS: signaling with |answer-C1|
// |answer-C1| (sendonly) arrives at Alice // |answer-C1| (sendonly) arrives at Alice
AliceJS->AliceUA: setRemoteDescription with |answer-C1| AliceJS->AliceUA: setRemoteDescription with |answer-C1|
AliceUA->AliceJS: ontrack events for audio and video AliceUA->AliceJS: ontrack events for audio and video
// a relay candidate is sent to Alice // a relay candidate is sent to Alice
BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1|
skipping to change at page 88, line 20 skipping to change at page 87, line 21
// a relay candidate is sent to Alice // a relay candidate is sent to Alice
BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1|
BobJS->WebServer: signaling with |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1|
WebServer->AliceJS: signaling with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-1|
AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1|
// ICE and DTLS establish while call is ringing // ICE and DTLS establish while call is ringing
// Bob accepts call, starts media, and sends a new offer // Bob accepts call, starts media, and sends new offer
BobJS->BobUA: transceiver.setTrack with audio and video tracks BobJS->BobUA: transceiver.setTrack with audio and video tracks
BobUA->AliceUA: media sent from Bob to Alice BobUA->AliceUA: media sent from Bob to Alice
BobJS->BobUA: transceiver.setDirection(sendrecv) for both BobJS->BobUA: transceiver.setDirection(sendrecv) for both
transceivers transceivers
BobJS->BobUA: createOffer BobJS->BobUA: createOffer
BobJS->BobUA: setLocalDescription with offer BobJS->BobUA: setLocalDescription with offer
// |offer-C2| is sent over signaling protocol to Alice // |offer-C2| is sent over signaling protocol to Alice
BobJS->WebServer: signaling with |offer-C2| BobJS->WebServer: signaling with |offer-C2|
WebServer->AliceJS: signaling with |offer-C2| WebServer->AliceJS: signaling with |offer-C2|
skipping to change at page 97, line 45 skipping to change at page 96, line 45
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July Text on Security Considerations", BCP 72, RFC 3552, July
2003. 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", Modifier for the Session Description Protocol (SDP)", RFC
RFC 3890, DOI 10.17487/RFC3890, September 2004, 3890, DOI 10.17487/RFC3890, September 2004,
<http://www.rfc-editor.org/info/rfc3890>. <http://www.rfc-editor.org/info/rfc3890>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
skipping to change at page 98, line 32 skipping to change at page 97, line 32
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", Attributes in the Session Description Protocol (SDP)", RFC
RFC 6236, May 2011. 6236, May 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
September 2012, <http://www.rfc-editor.org/info/rfc6716>. September 2012, <http://www.rfc-editor.org/info/rfc6716>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, April Real-time Transport Protocol (SRTP)", RFC 6904, April
2013. 2013.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/
DOI 10.17487/RFC7160, April 2014, RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>. <http://www.rfc-editor.org/info/rfc7160>.
[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format
for the Opus Speech and Audio Codec", RFC 7587, for the Opus Speech and Audio Codec", RFC 7587, DOI
DOI 10.17487/RFC7587, June 2015, 10.17487/RFC7587, June 2015,
<http://www.rfc-editor.org/info/rfc7587>. <http://www.rfc-editor.org/info/rfc7587>.
[RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto'
Field for Transporting RTP Media over TCP under Various Field for Transporting RTP Media over TCP under Various
RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016,
<http://www.rfc-editor.org/info/rfc7850>. <http://www.rfc-editor.org/info/rfc7850>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
skipping to change at page 99, line 47 skipping to change at page 98, line 47
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002. Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
RFC 3556, July 2003. 3556, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611, DOI
DOI 10.17487/RFC3611, November 2003, 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, December 2004. RFC 3960, December 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
skipping to change at page 101, line 7 skipping to change at page 100, line 7
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, Mixer Audio Level Indication", RFC 6464, DOI 10.17487/
DOI 10.17487/RFC6464, December 2011, RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>. <http://www.rfc-editor.org/info/rfc6464>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>. March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
skipping to change at page 102, line 5 skipping to change at page 101, line 5
Jennings, "WebRTC 1.0: Real-time Communication Between Jennings, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc- Browsers", World Wide Web Consortium WD WD-webrtc-
20140617, June 2014, 20140617, June 2014,
<http://www.w3.org/TR/2011/WD-webrtc-20140617>. <http://www.w3.org/TR/2011/WD-webrtc-20140617>.
Appendix A. Appendix A Appendix A. Appendix A
For the syntax validation performed in Section 5.7, the following For the syntax validation performed in Section 5.7, the following
list of ABNF definitions is used: list of ABNF definitions is used:
+-----------------------+-------------------------------------------+ +------------------------+------------------------------------------+
| Attribute | Reference | | Attribute | Reference |
+-----------------------+-------------------------------------------+ +------------------------+------------------------------------------+
| ptime | [RFC4566] Section 9 | | ptime | [RFC4566] Section 9 |
| maxptime | [RFC4566] Section 9 | | maxptime | [RFC4566] Section 9 |
| rtpmap | [RFC4566] Section 9 | | rtpmap | [RFC4566] Section 9 |
| recvonly | [RFC4566] Section 9 | | recvonly | [RFC4566] Section 9 |
| sendrecv | [RFC4566] Section 9 | | sendrecv | [RFC4566] Section 9 |
| 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 | [RFC4572] Section 5 | | fingerprint | [RFC4572] Section 5 |
| rtcp-fb | [RFC4585] Section 4.2 | | rtcp-fb | [RFC4585] Section 4.2 |
| candidate | [RFC5245] Section 15.1 | | candidate | [RFC5245] Section 15.1 |
| remote-candidates | [RFC5245] Section 15.2 | | remote-candidates | [RFC5245] Section 15.2 |
| ice-lite | [RFC5245] Section 15.3 | | ice-lite | [RFC5245] Section 15.3 |
| ice-ufrag | [RFC5245] Section 15.4 | | ice-ufrag | [RFC5245] Section 15.4 |
| ice-pwd | [RFC5245] Section 15.4 | | ice-pwd | [RFC5245] Section 15.4 |
| ice-options | [RFC5245] Section 15.5 | | ice-options | [RFC5245] Section 15.5 |
| extmap | [RFC5285] Section 7 | | extmap | [RFC5285] Section 7 |
| mid | [RFC5888] Section 4 and 5 | | mid | [RFC5888] Section 4 and 5 |
| group | [RFC5888] Section 4 and 5 | | group | [RFC5888] Section 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) | |
| 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 |
| dtls-id | [I-D.ietf-mmusic-dtls-sdp]Section 4 | | dtls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 |
+-----------------------+-------------------------------------------+ +------------------------+------------------------------------------+
Table 1: SDP ABNF References Table 1: SDP ABNF References
Appendix B. Appendix B Appendix B. Change log
The following text is meant to completely replace section
"Associating RTP/RTCP Streams With Correct SDP Media Description" of
[I-D.ietf-mmusic-sdp-bundle-negotiation].
As described in [RFC3550], RTP packets are associated with RTP
streams [RFC7656]. Each RTP stream is identified by an SSRC value,
and each RTP packet includes an SSRC field that is used to associate
the packet with the correct RTP stream. RTCP packets also use SSRCs
to identify which RTP streams the packet relates to. However, a RTCP
packet can contain multiple SSRC fields, in the course of providing
feedback or reports on different RTP streams, and therefore can be
associated with multiple such streams.
In order to be able to process received RTP/RTCP packets correctly,
it must be possible to associate an RTP stream with the correct "m="
line, as the "m=" line and SDP attributes associated with the "m="
line contain information needed to process the packets.
As all RTP streams associated with a BUNDLE group use the same
address:port combination for sending and receiving RTP/RTCP packets,
the local address:port combination cannot be used to associate an RTP
stream with the correct "m=" line. In addition, multiple RTP streams
might be associated with the same "m=" line.
An offerer and answerer can inform each other which SSRC values they
will use for an RTP stream by using the SDP 'ssrc' attribute
[RFC5576]. However, an offerer will not know which SSRC values the
answerer will use until the offerer has received the answer providing
that information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate an RTP stream with
the correct "m=" line using the SSRC value associated with the RTP
stream. In addition, the offerer and answerer may start using new
SSRC values mid-session, without informing each other using the SDP
'ssrc' attribute.
In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" line, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14, where the
offerer and answerer insert the identification-tag associated with an
"m=" line (provided by the remote peer) into RTP and RTCP packets
associated with a BUNDLE group.
When using this mechanism, the mapping from an SSRC to an
identification-tag is carried in RTP header extensions or RTCP SDES
packets, as specified in [I-D.ietf-mmusic-sdp-bundle-negotiation],
Section 14). Since a compound RTCP packet can contain multiple RTCP
SDES packets, and each RTCP SDES packet can contain multiple chunks,
a single RTCP packet can contain several SSRC to identification-tag
mappings. The offerer and answerer maintain tables used for routing
that are updated each time an RTP/RTCP packet contains new
information that affects how packets should be routed.
However, some implementations of
[I-D.ietf-mmusic-sdp-bundle-negotiation] may not include this
identification-tag in their RTP and RTCP traffic when using BUNDLE,
and instead use a payload type based mechanism for demuxing. In this
situation, each "m=" line MUST use unique payload type values, in
order for the payload type to be a reliable indicator of the relevant
"m=" line for the RTP stream.
Applications can implement RTP stacks in many different ways. The
algorithm below details one way that demultiplexing can be
accomplished, but is not meant to be prescriptive about exactly how
an RTP stack needs to be implemented. Applications MAY use any
algorithm that achieves equivalent results to those described in the
algorithm below.
To prepare for demultiplexing RTP/RTCP packets to the correct "m="
line, the following steps MUST be followed for each BUNDLE group.
Construct a table mapping MID to "m=" line for each "m=" line in
this BUNDLE group. Note that an "m=" line may only have one MID.
Construct a table mapping incoming SSRC to "m=" line for each "m="
line in this BUNDLE group and for each SSRC configured for
receiving in that "m=" line.
Construct a table mapping outgoing SSRC to "m=line" for each "m="
line in this BUNDLE group and for each SSRC configured for sending
in that "m=" line.
Construct a table mapping payload type to "m=" line for each "m="
line in the BUNDLE group and for each payload type configured for
receiving in that "m=" line. If any payload type is configured
for receiving in more than one "m=" line in the BUNDLE group, do
not it include it in the table, as it cannot be used to uniquely
identify a "m=" line.
Note that for each of these tables, there can only be one mapping
for any given key (MID, SSRC, or PT). In other words, the tables
are not multimaps.
As "m=" lines are added or removed from the BUNDLE groups, or their
configurations are changed, the tables above MUST also be updated.
For each RTP packet received, the following steps MUST be followed to
route the packet to the correct "m=" section within a BUNDLE group.
Note that the phrase 'deliver a packet to the "m=" line' means to
further process the packet as would normally happen with RTP/RTCP, if
it were received on a transport associated with that "m=" line
outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd),
including dropping an RTP packet if the packet's PT does not match
any PT in the "m=" line.
If the packet has a MID, and that MID is not in the table mapping
MID to "m=" line, drop the packet and stop.
If the packet has a MID, and the packet's extended sequence number
is greater than that of the last MID update, as discussed in
[RFC7941], Section 4.2.6, update the incoming SSRC mapping table
to include an entry that maps the packet's SSRC to the "m=" line
for that MID.
If the packet's SSRC is in the incoming SSRC mapping table, check
that the packet's PT matches a PT included on the associated "m="
line. If so, route the packet to that associated "m=" line and
stop; otherwise drop the packet and stop.
If the packet's payload type is in the payload type table, update
the the incoming SSRC mapping table to include an entry that maps
the packet's SSRC to the "m=" line for that payload type. In
addition, route the packet to the associated "m=" line and stop.
Otherwise, drop the packet.
For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the packet MUST be routed to the
"m=" line for the RTP streams it contains information about. This
routing is type-dependent, as each kind of RTCP packet has its own
mechanism for associating it with the relevant RTP streams.
Packets for which no appropriate "m=" line can be identified (i.e.,
for unknown RTP streams) are not relevant in the context of this
algorithm and MAY be dropped. This situation may occur with certain
multiparty RTP topologies.
Rules for handling the various types of RTCP packets are explained
below.
If the packet is of type SDES, for each chunk in the packet whose
SSRC is found in the incoming SSRC table, deliver a copy of the
packet to the "m=" line associated with that SSRC. In addition,
for any SDES MID items contained in these chunks, if the MID is
found in the table mapping MID to "m=" line, update the incoming
SSRC table to include an entry that maps the chunk's SSRC to the
"m=" line associated with that MID, unless the packet is older
than the packet that most recently updated the mapping for this
SSRC, as discussed in [RFC7941], Section 4.2.6.
Note that if an SDES packet is received as part of a compound RTCP
packet, the SSRC to "m=" line mapping may not exist until the SDES
packet is handled (e.g., in the case where RTCP for a source is
received before any RTP packets). Therefore, when processing a
compound packet, any contained SDES packet MUST be handled first.
If the packet is of type BYE, it indicates that the RTP streams
referenced in the packet are ending. Therefore, for each SSRC
indicated in the packet that is found in the incoming SSRC table,
first deliver a copy of the packet to the "m=" line associated
with that SSRC, but then remove the entry for that SSRC from the
incoming SSRC table.
If the packet is of type SR or RR, for each report block in the
report whose "SSRC of source" is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with
that SSRC. In addition, if the packet is of type SR, and the
sender SSRC for the packet is found in the incoming SSRC table,
deliver a copy of the packet to the "m=" line associated with that
SSRC.
If the implementation supports RTCP XR and the packet is of type
XR, as defined in [RFC3611], for each report block in the report
whose "SSRC of source" is is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with
that SSRC. In addition, if the sender SSRC for the packet is
found in the incoming SSRC table, deliver a copy of the packet to
the "m=" line associated with that SSRC.
If the packet is a feedback message of type RTPFB or PSFB, as
defined in [RFC4585], it will contain a media source SSRC, and
this SSRC is used for routing certain subtypes of feedback
messages. However, several subtypes of PSFB messages include
target SSRC(s) in a section called Feedback Control Information
(FCI). For these messages, the target SSRC(s) are used for
routing.
If the packet is a feedback message that does not include target
SSRCs in its FCI section, and the media source SSRC is found in
the outgoing SSRC table, deliver the packet to the "m=" line
associated with that SSRC. RTPFB and PSFB types that are handled
in this way include:
Generic NACK: [RFC4585] (PT=RTPFB, FMT=1).
Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1).
Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2).
Reference Picture Selection Indication (RPSI): [RFC4585]
(PT=PSFB, FMT=3).
If the packet is a feedback message that does include target
SSRC(s) in its FCI section, it can either be a request or a
notification. Requests reference a RTP stream that is being sent
by the message recipient, whereas notifications are responses to
an earlier request, and therefore reference a RTP stream that is
being received by the message recipient.
If the packet is a feedback request that includes target SSRC(s),
for each target SSRC that is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with
that SSRC. PSFB types that are handled in this way include:
Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4).
Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB,
FMT=5).
H.271 Video Back Channel Message (VBCM): [RFC5104]
(PT=PSFB, FMT=7).
Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB,
FMT=TBD).
If the packet is a feedback notification that include target
SSRC(s), for each target SSRC that is found in the incoming SSRC
table, deliver a copy of the RTCP packet to the "m=" line
associated with that SSRC. PSFB types that are handled in this
way include:
Temporal-Spatial Trade-off Notification (TSTN): [RF
C5104] (PT=PSFB, FMT=6). This message is a notification in
response to a prior TSTR.
If the packet is of type APP, the only routing information Note: This section will be removed by RFC Editor before publication.
included is the source of the packet, and therefore the packet
could be related to any existing "m=" line. Accordingly, deliver
a copy of the packet to each "m=" line.
Appendix C. Change log Changes in draft-20:
Note: This section will be removed by RFC Editor before publication. o Remove Appendix-B.
Changes in draft-19: Changes in draft-19:
o Examples are now machine-generated for correctness, and use IETF- o Examples are now machine-generated for correctness, and use IETF-
approved example IP addresses. approved example IP addresses.
o Add early transport warmup example, and add missing attributes to o Add early transport warmup example, and add missing attributes to
existing examples. existing examples.
o Only send "a=rtcp-mux-only" and "a=bundle-only" on new m= o Only send "a=rtcp-mux-only" and "a=bundle-only" on new m=
 End of changes. 26 change blocks. 
395 lines changed or deleted 153 lines changed or added

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