Internet DRAFT - draft-nandakumar-mmusic-rtcweb-grouping
draft-nandakumar-mmusic-rtcweb-grouping
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]
