[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-mmusic-sdp-source-attributes

MMUSIC                                                         J. Lennox
Internet-Draft                                             Layered Media
Expires: August 27, 2007                                          J. Ott
                                       Helsinki University of Technology
                                                              T. Schierl
                                                          Fraunhofer HHI
                                                       February 23, 2007


  Source-Specific Media Attributes in the Session Description Protocol
                                 (SDP)
              draft-lennox-mmusic-sdp-source-attributes-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 27, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Session Description Protocol provides mechanisms to describe
   attributes of multimedia sessions and of individual media streams
   (e.g., Real-time Transport Protocol (RTP) sessions) within a
   multimedia session, but does not provide any mechanism to describe



Lennox, et al.           Expires August 27, 2007                [Page 1]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   individual media sources within a media stream.  This document
   defines a mechanism to describe RTP media sources, identified by
   their Synchronization Source Identifiers (SSRCs), in SDP, associate
   attributes with these sources, and express relationships among
   sources.  It also defines a number of source-level attributes which
   can be used to describe properties of media sources.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Media Attributes . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  The "ssrc" Media Attribute . . . . . . . . . . . . . . . .  5
     4.2.  The "ssrc-group" Media Attribute . . . . . . . . . . . . .  6
   5.  Usage of Identified Source Identifiers in RTP  . . . . . . . .  7
   6.  Source Attributes  . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  The "cname" Source Attribute . . . . . . . . . . . . . . .  9
     6.2.  The "previous-ssrc" Source Attribute . . . . . . . . . . .  9
     6.3.  The "information" Source Attribute . . . . . . . . . . . . 10
     6.4.  The "bandwidth" Source Attribute . . . . . . . . . . . . . 10
     6.5.  The "sendrecv", "sendonly", "recvonly", and "inactive"
           Source Attributes  . . . . . . . . . . . . . . . . . . . . 11
     6.6.  The "charset", "sdplang", "lang", "framerate", and
           "quality" Source Attributes  . . . . . . . . . . . . . . . 12
     6.7.  The "fmtp" Source Attribute  . . . . . . . . . . . . . . . 12
     6.8.  Other Attributes . . . . . . . . . . . . . . . . . . . . . 13
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Usage With the Offer/Answer Model  . . . . . . . . . . . . . . 14
   9.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 15
   10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 15
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     13.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Open issues . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20











Lennox, et al.           Expires August 27, 2007                [Page 2]

Internet-Draft       Source-Specific SDP Attributes        February 2007


1.  Introduction

   The Session Description Protocol (SDP) [RFC4566] provides mechanisms
   to describe attributes of multimedia sessions and of media streams
   (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within
   a multimedia session, but does not provide any mechanism to describe
   individual media sources within a media stream.

   Several recently-proposed protocols, notably RTP Single-Source
   Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe
   specific media sources in SDP messages.  Single-source multicast, in
   particular, needs to ensure that receivers' RTP Syncronization Source
   Identifiers (SSRCs) do not collide with those of media senders, as
   the RTP specification [RFC3550] requires that colliding sources
   change their SSRC values after a collision has been detected.
   Earlier work has used mechanisms specific to each protocol to
   describe the individual sources of an RTP session.

   Moreover, whereas the Real-Time Transport Protocol (RTP) [RFC3550] is
   defined as allowing multiple sources in an RTP session (for example,
   if a user has more than one camera), SDP has no existing mechanism
   for an endpoint to indicate that it will be using multiple sources,
   or to describe their characteristics individually.

   To address all these problems, this document defines a mechanism to
   describe RTP sources, identified by their Synchronization Sources
   Identifiers (SSRCs), in SDP, associate attributes with these sources,
   and express relationships among individual sources.  It also defines
   a number of new SDP attributes that apply to individual sources
   ("source-level" attributes); describes how a number of existing media
   stream ("media-level") attributes can also be applied at the source
   level; and establishes an IANA repository for source-level
   attributes.

   During the still-ongoing discussion in the AVT and MMUSIC working
   groups on the transport [I-D.ietf-avt-rtp-svc] and signaling
   [I-D.schierl-mmusic-layered-codec] of the Scalable Video Coding (SVC)
   Extensions of H.264, SSRC multiplexing of layered video was
   considered as an appropriate multiplexing technique, if the use case
   strongly requires this.  It was considered that a compelling use case
   exists for identifying RTP packet streams carrying different layers
   of a single SVC media stream.  One use case was pointed out, which is
   the adaptation of an SRTP encrypted SVC stream by a middle-box not
   being in the security context.  Since the authentication and
   integrity mechanism of SRTP still requires the middle-boy being in
   the security context, the authors of [I-D.ietf-avt-rtp-svc] and
   [I-D.schierl-mmusic-layered-codec] currently do not consider SSRC
   multiplexing.  Since the process for both memos is still going on,



Lennox, et al.           Expires August 27, 2007                [Page 3]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   however, a requirement for SSRC multiplexing for SVC may come up
   again.  SSRC multiplexing would anyway make an easy identification of
   layers of a scalable media stream in a middle-box possible, without
   the need of parsing into RTP payload headers.  A potential use case
   is shown in Section 7, the examples section.


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.


3.  Overview

   In the Real-Time Transport Protocol (RTP) [RFC3550], an association
   among a group of communicating participants is known as an RTP
   Session.  An RTP session is typically associated with a single
   transport address (in the case of multicast) or communication flow
   (in the case of unicast), though RTP translators and single-source
   multicast [I-D.ietf-avt-rtcpssm] can make the situation more complex.
   RTP topologies are discussed in more detail in
   [I-D.ietf-avt-topologies].

   Within an RTP session, the source of a single stream of RTP packets
   is known as a synchronization source (SSRC).  Every synchronization
   source is identified by a 32-bit numeric identifier.  In addition,
   receivers (who may never send RTP packets) also have source
   identifiers, which are used to identify their RTP Control Protocol
   (RTCP) receiver reports and other feedback messages.

   Messages of the Session Description Protocol (SDP) [RFC4566], known
   as Session Descriptions, describe Multimedia Sessions.  A multimedia
   session is a set of multimedia senders and receivers, and the data
   streams flowing from senders to receivers.  A multimedia session
   contains a number of Media Streams, which are the individual RTP
   sessions or other media paths over which one type of multimedia data
   is carried.  Information that applies to an entire multimedia session
   is called Session-Level information, while information pertaining to
   one media stream is called Media-Level information.  The collection
   of all the information describing a media stream is known as a Media
   Description.  (Media descriptions are also sometimes known informally
   as SDP "m"-lines, after the SDP syntax that begins a media
   description.)  Several standard information elements are defined at
   both the session level and the media level.  Extended information can



Lennox, et al.           Expires August 27, 2007                [Page 4]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   be included at both levels through the use of attributes.

   (The term "Media Stream" does not appear in the SDP specification
   itself, but is used by a number of SDP extensions, for instance
   Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice],
   to denote the object described by an SDP media description.  This
   term is unfortunately rather confusing, as the RTP specification
   [RFC3550] uses the term "media stream" to refer to an individual
   media source or RTP packet stream, identified by an SSRC, whereas an
   SDP media stream describes an entire RTP session, which can contain
   any number of RTP sources.  In this document, the term "media stream"
   means an SDP media stream, i.e. the thing described by an SDP media
   description, whereas "media source" is used for a single source of
   media packets, i.e. an RTP media stream.)

   The core SDP specification does not have any way of describing
   individual media sources, in particular RTP synchronization sources,
   within a media stream.  To address this problem, in this document we
   introduce a third level of information, called Source-Level
   information.  Syntactically, source-level information is described by
   a new SDP media-level attribute "ssrc", which identifies specific
   synchronization sources within an RTP session, and acts as a meta-
   attribute mapping source-level attribute information to these
   sources.

   This document also defines an SDP media-level attribute "ssrc-group",
   which can represent relationships among media sources within an RTP
   session, in much the same way as the "group" attribute [RFC3388]
   represents relationships among media streams within a multimedia
   session.


4.  Media Attributes

   This section defines two media-level attributes, "ssrc" and "ssrc-
   group".

4.1.  The "ssrc" Media Attribute


   a=ssrc:<ssrc-id> <attribute>
   a=ssrc:<ssrc-id> <attribute>:<value>


   The SDP media attribute "ssrc" indicates a property (known as a
   "source-level attribute") of a media source (RTP stream) within an
   RTP session. <ssrc-id> is the synchronizaton source ID (SSRC) of the
   source being described, interpreted as a 32-bit unsigned integer in



Lennox, et al.           Expires August 27, 2007                [Page 5]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   network byte order and represented in decimal. <attribute> or
   <attribute>:<value> represent the source-level attribute specific to
   the given media source.  The source-level attribute follows the
   syntax of the SDP "a=" line.  It thus consists either of a single
   attribute name (a flag), e.g. "sendonly", or an attribute name and
   value, e.g. "cname:user@example.com".

   Within a media stream, ssrc attributes with the same value of
   <ssrc-id> describe different attributes of the same media sources.
   Across media streams, <ssrc-id> values are not correlated (unless
   correlation is indicated by media-stream grouping or some other
   mechanism) and MAY be repeated.

   For each source mentioned in SDP, the source-level attribute "cname",
   defined in Section 6.1, MUST be provided.  Any number of other
   source-level attributes for the source MAY also be provided.

   The "ssrc" media attribute MAY be used for any RTP-based media
   transport.  It is not defined for other transports.

   Though the source-level attributes specified by the ssrc property
   follow the same syntax as session-level and media-level attributes,
   they are defined independently.  All source-level attributes MUST be
   registered with IANA, using the registry defined in Section 12.

   Figure 14 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC4234] grammar for the ssrc attribute.

4.2.  The "ssrc-group" Media Attribute


   a=ssrc-group:<semantics> <ssrc-id> ...


   The SDP media attribute "ssrc-group" expresses a relationship among
   several sources of an RTP session.  It is analogous to the "group"
   session-level attribute [RFC3388], which expresses a relationship
   among media streams in an SDP multimedia session (i.e., a
   relationship among several logically related RTP sessions).  As
   sources are already identified by their SSRC IDs, no analogous
   property to the "mid" attribute is necessary; groups of sources are
   identified by their SSRC IDs directly.

   The <semantics> parameter is taken from the specification of the
   "group" attribute [RFC3388].  Its potential parameters are defined by
   IANA in "Semantics for the 'group' SDP Attribute" under "SDP
   Parameters".  The semantics defined for the ssrc-group attribute are
   FID (Flow Identification) [RFC3388] and FEC (Forward Error



Lennox, et al.           Expires August 27, 2007                [Page 6]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   Correction) [I-D.ietf-mmusic-fec-grouping].  In each case, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams grouped
   using the SDP "group" attribute.

   (None of the other "group" semantics registered with IANA as of this
   writing are useful for source grouping.  LS (Lip Synchronization)
   [RFC3388] is redundant for sources within a media stream, as RTP
   sources with the same CNAME are implicitly synchronized in RTP.  SRF
   (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network
   Address Types) [RFC4091] refer specifically to the media stream's
   transport characteristics.  CS (Composite Session)
   [I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is
   not applicable to RTP.)

   The ssrc-group attribute indicates the sources in a group by listing
   the <ssrc-id>s of the sources in the group.  It MUST list at least
   one <ssrc-id> for a group, and MAY list any number of additional
   ones.  Every <ssrc-id> listed in an ssrc-group attribute MUST be
   defined by a corresponding "ssrc:" line in the same media
   description.

   Figure 15 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC4234] grammar for the ssrc-group attribute.


5.  Usage of Identified Source Identifiers in RTP

   The synchronization source identifiers used in an RTP session are
   chosen randomly and independently by endpoints.  As such, it is
   possible for two RTP endpoints to choose the same SSRC identifier.
   Though the probability of this is low, the RTP specification
   [RFC3550] requires that all RTP endpoints MUST be prepared to detect
   and resolve collisions.

   As a result, all endpoints MUST be prepared for the fact that
   information about specific sources identified in a media stream might
   be out of date.  The actual binding between SSRCs and source CNAMEs
   can only be identified by the source description (SDES) RTCP packets
   transmitted on the RTP session.

   When endpoints are choosing their own local SSRC values for media
   streams for which source-level attributes have been specified, they
   MUST NOT use for themselves any SSRC identifiers mentioned in media
   descriptions they have received for the media stream.

   However, sources identified by SDP source-level attributes do not
   otherwise affect RTP transport logic.  Specifically, sources which



Lennox, et al.           Expires August 27, 2007                [Page 7]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   are only known through SDP, for which neither RTP nor RTCP packets
   have been received, MUST NOT be counted for RTP group size
   estimation, and report blocks MUST NOT be sent for them in SR or RR
   RTCP messages.

   Endpoints MUST NOT assume that only the sources mentioned in SDP will
   be present in an RTP session; additional sources, with previously
   unmentioned SSRC IDs, can be added at any time, and endpoints MUST be
   prepared to receive packets from these sources.  (How endpoints
   handle such packets is not specified here; they SHOULD be handled in
   the same manner as packets from additional sources would be handled
   had the endpoint not received any a=ssrc: attributes at all.)

   An endpoint that observes an SSRC collision between its explicitly-
   signaled source and another entity that has not explicitly signaled
   an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by
   5*1.5*Td, with Td being the deterministic calculated reporting
   interval for receivers, to see whether the conflict still exists.
   (This gives precedence to explicitly-signaled sources, and places the
   burden of collision resolution on non-signaled sources.)  SSRC
   collisions between multiple explicitly-signaled sources, however,
   MUST be acted upon immediately.

   If, following RTP's collision-resolution procedures [RFC3550], a
   source identified by source-level attributes has been forced to
   change its SSRC identifier, the author of the SDP containing the
   source-level attributes for these sources SHOULD send out an updated
   SDP session description with the new SSRC, if the mechanism by which
   SDP is being distributed for the multimedia session has a mechanism
   to distribute updated SDP.  This updated SDP MUST include a previous-
   ssrc source-level attribute, described in Section 6.2, listing the
   source's previous SSRC ID.  (If only a single source with a given
   CNAME has collided, the other RTP session members can infer a
   correspondence between the source's old and new SSRC IDs, without
   requiring an updated session description.  However, if more than one
   source collides at once, or if sources are leaving and re-joining,
   this inference is not possible.  To avoid confusion, therefore,
   sending updated SDP messages is always RECOMMENDED.)

   Endpoints MUST NOT reuse the same SSRC ID for identified sources with
   same CNAME for at least the duration of the RTP session's participant
   timeout interval (see Section 6.3.5 of [RFC3550]).  They SHOULD NOT
   reuse any SSRC ID ever mentioned in SDP (either by themselves or by
   other endpoints) for the entire lifetime of the RTP session.

   Endpoints MUST be prepared for the possibility that other parties in
   the session do not understand SDP source-level attributes, unless
   some higher-level mechanism normatively requires them.  See Section 9



Lennox, et al.           Expires August 27, 2007                [Page 8]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   for more discussion of this.


6.  Source Attributes

   This section describes specific source attributes that can be applied
   to RTP sources.

6.1.  The "cname" Source Attribute


   a=ssrc:<ssrc-id> cname:<cname>


   The "cname" source attribute associates a media source with its
   Canonical End-Point Identifier (CNAME) source description (SDES)
   item.  This MUST be the CNAME value that the media sender will place
   in its RTCP SDES packets; it therefore MUST follow the syntax
   conventions of CNAME defined in the RTP specification [RFC3550].  If
   a session participant receives an RTCP SDES packet associating this
   SSRC with a different CNAME, it SHOULD assume there has been an SSRC
   collision, and that the description of the source that was carried in
   the SDP description is not applicable to the actual source being
   received.  This source attribute is REQUIRED to be present if any
   source attributes are present for a source.  The cname attribute MUST
   NOT occur more than once for the same ssrc-id within a given media
   stream.

   Figure 16 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC4234] grammar for the cname attribute.

6.2.  The "previous-ssrc" Source Attribute


   a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...


   The "previous-ssrc" source attribute associates a media source with
   previous source identifiers used for the same media source.
   Following an SSRC change due to an SSRC collision involving a media
   source described in SDP, the updated session description describing
   the source's new SSRC (described in Section 5) MUST include the
   previous-ssrc attribute associating the new SSRC with the old one.
   If further updated SDP descriptions are published describing the
   media source, the previous-ssrc attribute SHOULD be included if the
   session description was generated before the participant timeout of
   the old SSRC, and MAY be included after that point.  This attribute,
   if present, MUST list at least one previous SSRC, and MAY list any



Lennox, et al.           Expires August 27, 2007                [Page 9]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   number of additional SSRCs for the source, if the source has collided
   more than once.  This attribute MUST be present only once for each
   source.

   Figure 17 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC4234] grammar for the previous-ssrc attribute.

6.3.  The "information" Source Attribute


   a=ssrc:<ssrc> information:<source description>


   The "information" source attribute provides textual information about
   a source.  It is analogous to the SDP "i=" field for session and
   media information.  There MUST be at most one "information" source
   attribute per media source.  If the "charset" attribute is present at
   the session, media, or source level, it specifies the character set
   used in the source description.  If the "charset" attribute is not
   present, the "information" attribute MUST contain ISO 10646
   characters in UTF-8 encoding.

   The "information" attribute is intended to provide a free-form human-
   readable description of a media source.  It is not suitable for
   parsing by automata.

   Figure 18 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC4234] grammar for the information attribute.

6.4.  The "bandwidth" Source Attribute


   a=ssrc:<ssrc> bandwidth:<bwtype>:<bandwidth>


   The "bandwidth" source attribute denotes the proposed bandwidth to be
   used by a source.  The <bwtype> is an alphanumeric modifier giving
   the meaning of the <bandwidth> figure.  Its specification is taken
   from the specification of the "b=" field in SDP [RFC4566], and its
   potential parameters are defined by IANA in the "bwtype" table under
   "SDP Parameters".  The "bandwidth" attribute overrides any "b="
   fields with the same <bwtype> for the session or media; however, a
   source's bandwidth MUST NOT be greater than the value in the
   equivalent "b=" field.  Moreover, the sum of the bandwidths of all
   sources in a media stream MUST NOT exceed the CT (Conference Total)
   bandwidth for the RTP session.

   The <bwtype> values defined for source attributes are "AS"



Lennox, et al.           Expires August 27, 2007               [Page 10]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   (Application-Specific) [RFC4566], and "TIAS" (Transport-Independent
   Application Specific) [RFC3890].  The semantics of these bandwidth
   types follow the are the same as for media-level "b=" fields, except
   that they apply to a single source rather than to every source within
   a session.

   (The other <bwtype> values registered with IANA as of this writing,
   "CT" (Conference Total) [RFC4566], "RS" (RTCP Sender) [RFC3556], and
   "RR" (RTCP Receiver) [RFC3556], all describe aspects of an entire RTP
   session, and so are not meaningful for describing individual
   sources.)

   Figure 19 in Section 10 gives a formal Augmented Backus-Naur Form
   (ABNF) [RFC4234] grammar for the bandwidth attribute.

6.5.  The "sendrecv", "sendonly", "recvonly", and "inactive" Source
      Attributes


   a=ssrc:<ssrc> sendrecv
   a=ssrc:<ssrc> sendonly
   a=ssrc:<ssrc> recvonly
   a=ssrc:<ssrc> inactive


   These source attributes indicate whether the corresponding sources
   will send RTP data ("sendrecv" and "sendonly"), will be used as the
   source of RTCP feedback messages ("sendrecv" and "recvonly"), or
   neither ("inactive").  The default value of this attribute is the
   corresponding media-level send or receive mode for the media stream.
   If a source's send/receive mode is the same as the mode of its media
   stream, session descriptions SHOULD NOT redundantly include the
   source's mode as well.

   The send/receive mode of a source MUST NOT be more permissive than
   that of the stream: that is, a "recvonly" media stream MUST NOT
   contain "sendrecv" or "sendonly" sources, a "sendonly" media stream
   MUST NOT contain "sendrecv" or "recvonly" sources, and an "inactive"
   media stream MUST contain only "inactive" sources.

   For the purposes of the "sendrecv" and "recvonly" modes, RTCP
   "feedback messages" consist of any non-mandatory RTCP packet type,
   including SR or RR RTCP packets containing report blocks, RTCP XR
   [RFC3611] packets, and RTCP AVPF [RFC4585] packets.

   RTCP SR or RR packets (without report blocks), SDES packets, and BYE
   packets MUST still be sent for "sendonly" sources, if the media
   stream has a non-zero RTCP bandwidth, and MAY be sent for "inactive"



Lennox, et al.           Expires August 27, 2007               [Page 11]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   sources.  Each endpoint SHOULD send RTCP from at least one source in
   an RTP session.

   A source which will be "recvonly" or "inactive" for the entire
   duration of a multimedia session -- i.e., one which will never be
   used as the source of RTP packets -- SHOULD NOT be explicitly
   mentioned in SDP.  However, a source which is temporarily "recvonly"
   or "inactive", but which might send RTP packets in the future, MAY be
   mentioned in SDP.

   An endpoint in a "sendrecv" or "recvonly" media stream SHOULD have at
   least one "sendrecv" or "recvonly" source which will send SR or RR
   report blocks while it is receiving active media sources.  However,
   this source need not be explicitly described in SDP.

   The formal grammar of these attributes is the same as of the
   equivalently-named media-level attributes defined in SDP [RFC4566].

6.6.  The "charset", "sdplang", "lang", "framerate", and "quality"
      Source Attributes


   a=ssrc:<ssrc> charset:<character set>
   a=ssrc:<ssrc> sdplang:<language tag>
   a=ssrc:<ssrc> lang:<language tag>
   a=ssrc:<ssrc> framerate:<frame rate>
   a=ssrc:<ssrc> quality:<quality>


   These source attributes apply to a single source within a media
   stream in the same way that the equivalent media attributes defined
   in SDP [RFC4566] apply to all the sources within the stream.  Their
   default values come from the corresponding media-level attributes.

6.7.  The "fmtp" Source Attribute


   a=ssrc:<ssrc> fmtp:<format> <format specific parameters>


   The "fmtp" source attribute allows format-specific parameters to be
   conveyed about a given source.  The <format> parameter MUST be one of
   the media formats (i.e., RTP payload types) specified for the media
   stream.  The meaning of the <format specific parameters> is unique
   for each media type.  This parameter MUST only be used for media
   types for which source-level format parameters have explicitly been
   specified; media-level format parameters MUST NOT be carried over
   blindly.



Lennox, et al.           Expires August 27, 2007               [Page 12]

Internet-Draft       Source-Specific SDP Attributes        February 2007


6.8.  Other Attributes

   Media-level attributes registered with IANA defined outside the core
   SDP specification [RFC4566] have not yet been analyzed and remain for
   future consideration.  Possibly sensible source attributes include
   maxprate [RFC3890], rtcp-fb [RFC4585], and label [RFC4574].


7.  Examples

   This section gives several examples of SDP descriptions of media
   sessions containing source attributes.  For brevity, only the media
   sections of the descriptions are given.

   m=audio 49168 RTP/AVP 0
   a=ssrc:314159 cname:user@example.com

    Figure 10: Example: declaration of a single synchronization source

   The example in Figure 10 shows an audio stream advertising a single
   source.

   m=video 49170 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=ssrc:12345 cname:another-user@example.com
   a=ssrc:12345 information:Main camera
   a=ssrc:67890 cname:another-user@example.com
   a=ssrc:67890 information:Alternate camera

     Figure 11: Example: a media stream containing several independent
                   sources from a single session member.

   The example in Figure 11 shows a video stream where one participant
   (identified by a single CNAME) has several cameras.  Each camera is
   identified by descriptive text.

   m=video 49172 RTP/AVP 97
   a=rtpmap:97 SVC/90000
   a=ssrc-group:DDP 271828 14142135
   a=ssrc:271828 cname:layered-codec@example.com
   a=ssrc:271828 framerate:15
   a=ssrc:14142135 cname:layered-codec@example.com
   a=ssrc:14142135 depend:lay 271828
   a=ssrc:14142135 framerate:30

      Figure 12: Example: relationship among several sources: layered
                                  coding




Lennox, et al.           Expires August 27, 2007               [Page 13]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   The example in Figure 12 shows a relationship among several sources,
   grouped by the "DDP" grouping semantics defined in Signaling of
   Layered and Multi-Description Media
   [I-D.schierl-mmusic-layered-codec].  (Note that this is only an
   example; multiplexing of layered codecs among several sources in an
   RTP session is currently not specified or encouraged.)

   m=video 49174 RTP/AVPF 96 98
   a=rtpmap:96 H.264/90000
   a=rtpmap:98 rtx/90000
   a=fmtp:98 apt=96;rtx-time=3000
   a=ssrc-group:FID 11111 22222
   a=ssrc:11111 cname:user3@example.com
   a=ssrc:11111 information:Main camera
   a=ssrc:22222 cname:user3@example.com
   a=ssrc-group:FID 33333 44444
   a=ssrc:33333 cname:user3@example.com
   a=ssrc:33333 information:Alternate camera
   a=ssrc:44444 cname:user3@example.com

          Figure 13: Example: relationship among several sources:
                          retransmission sources

   The example in Figure 13 shows how the relationships among sources
   used for RTP Retransmission [RFC4588] can be explicitly signaled.
   This prevents the complexity of associating original sources with
   retransmission sources when SSRC multiplexing is used for RTP
   retransmission, as is described in Section 5.3 of [RFC4588].


8.  Usage With the Offer/Answer Model

   When used with the SDP Offer/Answer Model [RFC3264], SDP source-
   specific attributes describe only the sources with which each party
   is willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.

   The SSRC IDs for sources described by an SDP answer MUST be distinct
   from the SSRC IDs for sources of that media stream in the offer.
   Similarly, new SSRC IDs in an updated offer MUST be distinct from the
   ssrc IDs for that media stream established in the most recent offer/
   answer exchange for the session, and SHOULD be distinct from any SSRC
   ID ever used by either party within the multimedia session (whether
   or not it is still being used).




Lennox, et al.           Expires August 27, 2007               [Page 14]

Internet-Draft       Source-Specific SDP Attributes        February 2007


9.  Backward Compatibility

   TBD.

   Things should be compatible for endpoints which don't understand
   source attributes, if they actually implement the requirements of
   RTP.


10.  Formal Grammar

   This section gives a formal Augmented Backus-Naur Form (ABNF)
   [RFC4234] grammar for each of the new media and source attributes
   defined in this document.  Grammars for existing session or media
   attributes which have been extended to be source attributes are not
   included.

   ssrc-attr = "ssrc:" ssrc-id SP attribute
   ; The base definition of "attribute" is in RFC 4566.
   ; (It is the content of "a=" lines.)
   ssrc-id = integer ; 0 - 2**32 - 1

   attribute /= ssrc-attr

               Figure 14: Syntax of the ssrc media attribute


   ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
   ; The definition of "semantics" is in RFC 3388.
   ; (It is the type of grouping being done.)

   attribute /= ssrc-group-attr

            Figure 15: Syntax of the ssrc-group media attribute


   cname-attr = "cname:" cname
   cname = byte-string
   ; Following the syntax conventions for CNAME as defined in RFC 3550.
   ; The definition of "byte-string" is in RFC 4566.

   attribute /= cname-attr

              Figure 16: Syntax of the cname source attribute







Lennox, et al.           Expires August 27, 2007               [Page 15]

Internet-Draft       Source-Specific SDP Attributes        February 2007


   previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)

   attribute /= previous-ssrc-attr

          Figure 17: Syntax of the previous-ssrc source attribute


   information-attr = "information:" text
   ; The definition of "text" is in RFC 4566.
   ; (It is the human-readable text, as in "i=" lines.)

   attribute /= information-attr

           Figure 18: Syntax of the information source attribute


   bandwidth-attr = "bandwidth:" bwtype ":" bandwidth
   ; The definitions of "bwtype" and "bandwidth" are in RFC 4566.
   ; (They are used in "b=" lines.)

   attribute /= bandwidth-attr

            Figure 19: Syntax of the bandwidth source attribute


11.  Security Considerations

   TBD

   All the normal security implications of RTP and SDP still apply.

   If you're not using SRTP, people can forge the RTP packets you're
   receiving.


12.  IANA Considerations

   Add ssrc and ssrc-group in Section 4 as media-level attributes.

   Define source-level IANA registry and populate it with source
   attributes from Section 6.


13.  References







Lennox, et al.           Expires August 27, 2007               [Page 16]

Internet-Draft       Source-Specific SDP Attributes        February 2007


13.1.  Normative References

   [I-D.ietf-mmusic-fec-grouping]
              Li, A., "Forward Error Correction Grouping Semantics in
              Session Description  Protocol",
              draft-ietf-mmusic-fec-grouping-05 (work in progress),
              June 2006.

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

   [RFC3388]  Camarillo, G., Eriksson, G., Holler, J., and H.
              Schulzrinne, "Grouping of Media Lines in the Session
              Description Protocol (SDP)", RFC 3388, December 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.

   [RFC3890]  Westerlund, M., "A Transport Independent Bandwidth
              Modifier for the Session Description Protocol (SDP)",
              RFC 3890, September 2004.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

13.2.  Informative References

   [I-D.ietf-avt-rtcpssm]
              Chesterfield, J., "RTCP Extensions for Single-Source
              Multicast Sessions with Unicast Feedback",
              draft-ietf-avt-rtcpssm-12 (work in progress),
              October 2006.

   [I-D.ietf-avt-rtp-svc]
              Wenger, S., "RTP Payload Format for SVC Video",
              draft-ietf-avt-rtp-svc-00 (work in progress),
              December 2006.

   [I-D.ietf-avt-topologies]
              Westerlund, M. and S. Wenger, "RTP Topologies",



Lennox, et al.           Expires August 27, 2007               [Page 17]

Internet-Draft       Source-Specific SDP Attributes        February 2007


              draft-ietf-avt-topologies-03 (work in progress),
              December 2006.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Methodology for Network  Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-13 (work in progress), January 2007.

   [I-D.mehta-rmt-flute-sdp]
              Mehta, H., "SDP Descriptors for FLUTE",
              draft-mehta-rmt-flute-sdp-05 (work in progress),
              January 2006.

   [I-D.schierl-mmusic-layered-codec]
              Wenger, S. and T. Schierl, "Signaling media decoding
              dependency in Session Description Protocol (SDP)",
              draft-schierl-mmusic-layered-codec-02 (work in progress),
              December 2006.

   [RFC3524]  Camarillo, G. and A. Monrad, "Mapping of Media Streams to
              Resource Reservation Flows", RFC 3524, April 2003.

   [RFC3556]  Casner, S., "Session Description Protocol (SDP) Bandwidth
              Modifiers for RTP Control Protocol (RTCP) Bandwidth",
              RFC 3556, July 2003.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611,
              November 2003.

   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
              Address Types (ANAT) Semantics for the Session Description
              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.





Lennox, et al.           Expires August 27, 2007               [Page 18]

Internet-Draft       Source-Specific SDP Attributes        February 2007


Appendix A.  Open issues

   o  Does an IANA registry need to be defined for ssrc-group semantics,
      separate from group semantics?
   o  Similarly, does a separate IANA registry need to be defined for
      bwtype parameter for the source-level bandwidth attribute?
   o  Would "orient", "ptime", or "maxptime" be useful as source-level
      attributes?
   o  Should any other SDP media-level attributes be carried over as
      source-level attributes?
   o  Should Offer/Answer be extended to accept or reject individual
      sources?


Authors' Addresses

   Jonathan Lennox
   Layered Media, Inc.
   433 Hackensack Avenue
   Sixth Floor
   Hackensack, NJ  07601
   US

   Email: jonathan@layeredmedia.com


   Joerg Ott
   Helsinki University of Technology (TKK)
   Networking Laboratory
   PO Box 3000
   FIN-02015 TKK
   Finland

   Email: jo@acm.org


   Thomas Schierl
   Fraunhofer HHI
   Einsteinufer 37
   D-10587 Berlin
   Germany

   Phone: +49-30-31002-227
   Email: schierl@hhi.fhg.de







Lennox, et al.           Expires August 27, 2007               [Page 19]

Internet-Draft       Source-Specific SDP Attributes        February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Lennox, et al.           Expires August 27, 2007               [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/