--- 1/draft-ietf-mmusic-sdp-simulcast-13.txt 2019-03-05 01:13:13.996299892 -0800 +++ 2/draft-ietf-mmusic-sdp-simulcast-14.txt 2019-03-05 01:13:14.080301932 -0800 @@ -1,21 +1,21 @@ Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Standards Track Ericsson -Expires: December 29, 2018 S. Nandakumar +Expires: September 6, 2019 S. Nandakumar M. Zanaty Cisco - June 27, 2018 + March 5, 2019 Using Simulcast in SDP and RTP Sessions - draft-ietf-mmusic-sdp-simulcast-13 + draft-ietf-mmusic-sdp-simulcast-14 Abstract In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different @@ -31,25 +31,25 @@ 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 https://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 December 29, 2018. + This Internet-Draft will expire on September 6, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -91,34 +91,35 @@ 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 35 - B.1. Modifications Between WG Version -12 and -13 . . . . . . 35 - B.2. Modifications Between WG Version -11 and -12 . . . . . . 36 - B.3. Modifications Between WG Version -10 and -11 . . . . . . 36 - B.4. Modifications Between WG Version -09 and -10 . . . . . . 37 - B.5. Modifications Between WG Version -08 and -09 . . . . . . 37 - B.6. Modifications Between WG Version -07 and -08 . . . . . . 37 - B.7. Modifications Between WG Version -06 and -07 . . . . . . 38 - B.8. Modifications Between WG Version -05 and -06 . . . . . . 38 - B.9. Modifications Between WG Version -04 and -05 . . . . . . 38 - B.10. Modifications Between WG Version -03 and -04 . . . . . . 39 - B.11. Modifications Between WG Version -02 and -03 . . . . . . 39 - B.12. Modifications Between WG Version -01 and -02 . . . . . . 40 - B.13. Modifications Between WG Version -00 and -01 . . . . . . 40 - B.14. Modifications Between Individual Version -00 and WG + B.1. Modifications Between WG Version -13 and -14 . . . . . . 35 + B.2. Modifications Between WG Version -12 and -13 . . . . . . 36 + B.3. Modifications Between WG Version -11 and -12 . . . . . . 36 + B.4. Modifications Between WG Version -10 and -11 . . . . . . 36 + B.5. Modifications Between WG Version -09 and -10 . . . . . . 37 + B.6. Modifications Between WG Version -08 and -09 . . . . . . 37 + B.7. Modifications Between WG Version -07 and -08 . . . . . . 37 + B.8. Modifications Between WG Version -06 and -07 . . . . . . 38 + B.9. Modifications Between WG Version -05 and -06 . . . . . . 38 + B.10. Modifications Between WG Version -04 and -05 . . . . . . 38 + B.11. Modifications Between WG Version -03 and -04 . . . . . . 39 + B.12. Modifications Between WG Version -02 and -03 . . . . . . 39 + B.13. Modifications Between WG Version -01 and -02 . . . . . . 40 + B.14. Modifications Between WG Version -00 and -01 . . . . . . 40 + B.15. Modifications Between Individual Version -00 and WG Version -00 . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Most of today's multiparty video conference solutions make use of centralized servers to reduce the bandwidth and CPU consumption in the endpoints. Those servers receive RTP streams from each participant and send some suitable set of possibly modified RTP streams to the rest of the participants, which usually have @@ -769,22 +770,22 @@ a simulcast of 2 video resolutions and frame rates: HD 1280x720p 30fps and thumbnail 320x180p 15fps. This is defined below using the "imageattr" [RFC6236]. In this example, only the "pt" "a=rid" parameter is used, effectively achieving a 1:1 mapping between RtpStreamId and media formats (RTP payload types), to describe simulcast stream formats. Alice's Offer: v=0 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 s=Simulcast Enabled Client - t=0 0 c=IN IP4 192.0.2.156 + t=0 0 m=audio 49200 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49300 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 send pt=97 @@ -805,22 +806,22 @@ The Answer from the server indicates that it too is simulcast capable. Should it not have been simulcast capable, the "a=simulcast" line would not have been present and communication would have started with the media negotiated in the SDP. Also the usage of the RtpStreamId RTP header extension is accepted. v=0 o=server 823479283 1209384938 IN IP4 192.0.2.2 s=Answer to Simulcast Enabled Client - t=0 0 c=IN IP4 192.0.2.43 + t=0 0 m=audio 49672 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49674 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 recv pt=97 @@ -865,22 +866,22 @@ of both BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and "a=rid" [I-D.ietf-mmusic-rid] recommends using the RTP header extension [RFC8285] for carrying these RTP stream identification fields, which is consequently also included in the SDP. Note also that for "a=rid", the corresponding RtpStreamId SDES attribute RTP header extension is named rtp-stream-id [I-D.ietf-avtext-rid]. v=0 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d s=Offer from Simulcast Enabled Multi-Source Client - t=0 0 c=IN IP6 2001:db8::c000:27d + t=0 0 a=group:BUNDLE foo bar zen m=audio 49200 RTP/AVP 99 a=mid:foo a=rtpmap:99 G722/8000 m=video 49600 RTP/AVPF 100 101 103 a=mid:bar a=rtpmap:100 H264-SVC/90000 a=rtpmap:101 H264/90000 a=rtpmap:103 VP8/90000 a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \ @@ -935,22 +936,22 @@ The video source is offered to be sent as two simulcast streams, both with two alternative simulcast formats. Redundancy and repair are offered in the form of both Flexible FEC and RTP Retransmission. The Flexible FEC is not bound to any particular RTP streams and is therefore possible to use across all RTP streams that are being sent as part of this media description. v=0 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d s=Offer from Simulcast Enabled Client using Redundancy - t=0 0 c=IN IP6 2001:db8::c000:27d + t=0 0 a=group:BUNDLE foo bar m=audio 49200 RTP/AVP 97 98 99 100 101 102 a=mid:foo a=rtpmap:97 G711/8000 a=rtpmap:98 LPC/8000 a=rtpmap:99 OPUS/48000/1 a=rtpmap:100 RED/8000/1 a=rtpmap:101 CN/8000 a=rtpmap:102 telephone-event/8000 a=fmtp:99 useinbandfec=1;usedtx=0 @@ -1368,21 +1369,21 @@ rid-09 (work in progress), October 2016. [I-D.ietf-mmusic-rid] Roach, A., "RTP Payload Format Restrictions", draft-ietf- mmusic-rid-15 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- - negotiation-52 (work in progress), May 2018. + negotiation-54 (work in progress), December 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1410,30 +1411,30 @@ February 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., - Even, R., and H. Zheng, "Guidelines for using the - Multiplexing Features of RTP to Support Multiple Media - Streams", draft-ietf-avtcore-multiplex-guidelines-05 (work - in progress), October 2017. + and R. Even, "Guidelines for using the Multiplexing + Features of RTP to Support Multiple Media Streams", draft- + ietf-avtcore-multiplex-guidelines-08 (work in progress), + December 2018. [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction - (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in - progress), March 2018. + (FEC)", draft-ietf-payload-flexible-fec-scheme-17 (work in + progress), February 2019. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, @@ -1584,81 +1585,85 @@ REQ-6.1: Interworking with non-simulcast legacy clients using a single media source per media type. REQ-6.2: WebRTC environment with a single media source per SDP media description. Appendix B. Changes From Earlier Versions NOTE TO RFC EDITOR: Please remove this section prior to publication. -B.1. Modifications Between WG Version -12 and -13 +B.1. Modifications Between WG Version -13 and -14 + + o c= and t= line order corrected in SDP examples + +B.2. Modifications Between WG Version -12 and -13 o Examples corrected to follow RID ABNF o Example Figure 7 now comments on priority for second media source. o Clarified a SHOULD limitation. o Added urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id in examples with RTX. o ABNF now uses RFC 7405 to indicate case sensitivity o Various minor editorials and nits. -B.2. Modifications Between WG Version -11 and -12 +B.3. Modifications Between WG Version -11 and -12 o Modified Normative statement regarding RTP stream duplication in Section 5.2. o Clarified assumption about use of congestion control by applications. o Changed to use RFC 8174 boilerplate instead of RFC 2119. o Clarified explanation of syntax for simulcast attribute in Section 4. o Editorial clarification in Section 5.2 and 5.3.2. o Various minor editorials and nits. -B.3. Modifications Between WG Version -10 and -11 +B.4. Modifications Between WG Version -10 and -11 o Added new SDP example section on Simulcast and Redundancy, including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft- ietf-payload-flexible-fec-scheme). o Removed restriction that "related" payload formats in an RTP stream (such as CN and DTMF) must not have their own rid-id, since there is no reason to forbid this and corresponding clarification is made in draft-ietf-mmusic-rid. o Removed any mention of source-specific signaling and the reference to RFC5576, since draft-ietf-mmusic-rid is not defined for source- specific signaling. o Changed some SDP examples to use a=rid restrictions instead of a=imageattr. o Changed reference from the obsoleted RFC 5285 to RFC 8285. -B.4. Modifications Between WG Version -09 and -10 +B.5. Modifications Between WG Version -09 and -10 o Amended overview section with a bit more explanation on the examples, and added an rid-id alternative for one of the streams. o Removed SCID also from the Terminology section, which was forgotten in -09 when changing SCID to rid-id. -B.5. Modifications Between WG Version -08 and -09 +B.6. Modifications Between WG Version -08 and -09 o Changed SCID to rid-id, to align with ietf-draft-mmusic-rid naming. o Changed Overview to be based on examples and shortened it. o Changed semantics of initially paused rid-id in modified SDP offers from requiring it to follow actual RFC 7728 pause state to an informational offerer's opinion at the time of offer creation, not in any way overriding or amending RFC 7728 signaling. @@ -1668,71 +1673,71 @@ most one "a=simulcast" line is included. o Clarified with a note that, for the case it is clear from the SDP that RTP PT uniquely maps to RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. o Moved Section 4 Requirements to become Appendix A. o Editorial corrections and clarifications. -B.6. Modifications Between WG Version -07 and -08 +B.7. Modifications Between WG Version -07 and -08 o Correcting syntax of SDP examples in section 6.6.1, as found by Inaki Baz Castillo. o Changing ABNF to only define the sc-value, not the SDP attribute itself, as suggested by Paul Kyzivat. o Changing I-D reference to newly published RFC 8108. o Adding list of modifications between -06 and -07. -B.7. Modifications Between WG Version -06 and -07 +B.8. Modifications Between WG Version -06 and -07 o A scope clarification, as result of the discussion with Roni Even. o A reformulation of the identification requirements for simulcast stream. o Correcting the statement related to source specific signalling (RFC 5576) to address Roni Even's comment. o Update of the last paragraph in Section 6.2 regarding simulcast stream differences as well as forbidding multiple instances of the same SCID within a single a=simulcast line. o Removal of note in Section 6.4 as result of issue raised by Roni Even. o Use of "m=" has been changed to media description and a few other editorial improvements and clarifications. -B.8. Modifications Between WG Version -05 and -06 +B.9. Modifications Between WG Version -05 and -06 o Added section on RTP Aspects o Added a requirement (5-4) on that capability exchange must be capable of handling multi RTP stream cases. o Added extmap attribute also on first signalling example as it is a recommended to use mechanism. o Clarified the definition of the simulcast attribute and how simulcast streams relates to simulcast formats and SCIDs. o Updated References list and moved around some references between informative and normative categories. o Editorial improvements and corrections. -B.9. Modifications Between WG Version -04 and -05 +B.10. Modifications Between WG Version -04 and -05 o Aligned with recent changes in draft-ietf-mmusic-rid and draft- ietf-avtext-rid. o Modified the SDP offer/answer section to follow the generally accepted structure, also adding a brief text on modifying the session that is aligned with draft-ietf-mmusic-rid. o Improved text around simulcast stream identification (as opposed to the simulcast stream itself) to consistently use the acronym @@ -1741,98 +1746,98 @@ o Changed references for RTP-level pause/resume and VP8 payload format that are now published as RFC. o Improved IANA registration text. o Removed unused reference to draft-ietf-payload-flexible-fec- scheme. o Editorial improvements and corrections. -B.10. Modifications Between WG Version -03 and -04 +B.11. Modifications Between WG Version -03 and -04 o Changed to only use RID identification, as was consensus during IETF 94. o ABNF improvements. o Clarified offer-answer rules for initially paused streams. o Changed references for RTP topologies and RTP taxonomy documents that are now published as RFC. o Added reference to the new RID draft in AVTEXT. o Re-structured section 6 to provide an easy reference by the updated IANA section. o Added a sub-section 7.1 with a discussion of bitrate adaptation. o Editorial improvements. -B.11. Modifications Between WG Version -02 and -03 +B.12. Modifications Between WG Version -02 and -03 o Removed text on multicast / broadcast from use cases, since it is not supported by the solution. o Removed explicit references to unified plan draft. o Added possibility to initiate simulcast streams in paused mode. o Enabled an offerer to offer multiple stream identification (pt or rid) methods and have the answerer choose which to use. o Added a preference indication also in send direction offers. o Added a section on limitations of the current proposal, including identification method specific limitations. -B.12. Modifications Between WG Version -01 and -02 +B.13. Modifications Between WG Version -01 and -02 o Relying on the new RID solution for codec constraints and configuration identification. This has resulted in changes in syntax to identify if pt or RID is used to describe the simulcast stream. o Renamed simulcast version and simulcast version alternative to simulcast stream and simulcast format respectively, and improved definitions for them. o Clarification that it is possible to switch between simulcast version alternatives, but that only a single one be used at any point in time. o Changed the definition so that ordering of simulcast formats for a specific simulcast stream do have a preference order. -B.13. Modifications Between WG Version -00 and -01 +B.14. Modifications Between WG Version -00 and -01 o No changes. Only preventing expiry. -B.14. Modifications Between Individual Version -00 and WG Version -00 +B.15. Modifications Between Individual Version -00 and WG Version -00 o Added this appendix. Authors' Addresses Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Stockholm Sweden Email: bo.burman@ericsson.com Magnus Westerlund Ericsson - Farogatan 2 - SE-164 80 Stockholm + Torshamnsgatan 23 + SE-164 83 Stockholm Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA