Multiple Synchronization Sources (SSRC) in SDP Media Descriptions
draft-westerlund-mmusic-max-ssrc-00

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 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 28, 2013.

Copyright Notice

Copyright (c) 2012 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.

Table of Contents

• 1. Introduction
• 2. Definitions
• 2.1. Requirements Language
• 2.2. Terminology
• 3. Multiple Media Stream Support
• 3.1. General
• 3.2. Multiple Source Support Limitations
• 4. SDP max-send-ssrc And max-recv-ssrc Attributes
• 4.1. Introduction
• 4.2. Usage
• 4.3. Syntax
• 4.4. Use in Offer/Answer
• 5. Examples
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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.

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 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 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]:

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} 
  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.

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

8.2. Informative References

Authors' Addresses