MMUSIC Working Group S. Nandakumar Internet-Draft Cisco Intended status: Standards Track July 15, 2013 Expires: January 16, 2014 SSRC Group Based Simulcast Signaling draft-nandakumar-mmusic-rtcweb-grouping-00 Abstract In some applications it may be necessary to send multiple media encodings corresponding to a media source with in independent RTP media streams. This is called Simulcast. This document discusses a framework for describing simulcast media streams in SDP and also defines semantics to express relationship amongst them. The semantics defined in this document are to be used with the source specific grouping framework defined in the [RFC5576] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 January 16, 2014. Copyright Notice Copyright (c) 2013 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 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 Nandakumar Expires January 16, 2014 [Page 1] Internet-Draft SSRC Group Simulcast July 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. imageattr for a=ssrc attribute . . . . . . . . . . . . . . . 4 5. The SIMUCAST ssrc-group attribute . . . . . . . . . . . . . . 5 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Offer/Answer Consideration . . . . . . . . . . . . . . . . . 6 8. Simulcast and Multiplexing . . . . . . . . . . . . . . . . . 6 9. Simulcast under Multicast RTP Topology . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Capture Device: The physical source of stream of media data of one type such as camera or microphone. Media Source: A Media Source logically defines the source of a raw stream of media data as generated either by a single capture device or by a conceptual source. A Media Source represents an Audio Source or a Video Source. Media Encoding: A particular encoding applied to the media data from a media source through the choice of sampling, bit-rate and other codec configuration parameters. Media Stream: Media from a Media Source is encoded and packetized to produce one or more Media Streams representing a sequence of RTP packets. RTP Source: Same as Media Stream. RTP Session: An RTP session is an association among a group of participants communicating with RTP. It is a group communications channel which can potentially carry a number of Media Streams. Within an RTP session, every participant finds out meta-data and control information (over RTCP) about all the Media Streams in the Nandakumar Expires January 16, 2014 [Page 2] Internet-Draft SSRC Group Simulcast July 2013 RTP session. The bandwidth of the RTCP control channel is shared within an RTP Session. Media Transport: A Media Transport defines an end-to-end transport association for carrying one or more RTP Sessions. The combination of a network address and port uniquely identifies such a transport association, for example an IP address and a UDP port. 2. Introduction Simulcast refers to taking media from a single media capture (e.g., a camera), and encoding it multiple times at different resolutions and / or frame rates. For example, a device with a single HD camera may send one version of the video at full HD resolution, and a second version encoded at a low resolution. This would allow a video conferencing bridge to be able to send the high resolution copy to some destination and low resolution copy to other destinations without having to recode the video at the conference bridge. [I-D.westerlund-avtcore-rtp-simulcast] describes different encodings of a media content to be combination of the following: o Bit-rate: The difference is the amount of bits spent to encode the media thus giving different quality. o Codec: Different media codecs are used to ensure that different receivers that do not have a common set of decoders can decode at least one of the versions. This can include codec configuration options that are not compatible, like video encoder profiles, or the capability of receiving the transport packetization. o Sampling: Different sampling of media, in spatial as well as in temporal domain, may be used to suit different rendering capabilities or needs at the receiving endpoints, as well as a method to achieve different bit-rates. For video streams, spatial sampling affects image resolution and temporal sampling affects video frame rate. For audio, spatial sampling relates to the number of audio channels and temporal sampling affects audio bandwidth. Obviously, a difference in sampling may result in difference in bit-rate. In any application that needs to send multiple encodings, there is a potential need for simulcast. The purpose of this document is to discuss suitable signaling solution in SDP for describing and negotiating simulcast streams, within the context of the Real Time Transport Protocol(RTP). Nandakumar Expires January 16, 2014 [Page 3] Internet-Draft SSRC Group Simulcast July 2013 3. Solution Overview The source-attribute specification [RFC5576] provides mechanisms describing Real-Time Protocol (RTP) [RFC3550] sources, identified by their synchronization source (SSRC) identifier, in the Session Description Protocol (SDP) [RFC4566], to associate attributes with these sources, and to express relationships among individual sources. To describe and negotiate simulcast streams with in SDP for a given media source, the following framework is been proposed: o Each physical media source is represented by its own unique m-line. This is a strict one-to-one mapping; a single media source device cannot be spread across several m-lines, nor may a single m-line represent multiple media sources. o Each simulcast media stream is marked with an a=ssrc attribute to correlate it with its RTP Packets o A new SSRC Grouping semantic is proposed to express the simulcast relationship between the media streams. o In the absence of the above grouping semantic, multiple SSRCs in a single m-line are interpreted as alternate sources for the same media source. o For multi-resolution simulcast, [RFC6236] imageattr is proposed for a=ssrc attribute line, to specify send multiple resolutions, for example. o For the receiver control of selecting the simulcast stream to receive, the mechanisms defined in [I-D.lennox-mmusic-sdp-source-selection] is proposed. o When multicast topology is used to distribute RTP/RTCP packets, having same multicast address across all the m=lines is proposed when multiplexing framework such as BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] is in operation. Providing explicit resolutions on a per-SSRC basis for SIMULCAST groupings allows an intermediary (such as a Media Translator [RFC5117]) to be able to select an appropriate SIMULCAST layer without inspecting the media stream, which could otherwise require decrypting and possibly partially decoding media packets. 4. imageattr for a=ssrc attribute Nandakumar Expires January 16, 2014 [Page 4] Internet-Draft SSRC Group Simulcast July 2013 This document extends a=ssrc attribute [RFC5576] by introducing [RFC6236] imageattr enabling specification of multi-resolution simulcast streams for a given media source. 5. The SIMUCAST ssrc-group attribute This document also extends [RFC5576] SSRC Grouping Framework semantics (a=ssrc-group) to indicate relationship between the simulcast media streams for a given media source. A semantic called "SIMULCAST" is defined to achieve this purpose. 6. SDP Examples The example SDP in Figure 1 shows simulcast encoding with the use of different codec-specific parameters using two different payload types for a camera source. It also describes different resolutions for each encoded simulcast media stream. The "SIMULCAST" SSRC grouping semantic is included to signal the relationship. m=video 62537 RTP/SAVPF 96 97 a=rtpmap:96 VP8/90000 a=rtpmap:97 VP8/90000 a=sendrecv a=ssrc:29154 a=imageattr:96 [x=1280,y=720] //Stream 1 a=fmtp:96 max-fr=30;max-fs=3600 a=ssrc:47182 a=imageattr:97 [x=640,y=360] //Stream 2 a=fmtp:97 max-fr=15;max-fs=880 a=ssrc-group:SIMULCAST 29154 47182 Figure 1 The SDP example in Figure 2, advertises simulcast of 2 video sources corresponding to 2 cameras, each at 2 resolutions. m=video 62537 RTP/SAVPF 96 97 //Camera 1 a=rtpmap:96 VP8/90000 a=rtpmap:97 VP8/90000 a=sendrecv a=ssrc:11111 a=ssrc:22222 a=imageattr:96 [x=1280,y=720] a=fmtp:96 max-fr=30;max-fs=3600 a=imageattr:97 [x=640,y=360] a=fmtp:97 max-fr=15;max-fs=880 a=ssrc-group:SIMULCAST 29154 47182 Nandakumar Expires January 16, 2014 [Page 5] Internet-Draft SSRC Group Simulcast July 2013 m=video 54890 RTP/SAVPF 96 97 //Camera 2 a=rtpmap:96 H264/90000 a=rtpmap:97 H264/90000 a=sendrecv a=ssrc:33333 a=ssrc:44444 a=fmtp:96 profile-level-id=4d0028;packetization-mode=1;max-fr=30 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1;max-fr=15 a=ssrc-group:SIMULCAST 33333 44444 Figure 2 7. Offer/Answer Consideration The Offer/Answer model for this specification adheres to the model as applicable to Source-Specific Media SDP attributes [RFC5576] and its extensions [I-D.lennox-mmusic-sdp-source-selection]. 8. Simulcast and Multiplexing Multiplexing in RTP can be achieved in several ways as listed: Payload Type based Multiplexing Media Stream Multiplexing based on SSRC in a Single RTP Session RTP Session Multiplexing over a single Media Transport. The proposed solution in this document assumes Media Stream Multiplexing to transport the simulcast encodings from several media sources with in a single RTP Session,whenever possible. Such a solution can be envisioned by the usage of multiplexing frameworks, such as, BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]. In the absence of such a framework, each media source gets its own RTP Session with its associated simulcast encodings multiplexed based on their respective SSRCs. 9. Simulcast under Multicast RTP Topology [RFC5117] describes several underlying network topologies supported by RTP. In this section the operation of the solution under multicast topologies is analyzed. The proposed solution enables right behavior for RTCP reporting across the members of the group, since all the sources and their simulcast streams form a single RTP Session under the BUNDLE multiplexing framework. Nandakumar Expires January 16, 2014 [Page 6] Internet-Draft SSRC Group Simulcast July 2013 In the scenarios where using a single 5-tuple for all the media sources is not possible, carrying each source with its simulcast encodings in its own RTP Session ensures correct behavior. Allowing media sources to send different simulcast encodings to different multicast group addresses is not directly enabled within the solution proposed. Such a situation might arise to enable the receivers to selectively choose the multicast groups based on their receiving capabilities or interests. However, the mechanisms defined in [I-D.lennox-mmusic-sdp-source-selection] enables receiver control to selectively choose the simulcast streams of interest. 10. IANA Considerations TBD 11. Acknowledgements I would like to thanks Cullen Jennings for his inputs and review on the proposed solution. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, May 2011. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. Nandakumar Expires January 16, 2014 [Page 7] Internet-Draft SSRC Group Simulcast July 2013 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [I-D.lennox-mmusic-sdp-source-selection] Lennox, J. and H. Schulzrinne, "Mechanisms for Media Source Selection in the Session Description Protocol (SDP)", draft-lennox-mmusic-sdp-source-selection-05 (work in progress), October 2012. [I-D.westerlund-avtcore-rtp-simulcast] Westerlund, M., Lindqvist, M., and F. Jansson, "Using Simulcast in RTP Sessions", draft-westerlund-avtcore-rtp- simulcast-02 (work in progress), February 2013. [I-D.lennox-raiarea-rtp-grouping-taxonomy] Lennox, J. and K. Gross, "A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", draft-lennox-raiarea-rtp-grouping-taxonomy-00 (work in progress), February 2013. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- bundle-negotiation-04 (work in progress), June 2013. Author's Address Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Nandakumar Expires January 16, 2014 [Page 8]