Internet DRAFT - draft-westerlund-mmusic-max-ssrc
draft-westerlund-mmusic-max-ssrc
Network Working Group C. Holmberg
Internet-Draft M. Westerlund
Intended status: Standards Track B. Burman
Expires: March 23, 2014 F. Jansson
Ericsson
September 19, 2013
Multiple Synchronization Sources (SSRC) in SDP Media Descriptions
draft-westerlund-mmusic-max-ssrc-02.txt
Abstract
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.
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 .
Status of This Memo
This Internet-Draft is submitted to IETF 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 March 23, 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
Holmberg, et al. Expires March 23, 2014 [Page 1]
Internet-Draft Multiple SSRC Signalling September 2013
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multiple Media Stream Support . . . . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Multiple Source Support Limitations . . . . . . . . . . . 4
4. SDP max-send-ssrc And max-recv-ssrc Attributes . . . . . . . 4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Use in Offer/Answer . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
An RTP session [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.
The Session Description Protocol (SDP) [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).
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.
Holmberg, et al. Expires March 23, 2014 [Page 2]
Internet-Draft Multiple SSRC Signalling September 2013
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.
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 .
2. Definitions
2.1. Requirements Language
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 [RFC2119].
2.2. Terminology
The following terms and abbreviations are used in this document:
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.
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.
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.
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).
3. Multiple Media Stream Support
3.1. General
Many applications and systems have been designed to ensure that any
given endpoint only needs to, for a given SDP media description, send
Holmberg, et al. Expires March 23, 2014 [Page 3]
Internet-Draft Multiple SSRC Signalling September 2013
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.
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 [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.
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 [RFC3550].
3.2. Multiple Source Support Limitations
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.
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.
4. SDP max-send-ssrc And max-recv-ssrc Attributes
4.1. Introduction
As different applications end entities typically are able to
simultaneously handle a different number of media streams associated
Holmberg, et al. Expires March 23, 2014 [Page 4]
Internet-Draft Multiple SSRC Signalling September 2013
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.
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.
4.2. Usage
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.
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.
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.
The number of streams that an entity can simultaneous send can be
different from the number it can receive.
4.3. Syntax
The syntax for the attributes is in ABNF [RFC5234]:
Holmberg, et al. Expires March 23, 2014 [Page 5]
Internet-Draft Multiple SSRC Signalling September 2013
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]
4.4. Use in Offer/Answer
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.
An SDP Answerer MUST NOT include the SDP attributes in the SDP Answer
unless the associated SDP Offer also contains them.
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
[RFC3264], also for directions in which the endpoint only supports a
single SSRC.
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.
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.
5. Examples
The SDP examples below are not complete. Only the relevant parts are
shown.
m=video 49200 RTP/AVP 99
a=rtpmap:99 H264/90000
a=max-send-ssrc:{*:2}
Holmberg, et al. Expires March 23, 2014 [Page 6]
Internet-Draft Multiple SSRC Signalling September 2013
a=max-recv-ssrc:{*:4}
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).
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}
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.
6. IANA Considerations
This document registers two media level SDP attributes.
TODO: IANA registration template
7. Security Considerations
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.
Holmberg, et al. Expires March 23, 2014 [Page 7]
Internet-Draft Multiple SSRC Signalling September 2013
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.
8. References
8.1. 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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg, et al. Expires March 23, 2014 [Page 8]
Internet-Draft Multiple SSRC Signalling September 2013
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Bo Burman
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 13 11
Email: bo.burman@ericsson.com
Fredrik Jansson
Ericsson
Farogatan 6
Kista SE-164 80
Sweden
Phone: +46 10 719 00 00
Email: fredrik.k.jansson@ericsson.com
Holmberg, et al. Expires March 23, 2014 [Page 9]
