| 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
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]
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 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.
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:
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).
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:
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.
This document extends a=ssrc attribute [RFC5576] by introducing [RFC6236] imageattr enabling specification of multi-resolution simulcast streams for a given media source.
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.
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 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
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].
Multiplexing in RTP can be achieved in several ways as listed:
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.
[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.
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.
TBD
I would like to thanks Cullen Jennings for his inputs and review on the proposed solution.