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

Network Working Group                                        C. Holmberg
Internet-Draft                                             M. Westerlund
Intended status: Standards Track                               B. Burman
Expires: March 30, 2013                                       F. Jansson
                                                                Ericsson
                                                      September 26, 2012

   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 30, 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

Holmberg, et al.         Expires March 30, 2013                 [Page 1]
Internet-Draft          Multiple SSRC Signalling          September 2012

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

Holmberg, et al.         Expires March 30, 2013                 [Page 2]
Internet-Draft          Multiple SSRC Signalling          September 2012

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:

Holmberg, et al.         Expires March 30, 2013                 [Page 3]
Internet-Draft          Multiple SSRC Signalling          September 2012

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

Holmberg, et al.         Expires March 30, 2013                 [Page 4]
Internet-Draft          Multiple SSRC Signalling          September 2012

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

Holmberg, et al.         Expires March 30, 2013                 [Page 5]
Internet-Draft          Multiple SSRC Signalling          September 2012

   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

Holmberg, et al.         Expires March 30, 2013                 [Page 6]
Internet-Draft          Multiple SSRC Signalling          September 2012

   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

Holmberg, et al.         Expires March 30, 2013                 [Page 7]
Internet-Draft          Multiple SSRC Signalling          September 2012

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

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

Holmberg, et al.         Expires March 30, 2013                 [Page 8]
Internet-Draft          Multiple SSRC Signalling          September 2012

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com

   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
   Fax:
   Email: fredrik.k.jansson@ericsson.com
   URI:

Holmberg, et al.         Expires March 30, 2013                 [Page 9]