--- 1/draft-ietf-rtcweb-jsep-19.txt 2017-03-29 12:13:23.647125706 -0700 +++ 2/draft-ietf-rtcweb-jsep-20.txt 2017-03-29 12:13:23.855130650 -0700 @@ -1,21 +1,21 @@ Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track C. Jennings -Expires: September 11, 2017 Cisco +Expires: September 30, 2017 Cisco E. Rescorla, Ed. Mozilla - March 10, 2017 + March 29, 2017 Javascript Session Establishment Protocol - draft-ietf-rtcweb-jsep-19 + draft-ietf-rtcweb-jsep-20 Abstract This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,106 +51,105 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 3.2. Session Descriptions and State Machine . . . . . . . . . 7 - 3.3. Session Description Format . . . . . . . . . . . . . . . 11 - 3.4. Session Description Control . . . . . . . . . . . . . . . 11 - 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 - 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 - 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 - 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 - 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 + 3.3. Session Description Format . . . . . . . . . . . . . . . 10 + 3.4. Session Description Control . . . . . . . . . . . . . . . 10 + 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10 + 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11 + 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 11 + 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 11 + 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 12 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13 - 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 - 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 - 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 - 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 - 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 17 - 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 19 - 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 - 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 20 - 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 21 - 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 21 - 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 23 - 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 - 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24 - 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 24 - 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 24 - 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 25 - 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 26 - 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 27 - 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 - 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 - 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 29 - 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 - 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30 - 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30 - 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 30 - 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 - 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31 - 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32 - 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 - 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 - 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 - 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33 - 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 33 - 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 - 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 - 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 34 - 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35 - 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 - 5.1.2. Profile Names and Interoperability . . . . . . . . . 35 - 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 36 - 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36 - 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 - 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 - 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 - 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 - 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 - 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 - 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 54 - 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 55 - 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 - 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 56 - 5.5. Processing a Local Description . . . . . . . . . . . . . 57 - 5.6. Processing a Remote Description . . . . . . . . . . . . . 57 - 5.7. Parsing a Session Description . . . . . . . . . . . . . . 58 - 5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 58 - 5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 60 - 5.7.3. Semantics Verification . . . . . . . . . . . . . . . 62 - 5.8. Applying a Local Description . . . . . . . . . . . . . . 64 - 5.9. Applying a Remote Description . . . . . . . . . . . . . . 65 - 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 69 - 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 71 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 71 - 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 72 - 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 77 - 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 86 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 94 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 95 - 11.2. Informative References . . . . . . . . . . . . . . . . . 99 - Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 101 - Appendix B. Appendix B . . . . . . . . . . . . . . . . . . . . . 102 - Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 107 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116 + 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 13 + 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14 + 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 15 + 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15 + 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16 + 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18 + 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 19 + 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19 + 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 20 + 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20 + 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22 + 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 23 + 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 23 + 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 23 + 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 23 + 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 24 + 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 25 + 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 26 + 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 27 + 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 28 + 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 28 + 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 29 + 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 29 + 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 29 + 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 29 + 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 30 + 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 30 + 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 31 + 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 32 + 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 32 + 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 32 + 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 32 + 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 32 + 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 33 + 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 33 + 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 33 + 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 34 + 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 34 + 5.1.2. Profile Names and Interoperability . . . . . . . . . 34 + 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 35 + 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 35 + 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 42 + 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 46 + 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 46 + 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 46 + 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 47 + 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 47 + 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 53 + 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 54 + 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 55 + 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 55 + 5.5. Processing a Local Description . . . . . . . . . . . . . 56 + 5.6. Processing a Remote Description . . . . . . . . . . . . . 56 + 5.7. Parsing a Session Description . . . . . . . . . . . . . . 57 + 5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 57 + 5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 59 + 5.7.3. Semantics Verification . . . . . . . . . . . . . . . 61 + 5.8. Applying a Local Description . . . . . . . . . . . . . . 63 + 5.9. Applying a Remote Description . . . . . . . . . . . . . . 64 + 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 68 + 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 70 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 70 + 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 71 + 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 76 + 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 85 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 93 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 94 + 11.2. Informative References . . . . . . . . . . . . . . . . . 98 + Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 100 + Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 101 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 1. Introduction This document describes how the W3C WEBRTC RTCPeerConnection interface [W3C.WD-webrtc-20140617] is used to control the setup, management and teardown of a multimedia session. 1.1. General Design of JSEP The thinking behind WebRTC call setup has been to fully specify and @@ -3289,25 +3288,23 @@ ICE components in each bundle, and begin muxing these m= sections accordingly, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. If the description is of type "answer", and there are still remaining candidates in the ICE candidate pool, discard them. 6. Processing RTP/RTCP When bundling, associating incoming RTP/RTCP with the proper m= - section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. [The - BUNDLE draft does not currently contain the necessary text to - describe this demux, but when it does it will contain text like that - contained in Appendix B.] When not bundling, the proper m= section - is clear from the ICE component over which the RTP/RTCP is received. + section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. 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 RtpTransceiver(s) associated with the m= section(s) and further processing of the RTP/RTCP is done at the RtpTransceiver level. This includes using RID [I-D.ietf-mmusic-rid] to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream. 7. Examples @@ -3949,21 +3945,21 @@ // a relay candidate is sent to Alice BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| // 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 BobUA->AliceUA: media sent from Bob to Alice BobJS->BobUA: transceiver.setDirection(sendrecv) for both transceivers BobJS->BobUA: createOffer BobJS->BobUA: setLocalDescription with offer // |offer-C2| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |offer-C2| WebServer->AliceJS: signaling with |offer-C2| @@ -4351,22 +4347,22 @@ [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC3890] Westerlund, M., "A Transport Independent Bandwidth - Modifier for the Session Description Protocol (SDP)", - RFC 3890, DOI 10.17487/RFC3890, September 2004, + Modifier for the Session Description Protocol (SDP)", RFC + 3890, DOI 10.17487/RFC3890, September 2004, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the @@ -4386,42 +4382,42 @@ [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image - Attributes in the Session Description Protocol (SDP)", - RFC 6236, May 2011. + Attributes in the Session Description Protocol (SDP)", RFC + 6236, May 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, April 2013. [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple - Clock Rates in an RTP Session", RFC 7160, - DOI 10.17487/RFC7160, April 2014, + Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/ + RFC7160, April 2014, . [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format - for the Opus Speech and Audio Codec", RFC 7587, - DOI 10.17487/RFC7587, June 2015, + for the Opus Speech and Audio Codec", RFC 7587, DOI + 10.17487/RFC7587, June 2015, . [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, . [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, @@ -4447,26 +4443,26 @@ [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth - Modifiers for RTP Control Protocol (RTCP) Bandwidth", - RFC 3556, July 2003. + Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC + 3556, July 2003. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control - Protocol Extended Reports (RTCP XR)", RFC 3611, - DOI 10.17487/RFC3611, November 2003, + Protocol Extended Reports (RTCP XR)", RFC 3611, DOI + 10.17487/RFC3611, November 2003, . [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. @@ -4496,22 +4492,22 @@ for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- - Mixer Audio Level Indication", RFC 6464, - DOI 10.17487/RFC6464, December 2011, + Mixer Audio Level Indication", RFC 6464, DOI 10.17487/ + RFC6464, December 2011, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, @@ -4530,23 +4526,23 @@ Jennings, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20140617, June 2014, . Appendix A. Appendix A For the syntax validation performed in Section 5.7, the following list of ABNF definitions is used: - +-----------------------+-------------------------------------------+ + +------------------------+------------------------------------------+ | Attribute | Reference | - +-----------------------+-------------------------------------------+ + +------------------------+------------------------------------------+ | ptime | [RFC4566] Section 9 | | maxptime | [RFC4566] Section 9 | | rtpmap | [RFC4566] Section 9 | | recvonly | [RFC4566] Section 9 | | sendrecv | [RFC4566] Section 9 | | sendonly | [RFC4566] Section 9 | | inactive | [RFC4566] Section 9 | | framerate | [RFC4566] Section 9 | | fmtp | [RFC4566] Section 9 | | quality | [RFC4566] Section 9 | @@ -4565,269 +4561,31 @@ | mid | [RFC5888] Section 4 and 5 | | group | [RFC5888] Section 4 and 5 | | imageattr | [RFC6236] Section 3.1 | | extmap (encrypt | [RFC6904] Section 4 | | option) | | | msid | [I-D.ietf-mmusic-msid] Section 2 | | rid | [I-D.ietf-mmusic-rid] Section 10 | | simulcast | [I-D.ietf-mmusic-sdp-simulcast]Section | | | 6.1 | | dtls-id | [I-D.ietf-mmusic-dtls-sdp]Section 4 | - +-----------------------+-------------------------------------------+ + +------------------------+------------------------------------------+ Table 1: SDP ABNF References -Appendix B. Appendix B - - 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. +Appendix B. Change log - If the packet is of type APP, the only routing information - 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. + Note: This section will be removed by RFC Editor before publication. -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: o Examples are now machine-generated for correctness, and use IETF- approved example IP addresses. o Add early transport warmup example, and add missing attributes to existing examples. o Only send "a=rtcp-mux-only" and "a=bundle-only" on new m=