--- 1/draft-ietf-mmusic-sdp-simulcast-07.txt 2017-03-13 14:14:38.206753680 -0700 +++ 2/draft-ietf-mmusic-sdp-simulcast-08.txt 2017-03-13 14:14:38.278755394 -0700 @@ -1,21 +1,21 @@ Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Standards Track Ericsson -Expires: August 4, 2017 S. Nandakumar +Expires: September 14, 2017 S. Nandakumar M. Zanaty Cisco - January 31, 2017 + March 13, 2017 Using Simulcast in SDP and RTP Sessions - draft-ietf-mmusic-sdp-simulcast-07 + draft-ietf-mmusic-sdp-simulcast-08 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,21 +31,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 August 4, 2017. + This Internet-Draft will expire on September 14, 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 @@ -53,64 +53,66 @@ 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 5 + 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 6 3.2. Application Specific Media Source Handling . . . . . . . 7 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9 + 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 14 6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 14 6.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 15 - 6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 + 6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 16 6.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 16 6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16 - 6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 + 6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 17 6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 7. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Outgoing from Endpoint with Media Source . . . . . . . . 21 7.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21 7.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 23 7.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24 7.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25 8. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26 9. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 32 - A.1. Modifications Between WG Version -05 and -06 . . . . . . 32 - A.2. Modifications Between WG Version -04 and -05 . . . . . . 32 - A.3. Modifications Between WG Version -03 and -04 . . . . . . 33 - A.4. Modifications Between WG Version -02 and -03 . . . . . . 33 - A.5. Modifications Between WG Version -01 and -02 . . . . . . 33 - A.6. Modifications Between WG Version -00 and -01 . . . . . . 34 - A.7. Modifications Between Individual Version -00 and WG + A.1. Modifications Between WG Version -07 and -08 . . . . . . 32 + A.2. Modifications Between WG Version -06 and -07 . . . . . . 32 + A.3. Modifications Between WG Version -05 and -06 . . . . . . 32 + A.4. Modifications Between WG Version -04 and -05 . . . . . . 33 + A.5. Modifications Between WG Version -03 and -04 . . . . . . 33 + A.6. Modifications Between WG Version -02 and -03 . . . . . . 34 + A.7. Modifications Between WG Version -01 and -02 . . . . . . 34 + A.8. Modifications Between WG Version -00 and -01 . . . . . . 34 + A.9. Modifications Between Individual Version -00 and WG Version -00 . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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 @@ -425,34 +428,34 @@ 6. Detailed Description This section further details the overview above (Section 5). First, formal syntax is provided (Section 6.1), followed by the rest of the SDP attribute definition in Section 6.2. Relating Simulcast Streams (Section 6.5) provides the definition of the RTP/RTCP mechanisms used. The section is concluded with a number of examples. 6.1. Simulcast Attribute - This document defines a new SDP media-level "a=simulcast" attribute - with the following ABNF [RFC5234] syntax: + This document defines a new SDP media-level "a=simulcast" attribute, + with value according to the following ABNF [RFC5234] syntax: - sc-attr = "a=simulcast:" sc-value - sc-value = sc-str-list [SP sc-str-list] - sc-str-list = sc-dir SP sc-alt-list *( ";" sc-alt-list ) - sc-dir = "send" / "recv" + sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] ) + sc-send = "send" SP sc-str-list + sc-recv = "recv" SP sc-str-list + sc-str-list = sc-alt-list *( ";" sc-alt-list ) sc-alt-list = sc-id *( "," sc-id ) sc-id-paused = "~" - sc-id = [sc-id-paused] rid-identifier + sc-id = [sc-id-paused] rid-id ; SP defined in [RFC5234] - ; rid-identifier defined in [I-D.ietf-mmusic-rid] + ; rid-id defined in [I-D.ietf-mmusic-rid] - Figure 1: ABNF for Simulcast + Figure 1: ABNF for Simulcast Value The "a=simulcast" attribute has a parameter in the form of one or two simulcast stream descriptions, each consisting of a direction ("send" or "recv"), followed by a list of one or more simulcast streams. Each simulcast stream consists of one or more alternative simulcast formats. Each simulcast format is identified by a simulcast stream identifier (SCID). The SCID MUST have the form of an RTP stream identifier, as described by RTP Payload Format Restrictions [I-D.ietf-mmusic-rid]. @@ -780,33 +782,32 @@ c=IN IP4 192.0.2.156 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 pt=97 send - a=rid:2 pt=98 send - a=rid:3 pt=97 recv + a=rid:1 send pt=97 + a=rid:2 send pt=98 + a=rid:3 recv pt=97 a=simulcast:send 1;2 recv 3 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Figure 4: Single-Source Simulcast Offer The only thing in the SDP that indicates simulcast capability is the line in the video media description containing the "simulcast" attribute. The included "a=fmtp" and "a=imageattr" parameters indicates that sent simulcast streams can differ in video resolution. - The RTP header extension for RtpStreamId is offered to avoid issues with the initial binding between RTP streams (SSRCs) and the RtpStreamId identifying the simulcast stream and its format. 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. @@ -817,23 +818,23 @@ c=IN IP4 192.0.2.43 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 pt=97 recv - a=rid:2 pt=98 recv - a=rid:3 pt=97 send + a=rid:1 recv pt=97 + a=rid:2 recv pt=98 + a=rid:3 send pt=97 a=simulcast:recv 1;2 send 3 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Figure 5: Single-Source Simulcast Answer Since the server is the simulcast media receiver, it reverses the direction of the "simulcast" and "rid" attribute parameters. 6.6.2. Multi-Source Client @@ -1156,21 +1157,21 @@ Simulcast is in this memo defined as the act of sending multiple alternative encoded streams of the same underlying media source. When transmitting multiple independent streams that originate from the same source, it could potentially be done in several different ways using RTP. A general discussion on considerations for use of the different RTP multiplexing alternatives can be found in Guidelines for Multiplexing in RTP [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and clarification on how to handle multiple streams in an RTP session can - be found in [I-D.ietf-avtcore-rtp-multi-stream]. + be found in [RFC8108]. The network aspects that are relevant for simulcast are: Quality of Service: When using simulcast it might be of interest to prioritize a particular simulcast stream, rather than applying equal treatment to all streams. For example, lower bit-rate streams may be prioritized over higher bit-rate streams to minimize congestion or packet losses in the low bit-rate streams. Thus, there is a benefit to use a simulcast solution with good QoS support. @@ -1227,21 +1228,21 @@ Contact name, email: IETF, contacted via mmusic@ietf.org, or a successor address designated by IESG Attribute name: simulcast Long-form attribute name: Simulcast stream description Charset dependent: No - Attribute value: See Section 6.1 of RFC XXXX. + Attribute value: sc-value; see Section 6.1 of RFC XXXX. Purpose: Signals simulcast capability for a set of RTP streams MUX category: NORMAL Note to RFC Editor: Please replace "RFC XXXX" with the assigned number of this RFC. 11. Security Considerations @@ -1272,37 +1273,37 @@ Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have contributed with important material to the first versions of this document. Robert Hansen and Cullen Jennings, from Cisco, Peter Thatcher, from Google, and Adam Roach, from Mozilla, contributed significantly to subsequent versions. 13. Acknowledgements The authors would like to thank Bernard Aboba, Thomas Belling, Roni - Even, and Adam Roach for the feedback they provided during the - development of this document. + Even, Adam Roach, Inaki Baz Castillo, and Paul Kyzivat for the + feedback they provided during the development of this document. 14. References 14.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [I-D.ietf-mmusic-rid] Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., Roach, A., and B. Campen, "RTP Payload Format - Restrictions", draft-ietf-mmusic-rid-08 (work in - progress), October 2016. + Restrictions", draft-ietf-mmusic-rid-09 (work in + progress), February 2017. [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-36 (work in progress), October 2016. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 @@ -1332,26 +1333,20 @@ February 2016, . 14.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft-ietf-avtcore- multiplex-guidelines-03 (work in progress), October 2014. - [I-D.ietf-avtcore-rtp-multi-stream] - Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, - "Sending Multiple RTP Streams in a Single RTP Session", - draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), - December 2015. - [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, . @@ -1427,43 +1422,80 @@ [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . + [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, + "Sending Multiple RTP Streams in a Single RTP Session", + RFC 8108, DOI 10.17487/RFC8108, March 2017, + . + Appendix A. Changes From Earlier Versions NOTE TO RFC EDITOR: Please remove this section prior to publication. -A.1. Modifications Between WG Version -05 and -06 +A.1. 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. + +A.2. 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. + +A.3. 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. -A.2. Modifications Between WG Version -04 and -05 +A.4. 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 @@ -1472,86 +1504,85 @@ 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. -A.3. Modifications Between WG Version -03 and -04 +A.5. 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. -A.4. Modifications Between WG Version -02 and -03 +A.6. 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. -A.5. Modifications Between WG Version -01 and -02 +A.7. 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. -A.6. Modifications Between WG Version -00 and -01 +A.8. Modifications Between WG Version -00 and -01 o No changes. Only preventing expiry. -A.7. Modifications Between Individual Version -00 and WG Version -00 +A.9. 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