One document matched: draft-nandakumar-mmusic-rtcweb-grouping-00.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-nandakumar-mmusic-rtcweb-grouping-00"
submissionType="IETF" xml:lang="en">
<front>
<title abbrev="SSRC Group Simulcast">
SSRC Group Based Simulcast Signaling
</title>
<author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>snandaku@cisco.com</email>
</address>
</author>
<date year="2013" month="July" day="14" />
<area>Transport</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>RTP</keyword>
<keyword>SDP</keyword>
<keyword>Multiplexing</keyword>
<keyword>RTCWEB</keyword>
<keyword>WEB</keyword>
<keyword>Browser</keyword>
<abstract>
<t>
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 <xref target="RFC5576"/>
</t>
</abstract>
</front>
<middle>
<section title="Terminology" toc="default">
<t>
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 <xref target="RFC2119" pageno="false"
format="default"/>.
</t>
<t>
Capture Device:
The physical source of stream of media data of one type such as
camera or microphone.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Media Stream:
Media from a Media Source is encoded and packetized to produce one or
more Media Streams representing a sequence of RTP packets.
</t>
<t>
RTP Source:
Same as Media Stream.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Introduction" toc="default">
<t>
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.
</t>
<t>
<xref target="I-D.westerlund-avtcore-rtp-simulcast"/> describes
different encodings of a media content to be combination of the following:
<list style="symbols">
<t> Bit-rate: The difference is the amount of bits spent to encode the
media thus giving different quality. </t>
<t> 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. </t>
<t> 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. </t>
</list>
</t>
<t>
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).
</t>
</section>
<section title="Solution Overview" toc="default">
<t>
The source-attribute specification <xref target="RFC5576"/> provides mechanisms
describing Real-Time Protocol (RTP) <xref target="RFC3550"/> sources,
identified by their synchronization source (SSRC) identifier,
in the Session Description Protocol (SDP) <xref target="RFC4566"/>,
to associate attributes with these sources, and to express relationships
among individual sources.
</t>
<t>
To describe and negotiate simulcast streams with in SDP for a given media source,
the following framework is been proposed:
<list style="symbols">
<t>
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.
</t>
<t>
Each simulcast media stream is marked with an a=ssrc attribute to correlate
it with its RTP Packets
</t>
<t>
A new SSRC Grouping semantic is proposed to express the simulcast
relationship between the media streams.
</t>
<t>
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.
</t>
<t>
For multi-resolution simulcast, <xref target="RFC6236"/> imageattr is
proposed for a=ssrc attribute line, to specify send multiple resolutions,
for example.
</t>
<t>
For the receiver control of selecting the simulcast stream to receive, the mechanisms
defined in <xref target="I-D.lennox-mmusic-sdp-source-selection"/> is proposed.
</t>
<t>
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 <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>
is in operation.
</t>
</list>
</t>
<t>
Providing explicit resolutions on a per-SSRC basis for SIMULCAST groupings
allows an intermediary (such as a Media Translator <xref target="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.
</t>
</section>
<section title="imageattr for a=ssrc attribute" toc="default">
<t>
This document extends a=ssrc attribute <xref target="RFC5576"/> by
introducing <xref target="RFC6236"/> imageattr enabling specification of
multi-resolution simulcast streams for a given media source.
</t>
</section>
<section title="The SIMUCAST ssrc-group attribute" toc="default">
<t>
This document also extends <xref target="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.
</t>
</section>
<section title="SDP Examples" toc="default">
<t>
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.
</t>
<figure title="Figure 1">
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>
The SDP example in Figure 2, advertises simulcast of 2 video sources
corresponding to 2 cameras, each at 2 resolutions.
</t>
<figure title="Figure 2">
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
<section title="Offer/Answer Consideration">
<t>
The Offer/Answer model for this specification adheres to the model as applicable
to Source-Specific Media SDP attributes <xref target="RFC5576"/> and its extensions
<xref target="I-D.lennox-mmusic-sdp-source-selection"/>.
</t>
</section>
<section anchor="simulmux" title="Simulcast and Multiplexing ">
<t>
Multiplexing in RTP can be achieved in several ways as listed:
<list style="symbol">
<t> Payload Type based Multiplexing </t>
<t> Media Stream Multiplexing based on SSRC in a Single RTP Session </t>
<t> RTP Session Multiplexing over a single Media Transport.</t>
</list>
</t>
<t>
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
<xref target="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.
</t>
</section>
<section anchor="simultopo" title="Simulcast under Multicast RTP Topology ">
<t>
<xref target="RFC5117"/> describes several underlying network topologies
supported by RTP. In this section the operation of the solution under
multicast topologies is analyzed.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
<xref target="I-D.lennox-mmusic-sdp-source-selection"/> enables receiver
control to selectively choose the simulcast streams of interest.
</t>
</section>
<section title="IANA Considerations" toc="default">
<t>
TBD
</t>
</section>
<section anchor="sec-acks" title="Acknowledgements" toc="default">
<t>
I would like to thanks Cullen Jennings for his inputs and review on the proposed
solution.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5888"?>
<?rfc include="reference.RFC.5576"?>
<?rfc include="reference.RFC.6236"?>
<?rfc include="reference.RFC.5117"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.I-D.lennox-mmusic-sdp-source-selection"?>
<?rfc include="reference.I-D.westerlund-avtcore-rtp-simulcast"?>
<?rfc include="reference.I-D.lennox-raiarea-rtp-grouping-taxonomy"?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-bundle-negotiation"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:52 |