One document matched: draft-westerlund-mmusic-max-ssrc-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200811" category="std" docName="draft-westerlund-mmusic-max-ssrc-02.txt" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Multiple SSRC Signalling">Multiple Synchronization Sources
(SSRC) in SDP Media Descriptions</title>
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M.W" surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Bo Burman" initials="B.B" surname="Burman">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 13 11</phone>
<email>bo.burman@ericsson.com</email>
</address>
</author>
<author fullname="Fredrik Jansson" initials="F.J" surname="Jansson">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Kista</city>
<region/>
<code>SE-164 80</code>
<country>Sweden</country>
</postal>
<phone>+46 10 719 00 00</phone>
<facsimile/>
<email>fredrik.k.jansson@ericsson.com</email>
<uri/>
</address>
</author>
<date year="2013"/>
<abstract>
<t>This document describes use-cases where endpoints, for a given media
type, use multiple media sources. It also describes how endpoints
normally support media sources, and limitations associated with the
support of multiple sources.</t>
<t>This document also defines two new SDP attributes, "max-send-ssrc"
and "max-recv-ssrc". The attributes allows an entity to, for a given
media description, indicate sending and receiving capabilities of
multiple media sources, based on codec usage .</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An RTP session <xref format="default" pageno="false"
target="RFC3550"/> contains a Synchronization Sources (SSRC) space. This
space can encompass a number of endpoints and network entities, and
associated media streams, within the RTP session. As defined in RFC
3550, within an RTP session, each entity may use zero, one or multiple
SSRCs to indicate a physical media source (e.g. a camera or a
microphone), a conceptual source (e.g. the most active speaker, selected
by an RTP mixer, within a conference), or to identify a receiver that
provides feedback and reports on reception. A given SSRC value is
associated with a physical media source. Multiple SSRC values can be
associated with the same source.</t>
<t>The Session Description Protocol (SDP) <xref format="default"
pageno="false" target="RFC4566"/> describes media streams using media
descriptions (m- lines). Each m- line is normally associated with a
given media type (e.g. audio or video).</t>
<t>Multiple media streams and media sources might be associated with a
single SDP media description. Each media stream will share the
parameters and characteristics (e.g. payload type values and codecs)
that have been indicated in the SDP media description.</t>
<t>This document describes use-cases where endpoints, for a given media
type, use multiple media sources. It also describes how endpoints
normally support media sources, and limitations associated with the
support of multiple sources.</t>
<t>This document also defines two new SDP attributes, "max-send-ssrc"
and "max-recv-ssrc". The attributes allows an entity to, for a given
media description, indicate sending and receiving capabilities of
multiple media sources, based on codec usage .</t>
</section>
<section title="Definitions">
<section title="Requirements Language">
<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 <xref
target="RFC2119"/>.</t>
</section>
<section title="Terminology">
<t>The following terms and abbreviations are used in this
document:</t>
<t><list style="hanging">
<t hangText="Encoding:">A particular encoding is the choice of the
media encoder (codec) that has been used to compress the media,
the fidelity of that encoding through the choice of sampling,
bit-rate and other configuration parameters.</t>
<t hangText="Different encodings:">An encoding is different when
some parameter that characterize the encoding of a particular
media source has been changed. Such changes can be one or more of
the following parameters; codec, codec configuration, bit-rate,
sampling.</t>
<t hangText="Media source:">The source of a stream of data of one
Media Type, It can either be a single media capturing device such
as a video camera, a microphone, or a specific output of a media
production function, such as an audio mixer, or some video editing
function.</t>
<t hangText="Media stream:">Within the scope of this document, a
media stream represents a media flow, associated with a media
source (identified by a SSRC value) and an SDP media description
(m- line).</t>
</list></t>
</section>
</section>
<section title="Multiple Media Stream Support">
<section title="General">
<t>Many applications and systems have been designed to ensure that any
given endpoint only needs to, for a given SDP media description, send
or receive a single media stream, associated with a single source.
Some applications might be able to switch between different SSRC
values, but will still only be able to process media associated with a
single SSRC value at any given time.</t>
<t>Then there is some applications that are designed to use multiple
SSRCs simultaneously. Some send media from multiple media sources, for
example an application which sends video from multiple cameras. Some
RTP extension mechanisms require endpoints to be able to handle
multiple SSRCs. An example is the mechanism for SSRC multiplexed RTP
retransmissions <xref format="default" pageno="false"
target="RFC4588"/>. Multicast applications typically support multiple
media streams, as they might receive media from multiple remote
entities. Some unicast multi-party applications also receive multiple
media sources from a central entity relaying sources from multiple
origins. </t>
<t>NOTE: Even if an endpoint is not used in scenarios where multiple
media streams (SSRCs) are sent and received, according to RFC 3550,
the endpoint need to be able to support cases where the SSRC value
used for a media stream is changed, e.g. due to an SSRC value
collision <xref format="default" pageno="false"
target="RFC3550"/>.</t>
</section>
<section title="Multiple Source Support Limitations">
<t>The theoretical maximum number of sources, for a given RTP session,
is 2^32. However, even if applications, for a given RTP session, are
able to handle multiple media streams simultaneously, entities only
have resources to handle a given number (typically far smaller the
theoretical maximum number) of media streams. The number of supported
media streams might depend on the type of codecs, or codec
configurations, that are used for the media streams. Networks might
also put constrains on the number of media streams that can be
supported.</t>
<t>In environments where endpoints, for a given SDP media description,
have different amount of resources to handle multiple media stream of
handling multiple media streams, network entities (e.g. RTP mixers)
might be used, in order to select, or combine, media streams into a
number of media streams that is supported by the endpoints to which
the media is sent. The policies and algorithms to select and combine
media streams are outside the scope of this document.</t>
</section>
</section>
<section title="SDP max-send-ssrc And max-recv-ssrc Attributes">
<section title="Introduction">
<t>As different applications end entities typically are able to
simultaneously handle a different number of media streams associated
with a given SDP media description, it is necessary for an entity to
be able to declare how many media streams it able to simultaneously
send and receive, and whether the used codecs and codec configurations
have impact on the number of media streams.</t>
<t>This section defines two new media level SDP attributes,
"max-send-ssrc" and "max-recv-ssrc". The attributes are used to, for a
given SDP media description, indicate the multiple stream capabilities
of an entity. The "max-send-ssrc" attribute is used to indicate
simultaneous sending capabilities, and the "max-recv-ssrc" attribute
is used to indicate simultaneous receiving capabilities.</t>
</section>
<section title="Usage">
<t>The SDP attributes are used to describe multiple stream
capabilities based on which codecs or codec configurations are used
for each stream. The attributes allow to describe multiple
alternatives.</t>
<t>Each alternative contains one or more codecs or codec
configurations (indexed using the payload type value which has
describes the codec in the SDP), and for each codec the number of
simultaneous streams the endpoint is able to handle.</t>
<t>For a given alternative, payload type values can be explicitly
listed. It is also possible to use a payload type range, which
includes all payload type values within the range. Alternatively it is
possible to use a wildcard value, which indicates that the indicated
number of SSRCs is independent of which codec is used.</t>
<t>The number of streams that an entity can simultaneous send can be
different from the number it can receive.</t>
</section>
<section title="Syntax">
<t>The syntax for the attributes is in ABNF <xref
target="RFC5234"/>:</t>
<figure>
<artwork><![CDATA[
max-ssrc = "a="( "max-send-ssrc:" / "max-recv-ssrc:" ) alt-list
alt-list = alt-set *(WSP alt-set)
alt-set = "{" alt *("&" alt)) "}"
alt = pt ":" limit
pt = ( pt-list / pt-wildcard )
pt-list = ( pt-value / pt-range ) *(","( pt-value / pt-range ))
pt-value = 1*3DIGIT
pt-range = pt-value "-" pt-value
pt-wildcard = "*"
limit = 1*8DIGIT
; WSP and DIGIT defined in [RFC5234]
]]></artwork>
</figure>
</section>
<section title="Use in Offer/Answer">
<t>An SDP Offerer that supports and uses the mechanism in this
document MUST include the SDP attributes in the initial SDP offer of a
session. If the SDP Answerer also supports and uses the mechanism, the
attributes MUST be included in each subsequent SDP Offer and Answer
during the session.</t>
<t>An SDP Answerer MUST NOT include the SDP attributes in the SDP
Answer unless the associated SDP Offer also contains them.</t>
<t>For sendrecv SDP media descriptions (m- lines), an endpoint that
uses the mechanism described in this document MUST include both the
"max-send-ssrc" and "max-recv-ssrc" attributes in an SDP Offer and
Answer <xref format="default" pageno="false" target="RFC3264"/>, also
for directions in which the endpoint only supports a single SSRC.</t>
<t>For sendonly or recvonly SDP media descriptions, an endpoint MUST
include that attribute which corresponds to the direction attribute.
For information purpose, the endpoint MAY include also the other
attribute.</t>
<t>TODO: Guidance text is needed, which describes how the SDP Answerer
indciates its capabilities in a way so that they match the
capabilities of the SDP Offerer as far as possible.</t>
</section>
</section>
<section title="Examples">
<t>The SDP examples below are not complete. Only the relevant parts are
shown.</t>
<figure>
<artwork><![CDATA[
m=video 49200 RTP/AVP 99
a=rtpmap:99 H264/90000
a=max-send-ssrc:{*:2}
a=max-recv-ssrc:{*:4}]]></artwork>
</figure>
<t>The SDP indicates that the endpoint is able to send 2 simultaneous
SSRCs, and is able to receive 4 simultaneous SSRCs. The wildcarded
payload type value indicates that the indicated capabilities apply for
any of the indicated codecs (only a single one in this example).</t>
<figure>
<artwork><![CDATA[
m=video 50324 RTP/AVP 96 97
a=rtpmap:96 H264/90000
a=rtpmap:97 H263-2000/90000
a=max-recv-ssrc:{96:2&97:3} {96:1&97:4} {97:5}
a=max-send-ssrc:{* 1}]]></artwork>
</figure>
<t>The SDP indicates 3 different receiving capability alternatives. The
first alternative indicates that the endpoint is able to receive at most
2 SSRCs using the H.264 codec (payload type value 96) and 3 SSRCs using
the H.263 codec (payload type value 97). The second alternative
indicates that the endpoint is able to receive 1 SSRC using the H.264
codec and 4 SSRCs using the H.263 codec. The third alternative indicates
that the endpoint is able to receive 5 SSRCs using the H.263 codec. The
SDP indicates that the endpoint is only able to send one SSRC, no matter
which of the indicated codecs are used.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document registers two media level SDP attributes.</t>
<t>TODO: IANA registration template</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The "max-recv-ssrc" and "max-send-ssrc" SDP attributes describe
capabilities of the endpoint that sends the attributes. Knowledge of the
capabilities might be used to trigger different kind of attacks. The
primary security concern is when a malicious man-in-the-middle (MiTM)
modifies the attribute values so that endpoints have wrong information
about the capabilities of the other endpoints. Such modification of the
capabilities might cause bad user experience, or prevent services all
together. For example, if an endpoint has indicated that it is only able
to receive a single media stream, and a MiTM increases that number, the
endpoint might end up receiving more media streams than it is able to
handle.</t>
<t>In order to prevent a MiTM to modify the SDP attributes, it is
RECOMMENDED to use a mechanism that provides authentication and
integrity protection of the SDP.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3264'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.5234'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.4588'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:13 |