Network Working Group                                        P. Thatcher
Internet-Draft                                                    Google
Intended status: Standards Track                               M. Zanaty
Expires: May 14, August 4, 2016                                    S. Nandakumar
                                                           Cisco Systems
                                                               B. Burman
                                                                Ericsson
                                                                A. Roach
                                                               B. Campen
                                                                 Mozilla
                                                       November 11, 2015
                                                       February 01, 2016

                     RTP Payload Format Constraints
                        draft-ietf-mmusic-rid-00
                        draft-ietf-mmusic-rid-01

Abstract

   In this specification, we define a framework for identifying Source RTP
   Streams with the constraints on its payload format in the Session
   Description Protocol.  This framework uses defines a new "rid" SDP
   attribute to: a) effectively identify the Source RID RTP Streams within a
   RTP Session, b) constrain their payload format parameters in a codec-agnostic codec-
   agnostic way beyond what is provided with the regular Payload Types
   and c) enable unambiguous mapping between the Source RID RTP Streams to
   their media format specification in the SDP.

   Note-1: The name 'rid' is not yet finalized.  Please refer to
   Section 12 for more details on the naming.

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 May 14, August 4, 2016.

Copyright Notice

   Copyright (c) 2015 2016 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Key Words for Requirements  . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  SDP 'rid' "a=rid" Media Level Attribute . . . . . . . . . . . . . . .   5
   6.  'rid-level'   4
   5.  "a=rid" constraints . . . . . . . . . . . . . . . . . . .   6
   7. . .   5
   6.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .   7
     7.1.
     6.1.  Generating the Initial SDP Offer  . . . . . . . . . . . .   7
     7.2.
     6.2.  Answerer processing the SDP Offer . . . . . . . . . . . .   8
       7.2.1.
       6.2.1.  'rid' unaware Answerer  . . . . . . . . . . . . . . .   8
       7.2.2.
       6.2.2.  'rid' aware Answerer  . . . . . . . . . . . . . . . .   8
     7.3.
     6.3.  Generating the SDP Answer . . . . . . . . . . . . . . . .   9
     7.4.  Offering
     6.4.  Offerer Processing of the SDP Answer  . . . . . . . . . .  10
     7.5.
     6.5.  Modifying the Session . . . . . . . . . . . . . . . . . .  10
   8.  Usage of 'rid' in RTP and RTCP  . . . . .  11
   7.  Use with Declarative SDP  . . . . . . . . . .  10
     8.1.  RTCP 'RID' SDES Extension . . . . . . . .  11
   8.  Interaction with Other Techniques . . . . . . . .  11
     8.2.  RTP 'rid' Header Extension . . . . . .  11
   9.  Formal Grammar  . . . . . . . . .  11
   9.  Interaction with Other Techniques . . . . . . . . . . . . . .  12
   10. Formal Grammar  . . . SDP Examples  . . . . . . . . . . . . . . . . . . . .  12
   11. SDP Examples . . . .  13
     10.1.  Many Bundled Streams using Many Codecs . . . . . . . . .  13
     10.2.  Scalable Layers  . . . . . . . . . . .  14
     11.1.  Many Bundled Streams using Many Codecs . . . . . . . . .  14
     11.2.  Scalable Layers  15
   11. Open Issues . . . . . . . . . . . . . . . . . . . .  16
   12. Open Issues . . . . .  16
     11.1.  Declarative SDP  . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Name
     11.2.  Definition of the identifier bitrate  . . . . . . . . . . . . . . . . .  16
   13. IANA Considerations
     11.3.  Escaping new constraint values . . . . . . . . . . . . .  16
     11.4.  Utility of max-width and max height  . . . . . . . . . .  17
     13.1.  New RTP Header Extension URI
     11.5.  Definition of max-fps  . . . . . . . . . . . . . . . . .  17
     13.2.  New SDES item
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     13.3.  18
     12.1.  New SDP Media-Level attribute  . . . . . . . . . . . . .  18
     13.4.
     12.2.  Registry for RID-Level Parameters  . . . . . . . . . . .  18
   14.
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   15.
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   16.
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     16.1.
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     16.2.  19
     15.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Payload Type (PT) in RTP provides a mapping between the format of the
   RTP payload and the media format description specified in the
   signaling.  For applications that use SDP for signaling, the
   constructs rtpmap and/or fmtp describe the characteristics of the
   media that is carried in the RTP payload, mapped to a given PT.

   Recent advances in standards such as RTCWEB and NETVC have given rise to rich multimedia
   applications requiring support for multiple RTP Streams with in within a RTP
   session [I-D.ietf-mmusic-sdp-bundle-negotiation],
   [I-D.ietf-mmusic-sdp-simulcast] or having to support multiple codecs,
   for example. a large number
   of codecs.  These demands have unearthed challenges inherent with:

   o  The restricted RTP PT space in specifying the various payload
      configurations,

   o  The codec-specific constructs for the payload formats in SDP,

   o  Missing or underspecied underspecified payload format parameters,

   o  Ambiguity in mapping between the  Overloading of PTs to indicate not just codec configurations, but
      individual Source streams within an RTP Streams and
      their equivalent format specification session.

   To expand on these points: [RFC3550] assigns 7 bits for the PT in the SDP.

   This specification defines a new SDP framework for constraining
   Source
   RTP Streams (Section 2.1.10
   [I-D.ietf-avtext-rtp-grouping-taxonomy]), called "Restriction
   Identifier (rid)", header.  However, the assignment of static mapping of payload
   codes to payload formats and multiplexing of RTP with other protocols
   (such as RTCP) could result in limited number of payload type numbers
   available for the application usage.  In scenarios where the number
   of possible RTP payload configurations exceed the available PT space
   within a RTP Session, there is need a way to represent the additional
   constraints on payload configurations and to effectively map a RID
   RTP Stream to its corresponding constraints.  This issue is
   exacerbated by the increase in techniques such as simulcast and
   layered codecs, which introduce additional streams into RTP Sessions.

   This specification defines a new SDP framework for constraining
   Source RTP Streams (Section 2.1.10
   [I-D.ietf-avtext-rtp-grouping-taxonomy]), along with the SDP
   attributes to constrain their payload formats in a codec-agnostic way.  The "rid"
   This framework can be thought of as complementary extension to the
   way the media format parameters are specified in SDP today, via the
   "a=fmtp" attribute.

   This specification also proposes a new RTCP makes use of the RTP Stream Identifier SDES RTCP
   item to carry the
   "rid" value, defined in [I-D.roach-avtext-rid]  to provide correlation
   between the RTP Packets and their format specification in the SDP.  This SDES item also uses the header
   extension mechanism [I-D.ietf-avtext-sdes-hdr-ext] to provide
   correlation at stream startup, or stream changes where RTCP isn't
   sufficient.

   The additional constraints on individual streams are indicated with a
   new "a=rid" SDP attribute.  Note that the "rid" parameters communicated via
   this attribute only serve to further constrain the parameters that
   are established on a PT format.  They do not relax any existing
   constraints.

   As described in Section 7.2.1, 6.2.1, this mechanism achieves backwards
   compatibility via the normal SDP processing rules, which require
   unknown a= parameters to be ignored.  This means that implementations
   need to be prepared to handle successful offers and answers from
   other implementations that neither indicate nor honor the constraints
   requested by this mechanism.

   Further, as described in Section 7 6 and its subsections, this
   mechanism achieves extensibility by: (a) having offerers include all
   supported constraints in their offer, abd (b) having answerers ignore
   a=rid
   "a=rid" lines that specify unknown constraints.

2.  Key Words for Requirements

   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]

3.  Terminology

   The terms Source "Source RTP Stream, Endpoint, RTP Session, Stream", "Endpoint", "RTP Session", and RTP Stream "RTP
   Stream" are used as defined in
   [I-D.ietf-avtext-rtp-grouping-taxonomy].

   The term "RID RTP Stream" is used as defined in
   [I-D.roach-avtext-rid].

   [RFC4566] and [RFC3264] terminology is also used where appropriate.

4.  Motivation  SDP "a=rid" Media Level Attribute

   This section summarizes several motivations for proposing defines new SDP media-level attribute [RFC4566],
   "a=rid".  Roughly speaking, this attribute takes the "rid"
   framework.

   1. following form
   (see Section 9 for a formal definition).

a=rid:<rid-identifier> <direction> [pt=<fmt-list>;]<constraint>=<value>...

   An "a=rid" SDP media attribute specifies constraints defining a
   unique RTP PT Space Exhaustion: [RFC3550] defines payload type (PT) that
       identifies configuration identified via the format of "rid-identifier".
   This value binds the restriction to the RID RTP payload and determine its
       interpretation Stream identified by
   its RID SDES item [I-D.roach-avtext-rid].

   The "direction" parameter identifies the application.  [RFC3550] assigns 7 bits for
       the PT in the RTP header.  However, the assignment of static
       mapping of payload codes to payload formats and multiplexing of
       RTP with other protocols (such as RTCP) could result in limited
       number directionality of payload type numbers available for the application
       usage.  In scenarios where the number of possible RID
   RTP payload
       configurations exceed the available Stream; it may be either "send" or "recv".

   The optional "pt" parameter lists one or more PT space within a RTP
       Session, there is need a way to represent values that can be
   used in the additional
       constraints on payload configurations and to effectively map a
       Source associated RID RTP Stream to its corresponding constraints.

   1.  Multi-source and Multi-stream Use Cases: Recently, there Stream.  If the parameter is a
       rising trend with real-time multimedia applications supporting
       multiple sources per endpoint with various temporal resolutions
       (Scalable Video Codec) and spatial resolutions (Simulcast) per
       source.  These applications are being challenged by absent,
   then any of the limited
       RTP PT space and/or by the underspecified SDP constructs for
       exercising granular control on configuring the individual Source
       RTP Streams.

5.  SDP 'rid' Media Level Attribute

   This section defines new SDP media-level attribute [RFC4566],
   "a=rid".  Roughly speaking, this attribute takes the following form
   (see Section 10 for a formal definition).

a=rid:<rid-identifier> <direction> [pt=<fmt-list>;]<constraint>=<value>...

   A given "a=rid" SDP media attribute specifies constraints defining an
   unique RTP payload configuration identified via values specified in the "rid-identifier".
   A set corresponding "m=" line
   may be used.

   The list of zero or more codec-agnostic "rid-level" constraints are defined "constraint" parameters
   (Section 6) that 5) describe the media format specification applicable
   to one or more Payload Types speicified by restrictions that the "a=rid" line.

   The 'rid' corresponding RID RTP
   Stream will conform to.

   This framework MAY be used in combination with the 'a=fmtp' "a=fmtp" SDP
   attribute for describing the media format parameters for a given RTP
   Payload Type.  However in  In such scenarios, the 'rid-level' "a=rid" constraints (Section 6) 5)
   further constrains constrain the equivalent 'fmtp' "a=fmtp" attributes.

   The 'direction' identifies the either 'send', 'recv' directionality
   of the Source RTP Stream.

   A given SDP media description MAY have zero or more "a=rid" lines
   describing various possible RTP payload configurations.  A given
   'rid-identifier'
   "rid-identifier" MUST NOT be repeated in a given media description. description
   ("m=" section).

   The 'rid' "a=rid" media attribute MAY be used for any RTP-based media
   transport.  It is not defined for other transports, although other
   documents may extend its semantics for such transports.

   Though the 'rid-level' attributes parameters specified by the 'rid' property "rid" constraints follow the a
   syntax similar to session-level and media-level attributes, they are
   defined independently.  All 'rid-level'
   attributes "rid" parameters MUST be registered with
   IANA, using the registry defined in Section 13 12

   Section 10 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
   grammar for the "rid" attribute.  The "a=rid" media attribute is not
   dependent on charset.

6.  'rid-level'

5.  "a=rid" constraints

   This section defines the 'rid-level' "a=rid" constraints that can be used to
   constrain
   restrict the RTP payload encoding format in a codec-agnostic way.

   The following constraints are intended to apply to video codecs in a
   codec-independent fashion.

   o  max-width, for spatial resolution in pixels.  In the case that
      stream orientation signaling is used to modify the intended
      display orientation, this attribute refers to the width of the
      stream when a rotation of zero degrees is encoded.

   o  max-height, for spatial resolution in pixels.  In the case that
      stream orientation signaling is used to modify the intended
      display orientation, this attribute refers to the width of the
      stream when a rotation of zero degrees is encoded.

   o  max-fps, for frame rate in frames per second.  For encoders that
      do not use a fixed framerate for encoding, this value should
      constrain the minimum amount of time between frames: the time
      between any two consecutive frames SHOULD NOT be less than 1/max-
      fps seconds.

   o  max-fs, for frame size in pixels per frame.  This is the product
      of frame width and frame height, in pixels, for rectangular
      frames.

   o  max-br, for bit rate in bits per second.  The restriction applies
      to the media payload only, and does not include overhead
      introduced by other layers (e.g., RTP, UDP, IP, or Ethernet).  The
      exact means of keeping within this limit are left up to the
      implementation, and instantaneous excursions outside the limit are
      permissible.  For any given one-second sliding window, however,
      the total number of bits in the payload portion of RTP SHOULD NOT
      exceed the value specified in "max-br."

   o  max-pps, for pixel rate in pixels per second.  This value SHOULD
      be handled identically to max-fps, after performing the following
      conversion: max-fps = max-pps / (width * height).  If the stream
      resolution changes, this value is recalculated.  Due to this
      recalculation, excursions outside the specified maximum are
      possible during near resolution change boundaries.

   o  max-bpp, for maximum number of bits per pixel, calculated as an
      average of all samples of any given coded picture.  This is
      expressed as a floating point value, with an allowed range of
      0.0001 to 48.0.

   All the constraints are optional and are subjected subject to negotiation based
   on the SDP Offer/Answer rules described in Section 7 6.

   This list is intended to be an initial set of constraints; future constraints.  Future
   documents may define additional constraints; see Section 13.4. 12.2.  While
   this document doesn't does not define constraints for audio codecs, there is
   no reason such constraints should be precluded from definition and
   registration by other documents.

   Section 10 9 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234]
   grammar for each of the "rid-level" "a=rid" attributes defined in this section.

7.

6.  SDP Offer/Answer Procedures

   This section describes the SDP Offer/Answer [RFC3264] procedures when
   using the 'rid' this framework.

   Note that 'rid's "rid-identifier" values are only required to be unique
   within a media section ("m-line"); they do not necessarily need to be
   unique within an entire RTP session.  In traditional usage, each
   media section is sent on its own unique 5-tuple, which provides an
   unambiguous scope.  Similarly, when using BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
   streams uniquely to a single media description.

7.1.

6.1.  Generating the Initial SDP Offer

   For each media description in the offer, the offerer MAY choose to
   include one or more "a=rid" lines to specify a configuration profile
   for the given set of RTP Payload Types.

   In order to construct a given "a=rid" line, the offerer must follow
   the below
   these steps:

   1.  It MUST generate a 'rid-identifier' "rid-identifier" that is unique within a media
       description

   2.  It MUST set the direction for the 'rid-identifier' "rid-identifier" to one of
       'send'
       "send" or 'recv' "recv"

   3.  It MAY include a listing of SDP format tokens (usually
       corresponding to RTP payload types) allowed to which the constraints
       expressed by appear in the 'rid-level' attributes apply. RID
       RTP Stream.  Any Payload Types chosen MUST be a valid payload
       type for the media section (that is, it must be listed on the
       "m=" line).  The order of the listed formats is significant; the
       alternatives are listed from (left) most preferred to (right)
       least preferred.  When using RID, this preference overrides the
       normal codec preference as expressed by format type ordering on
       the "m="-line, using regular SDP rules.

   4.  The Offerer then chooses the 'rid-level' zero or more "a=rid" constraints
       (Section 6) 5) to be applied for to the rid, and adds them to the
       "a=rid" line.

   5.  If
       it the offerer wishes the answer answerer to have the ability to specify
       a constraint, but does not wish to set a value itself, it MUST
       include the name of the constraint in the "a=rid" line, but
       without any indicated value.

   Note: If an 'a=fmtp' "a=fmtp" attribute is also used to provide media-format-
   specific parameters, then the 'rid-level' "a=rid" attributes will further
   constrain the equivalent 'fmtp' "a=fmtp" parameters for the given Payload
   Type for those streams associated with the 'rid'. specified RID RTP Stream.

   If a given codec would require an "a=fmtp" line when used without
   "a=rid" then the offer MUST include a valid corresponding "a=fmtp"
   line even when using RID.

7.2. "a=rid".

6.2.  Answerer processing the SDP Offer

   For each media description in the offer, and for each "a=rid"
   attribute in the media description, the receiver of the offer will
   perform the following steps:

7.2.1.

6.2.1.  'rid' unaware Answerer

   If the receiver doesn't support the 'rid' framework proposed in this
   specification, the entire "a=rid" line is ignored following the
   standard [RFC3264] Offer/Answer rules.

   Section 7.1 6.1 requires the offer to include a valid "a=fmtp" line for
   any codecs that otherwise require it (in other words, the "a=rid"
   line cannot be used to replace "a=fmtp" configuration).  As a result,
   ignoring the "a=rid" line is always guaranteed to result in a valid
   session description.

7.2.2.

6.2.2.  'rid' aware Answerer

   If the answerer supports 'rid' framework, the "a=rid" attribute, the following steps
   are executed, in order, for each "a=rid" line in a given media
   description:

   1.  Extract the rid-identifier from the "a=rid" line and verify its
       uniqueness.  In the case of a duplicate, the entire "a=rid" line,
       and all "a=rid" lines with rid-identifiers that duplicate this
       line, are rejected and MUST NOT be included in the SDP Answer.

   2.  If the "a=rid" line contains a "pt=" parameter, the list of
       payload types is verified against the list of valid payload types
       for the media section (that is, those listed on the "m=" line).
       If there is no match for the Payload Type listed in
       Any PT missing from the "a=rid"
       line, then remove "m=" line is removed from the "a=rid" line. "pt="
       parameter.

   3.  The answerer ensures that "rid-level" "a=rid" parameters listed are
       supported and
       syntactically well formed.  In the case of a syntax
       error or error, the
       "a=rid" line is removed.

   4.  If the "direction" parameter is "recv", The answerer ensures that
       "a=rid" parameters are supported.  In the case of an unsupported
       parameter, the "a=rid" line is removed.

   4.

   5.  If the 'depend' rid-level attribute "depend" parameter is included, the answerer MUST make
       sure that the rid-identifiers listed rid-identifiers unambiguously match the rid-identifiers rid-
       identifiers in the SDP offer.  Any lines that do not are removed.

   5.  if the "a=rid" line contains a "pt=" parameter, the

   6.  The answerer verifies that the attribute values provided in the "rid-level"
       attributes constraining parameters are
       consistent with at least one of the corrsponding codecs and their
       other parameters.  See to be used with the
       RID RTP Stream.  If the "a=rid" line contains a "pt=" parameter,
       it contains the list of such codecs; otherwise, the list of such
       codecs is taken from the associated "m=" line.  See Section 9 8 for
       more detail.  If the rid-
       level "a=rid" parameters are incompatible with the
       other codec
       properties, properties for all codecs, then the "a=rid" line is
       removed.

7.3.

   Note that the answerer does not need to understand every constraint
   present in a "send" line: if a stream sender constrains the stream in
   a way that the receiver does not understand, this causes no issues
   with interoperability.

6.3.  Generating the SDP Answer

   Having performed the verification of the SDP offer as described, the
   answerer shall perform the following steps to generate the SDP
   answer.

   For each "a=rid" line:

   1.  The sense of of the "direction" parameter is reversed: "send" is
       changed to "recv", and "recv" is changed to "send".

   2.  The answerer MAY choose to modify specific 'rid-level' attribute "a=rid" constraint
       value in the answer SDP.  In such a case, the modified value MUST
       be more constrained than the ones specified in the offer.  The
       answer MUST NOT include any constraints that were not present in
       the offer.

   2.

   3.  The answerer MUST NOT modify the 'rid-identifier' "rid-identifier" present in the
       offer.

   3.  The

   4.  If the "a=rid" line contains a "pt=" parameter, the answerer is
       allowed to remove one or more media formats from a given 'a=rid' "a=rid"
       line.  If the answerer chooses to remove all the media format
       tokens from an "a=rid" line, the answerer MUST remove the entire
       "a=rid" line.

   4.  If the offer did not contain a "pt=" parameter for
       a given "a=rid" line, then the answer MUST NOT contain a "pt="
       parameter in the corresponding line.

   5.  In cases where the answerer is unable to support the payload
       configuration specified in a given "a=rid" line in the offer, the
       answerer MUST remove the corresponding "a=rid" line.  This
       includes situations in which the answerer does not understand one
       or more of the constraints in the an "a=rid" line that has an
       associated value. with a direction of
       "recv".

   Note: in the case that the answerer uses different PT values to
   represent a codec than the offerer did, the "a=rid" values in the
   answer use the PT values that were sent are present in the offer.

7.4.  Offering its answer.

6.4.  Offerer Processing of the SDP Answer

   The offerer shall follow the these steps similar to answerer's offer when processing with the following exceptions answer:

   1.  The offerer MUST ensure that matches the 'rid-identifiers' aren't changed
       between "a=rid" line in the answer to the "a=rid"
       line in the offer and using the answer. "rid-identifier".  If no matching
       line can be located in the offer, the "a=rid" line is ignored.

   2.  If so, the answer contains any constraints that were not present in
       the offer, then the offerer MUST SHALL consider the corresponding 'a=rid' "a=rid" line as
       rejected.

   2.

   3.  If there exist changes in the 'rid-level' attribute values, constraints have been changed between the offer and the
       answer, the offerer MUST ensure that the modifications can be supported or
       else
       supported; if they cannot, the SHALL consider the "a=rid" line as
       rejected.

   3.

   4.  If the SDP "a=rid" line in the answer contains any "rid-identifier" that doesn't
       match with the offer, the a "pt=" parameter but
       the offer did not, the offerer MUST ignore SHALL consider the corresponding "a=rid" line.

   4. line as
       rejected.

   5.  If the "a=rid" line in the answer contains a "pt=" parameter, parameter and
       the offer did as well, the offerer verifies that the list of
       payload types is a subset of those sent in the corresponding
       "a=rid" line in the offer.

   5.  If not, the offerer SHALL consider
       the "a=rid" line as rejected.

   6.  If the "a=rid" line contains a "pt=" parameter, the offerer
       verifies that the attribute values provided in the "rid-level" "a=rid"
       attributes are consistent with the corrsponding corresponding codecs and their
       other parameters.  See Section 9 8 for more detail.  If the rid-
       level "a=rid"
       parameters are incompatible with the other codec properties, then
       the "a=rid" line is removed.

7.5.

   7.  The offerer verifies that the constraining parameters are
       consistent with at least one of the codecs to be used with the
       RID RTP Stream.  If the "a=rid" line contains a "pt=" parameter,
       it contains the list of such codecs; otherwise, the list of such
       codecs is taken from the associated "m=" line.  See Section 8 for
       more detail.  If the "a=rid" parameters are incompatible with the
       other codec properties for all codecs, then the "a=rid" line
       SHALL be considered rejected

   Any "a=rid" line present in the offer that was not matched by step 1
   above SHALL be considered as rejected.

6.5.  Modifying the Session

   Offers and answers inside an existing session follow the rules for
   initial session negotiation.  Such an offer MAY propose a change in
   the number of RIDs in use.  To avoid race conditions with media, any
   RIDs with proposed changes SHOULD use a new ID, rather than re-using
   one from the previous offer/answer exchange.  RIDs without proposed
   changes SHOULD re-use the ID from the previous exchange.

8.  Usage of 'rid' in RTP and RTCP

   The RTP fixed header includes the payload type number and the SSRC
   values of the RTP stream.  RTP defines how you de-multiplex streams
   within an RTP session, but in some use cases applications need
   further identifiers in order to effectively map the individual RTP
   Streams to their equivalent payload configurations in the SDP.

   This specification defines a new RTCP SDES item [RFC3550], 'RID',
   which is used to carry rids within RTCP SDES packets.  This makes it
   possible for a receiver to associate received RTP packets
   (identifying the Source RTP Stream)

7.  Use with a media description having
   the format constraint specified.

   This specification also uses the RTP header extension for RTCP SDES
   items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RID
   information Declarative SDP

   Although designed predominantly with session negotiation in RTP packets to provide correlation at stream startup,
   or after stream changes where mind, the use of RTCP may not
   "a=rid" attribute can also be sufficiently
   responsive.

8.1.  RTCP 'RID' SDES Extension

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      RID=TBD  |     length    | rid                         ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The rid payload is UTF-8 encoded and is not null-terminated.

      RFC EDITOR NOTE: Please replace TBD used in declarative SDP situations.
   When used with the assigned SDES
      identifier value.

8.2.  RTP 'rid' Header Extension

   Because recipients of RTP packets will typically need to know which
   "a=rid" declarative SDP, any constraints they correspond applied to immediately upon receipt, this
   specification also defines a means of carrying RID identifiers in RTP
   extension headers, using the technique described in
   [I-D.ietf-avtext-sdes-hdr-ext].

   As described in that document, the header extension element can be
   encoded using either the one-byte or two-byte header, and the
   identification-tag payload is UTF-8 encoded, as in SDP.

   As the identification-tag is included in an RTP header extension,
   there should be some consideration about the packet expansion caused
   by the identification-tag.  To avoid Maximum Transmission Unit (MTU)
   issues for the RTP packets,
   indicate how the header extension's size needs sender intends to be
   taken into account when constrain the encoding media.  Note that set of header
   extensions included in stream they are
   sending.

   In declarative use, the packet needs to "direction" parameter MUST be padded to the next
   32-bit boundary using zero bytes [RFC5285]

   It is RECOMMENDED that the identification-tag is kept short.  Due set to
   the properties of the RTP header extension mechanism, when using the
   one-byte header, a tag that is 1-3 bytes will result "send"
   in that a
   minimal number all "a=rid" lines.

   Recipients of 32-bit words are used for the RTP header extension,
   in case no other header extensions are included at the same time.  In
   many cases, a one-byte tag will be sufficient; it is RECOMMENDED that
   implementations declarative SDP may use the shortest identifier that fits indicated constraints to
   select an RID RTP Stream to decode, based on their purposes.

9. needs and
   capabilities.

8.  Interaction with Other Techniques

   Historically, a number of other approaches have been defined that
   allow constraining media streams via SDP parameters.  These include:

   o  Codec-specific configuration set via format parameters ("a=fmtp");
      for example, the H.264 "max-fs" format parameter

   o  Size restrictions imposed by image attribute attributes
      ("a=imgattr") [RFC6236]

   When the mechanism described in this document is used in conjunction
   with these other restricting mechanisms, it is intended to impose
   additional restrictions beyond those communicated in other
   techniques.

   In an offer, this means that a=rid "a=rid" lines, when combined with other
   restrictions on the media stream, are expected to result in a non-
   empty union.  For example, if image attributes are used to indicate
   that a PT has a minimum width of 640, then specification of "max-
   width=320" in an "a=rid" line that is then applied to that PT is
   nonsensical.  According to the rules of Section 7.2.2, 6.2.2, this will
   result in the corresponding "a=rid" line being ignored by the
   recipient.

   Similarly,

   In an answer answer, the a=rid "a=rid" lines, when combined with the other
   restrictions on the media stream, are also expected to result in a
   non-empty union.  If the implementation generating an answer wishes
   to restrict a property of the stream below that which would be
   allowed by other parameters (e.g., those specified in "a=fmtp" or
   "a=imgattr"), its only recourse is to remove the "a=rid" line
   altogether, as described in Section 7.3. 6.3.  If it instead attempts to
   constrain the stream beyond what is allowed by other mechanisms, then
   the offerer will ignore the corresponding "a=rid" line, as described
   in Section 7.4.

10. 6.4.

9.  Formal Grammar

   This section gives a formal Augmented Backus-Naur Form (ABNF)
   [RFC5234] grammar for each of the new media and rid-level "a=rid" attributes
   defined in this document.

   rid-syntax        = "a=rid:" rid-identifier SP rid-dir
                       [ rid-pt-param-list / rid-param-list ]

   rid-identifier    = 1*(alpha-numeric / "-" / "_")

   rid-dir           = "send" / "recv"

   rid-pt-param-list = SP rid-fmt-list *(";" rid-param)

   rid-param-list    = SP rid-param *(";" rid-param)

   rid-fmt-list      = "pt=" fmt *( "," fmt )
                        ; fmt defined in {{RFC4566}}

   rid-param         = rid-width-param
                       / rid-height-param
                       / rid-fps-param
                       / rid-fs-param
                       / rid-br-param
                       / rid-pps-param
                       / rid-bpp-param
                       / rid-depend-param
                       / rid-param-other

   rid-width-param   = "max-width" [ "=" int-param-val ]

   rid-height-param  = "max-height" [ "=" int-param-val ]

   rid-fps-param     = "max-fps" [ "=" int-param-val ]

   rid-fs-param      = "max-fs" [ "=" int-param-val ]

   rid-br-param      = "max-br" [ "=" int-param-val ]

   rid-pps-param     = "max-pps" [ "=" int-param-val ]

   rid-bpp-param     = "max-bpp" [ "=" float-param-val ]

   rid-depend-param  = "depend=" rid-list

   rid-param-other   = 1*(alpha-numeric / "-") [ "=" param-val ]

   rid-list          = rid-identifier *( "," rid-identifier )

   int-param-val     = 1*DIGIT

   float-param-val   = 1*DIGIT "." 1*DIGIT

   param-val         = *( %x20-58 / %x60-7E )
                       ; Any printable character except semicolon

11.

10.  SDP Examples

   Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in
   simulcast scenarios.

11.1.

10.1.  Many Bundled Streams using Many Codecs

   In this scenario, the offerer supports the Opus, G.722, G.711 and
   DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC
   (SCBP/SCHP) and H.265 (MP/M10P) for video.  An 8-way video call (to a
   mixer) is supported (send 1 and receive 7 video streams) by offering
   7 video media sections (1 sendrecv at max resolution and 6 recvonly
   at smaller resolutions), all bundled on the same port, using 3
   different resolutions.  The resolutions include:

   o  1 receive stream of 720p resolution is offered for the active
      speaker.

   o  2 receive streams of 360p resolution are offered for the prior 2
      active speakers.

   o  4 receive streams of 180p resolution are offered for others in the
      call.

   Expressing all these codecs and resolutions using 32 dynamic PTs (2
   audio + 10x3 video) would exhaust the primary dynamic space (96-127).
   RIDs are used to avoid PT exhaustion and express the resolution
   constraints.

   NOTE: The SDP given below skips few lines to keep the example short
   and focused, as indicated by either the "..." or the comments
   inserted.

                                       Example 1

   Offer:

   The offer for this scenario is shown below.

   ...
   m=audio 10000 RTP/SAVPF 96 9 8 0 123
   a=rtpmap:96 OPUS/48000
   a=rtpmap:9 G722/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:123 telephone-event/8000
   a=mid:a1
   ...
   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
   a=rtpmap:98 VP8/90000
   a=fmtp:98 max-fs=3600; max-fr=30
   a=rtpmap:99 VP9/90000
   a=fmtp:99 max-fs=3600; max-fr=30
   a=rtpmap:100 H264/90000
   a=fmtp:100 profile-level-id=42401f; packetization-mode=0
   a=rtpmap:101 H264/90000
   a=fmtp:101 profile-level-id=42401f; packetization-mode=1
   a=rtpmap:102 H264/90000
   a=fmtp:102 profile-level-id=640c1f; packetization-mode=0
   a=rtpmap:103 H264/90000
   a=fmtp:103 profile-level-id=640c1f; packetization-mode=1
   a=rtpmap:104 H264-SVC/90000
   a=fmtp:104 profile-level-id=530c1f
   a=rtpmap:105 H264-SVC/90000
   a=fmtp:105 profile-level-id=560c1f
   a=rtpmap:106 H265/90000
   a=fmtp:106 profile-id=1; level-id=93
   a=rtpmap:107 H265/90000
   a=fmtp:107 profile-id=2; level-id=93
   a=sendrecv
   a=mid:v1 (max resolution)
   a=rid:1 send max-width=1280;max-height=720;max-fps=30
   a=rid:2 recv max-width=1280;max-height=720;max-fps=30
   ...
   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
   ...same rtpmap/fmtp as above...
   a=recvonly
   a=mid:v2 (medium resolution)
   a=rid:3 recv max-width=640;max-height=360;max-fps=15
   ...
   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
   ...same rtpmap/fmtp as above...
   a=recvonly
   a=mid:v3 (medium resolution)
   a=rid:3 recv max-width=640;max-height=360;max-fps=15
   ...
   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
   ...same rtpmap/fmtp as above...
   a=recvonly
   a=mid:v4 (small resolution)
   a=rid:4 recv max-width=320;max-height=180;max-fps=15
   ...
   m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
   ...same rtpmap/fmtp as above...
   ...same rid:4 as above for mid:v5,v6,v7 (small resolution)...
   ...

   Answer:
   ...same as offer but swap send/recv...

11.2.

10.2.  Scalable Layers

   Adding scalable layers to the above simulcast example a session within a multiparty conference
   gives the SFU a selective forwarding unit (SFU) further flexibility to
   selectively forward packets from a source that best match the
   bandwidth and capabilities of diverse receivers.  Scalable encodings
   have dependencies between layers, unlike independent simulcast
   streams.  RIDs can be used to express these dependencies using the
   "depend" parameter.  In the example below, the highest resolution is
   offered to be sent as 2 scalable temporal layers (using MRST).

                                       Example 3

   Offer:
   ...
   m=audio ...same as Example 1 previous example ...
   ...
   m=video ...same as Example 1 previous example ...
   ...same rtpmap/fmtp as Example 1... previous example ...
   a=sendrecv
   a=mid:v1 (max resolution)
   a=rid:0 send max-width=1280;max-height=720;max-fps=15
   a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0
   a=rid:2 recv max-width=1280;max-height=720;max-fps=30
   a=rid:5 send max-width=640;max-height=360;max-fps=15
   a=rid:6 send max-width=320;max-height=180;max-fps=15
   a=simulcast: send rid=0;1;5;6 recv rid=2
   ...
   ...same m=video sections as Example1 previous example for mid:v2-v7...
   ...

   Answer:
   ...same as offer but swap send/recv...

12.

11.  Open Issues

12.1.  Name of

11.1.  Declarative SDP

   Section 7 describes the identifier

   The name 'rid' use of "a=rid" for declarative SDP.  This is provisionally used
   a pretty small amount of work, and is open for further
   discussion.

   Here are the few options that were considered while writing use of this
   draft
   o  CID: Constraint ID, which mechanism to
   describe how a sender is going to constrain a rather precise description stream does have some
   amount of what utility.  Is the text sufficient?  If not, do we are attempting want to accomplish.

   o  ESID: Encoded Stream ID, does not align well
   invest the work needed to make RID work with taxonomy which
      defines Encoded Stream declarative use cases?

   PROPOSAL: Keep the current text.

11.2.  Definition of bitrate

   Some questions have been raised as before RTP packetization.

   o  RSID or RID: RTP Stream ID, aligns better to whether we need a more formal
   description of bitrate than we currently use.

   If I read correctly, Magnus indicated that the definition in the
   document is consistent with taxonomy but very
      vague.

   o  LID: Layer ID, aligns TIAS, and believes it is sufficiently
   well defined.

   PROPOSAL: keep current definition that exists in description of "max-
   br".

11.3.  Escaping new constraint values

   The parameters on an "a=rid:" line are extensible.  The syntax for
   these is:

   rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]

   param-val         = *( %x20-58 / %x60-7E )
                       ; Any printable character except semicolon

   If an extension has values that can contain semicolons, they need an
   escaping mechanism.  Note that this is not an issue for any currently
   defined parameters, as they all take numeric values only.

   1.  Change extension syntax to only allow numeric values

   2.  Define a universal escaping mechanism for SVC with each layer all extensions to use

   3.  Leave this problem for the first extension parameter - if any -
       to define value in a separate
      stream, way that might allow a semicolon.  Note that
       this approach would allow the use of percent-style escaping
       (e.g., "%3B") but not for other SVC layerings or independent simulcast
      which is awkward to view backslash-style escaping (e.g., "\;"), as layers.

   o  EPT or XPT: EXtended Payload Type, conveys XPT.PT usage well, but
      may
       parsers that do not support the new constraint would interpret
       the embedded semicolon as a separator.

   PROPOSAL: Option #3

11.4.  Utility of max-width and max height

   Comment from Stephan Wenger: Are max-width and max-height actually
   useful controls?  Shouldn't max-fs be confused with PT, sufficient for example people may mistakenly think
      they can use any plausible
   uses?

   PROPOSAL: Keep max-height and max-width.  Implementation is well-
   defined and easily implemented.  At least one participant expressed
   support for these parameters at IETF 94 face-to-face meeting.

11.5.  Definition of max-fps

   Comment from Stephan Wenger: Would it in other places where PT would normally be used.

13.  IANA Considerations

13.1.  New RTP Header Extension URI

   This document defines a new extension URI in the RTP Compact Header
   Extensions subregistry of the Real-Time Transport Protocol (RTP)
   Parameters registry, according better to define max-fps as
   constraining the following data:

       Extension URI: urn:ietf:params:rtp-hdrext:sdes:rid
       Description:   RTP Stream Restriction Identifier
       Contact:       <mmusic@ietf.org>
       Reference:     RFCXXXX

13.2.  New SDES item

      RFC EDITOR NOTE: Please replace RFCXXXX with average over a second rather than the RFC number inverse of
      this document.

      RFC EDITOR NOTE: Please replace TBD with the assigned SDES
      identifier value.

   This document adds the MID SDES item
   smallest allowed interval between frames?

   PROPOSAL: Keep as currently defined.  The difference is subtle.  The
   only kinds of cases allowed by an average that aren't allowed by a
   minimum interframe interval are those such as sending no packets for
   most of a second, followed by a burst of 30 frames 1 ms apart, as
   part of a stream constrained to the 30 fps.  Such cases seem undesirable.

12.  IANA "RTCP SDES item
   types" registry as follows:

              Value:          TBD
              Abbrev.:        RID
              Name:           Restriction Identification
              Reference:      RFCXXXX

13.3. Considerations

12.1.  New SDP Media-Level attribute

   This document defines "rid" as SDP media-level attribute.  This
   attribute must be registered by IANA under "Session Description
   Protocol (SDP) Parameters" under "att-field (media level only)".

   The "rid" attribute is used to identify characteristics of RTP stream
   with in a RTP Session.  Its format is defined in Section 10.

13.4. 9.

12.2.  Registry for RID-Level Parameters

   This specification creates a new IANA registry named "att-field (rid
   level)" within the SDP parameters registry.  The rid-level "a=rid" parameters
   MUST be registered with IANA and documented under the same rules as
   for SDP session-level and media-level attributes as specified in
   [RFC4566].

   Parameters for "a=rid" lines that modify the nature of encoded media
   MUST be of the form that the result of applying the modification to
   the stream results in a stream that still complies with the other
   parameters that affect the media.  In other words, parameters always
   have to restrict the definition to be a subset of what is otherwise
   allowable, and never expand it.

   New parameter registrations are accepted according to the
   "Specification Required" policy of [RFC5226], provided that the
   specification includes the following information:

   o  contact name, email address, and telephone number

   o  parameter name (as it will appear in SDP)

   o  long-form parameter name in English

   o  whether the parameter value is subject to the charset attribute

   o  an explanation of the purpose of the parameter

   o  a specification of appropriate attribute values for this parameter

   o  an ABNF definition of the parameter

   The initial set of rid-level "a=rid" parameter names, with definitions in
   Section 6 5 of this document, is given below:

      Type            SDP Name                     Reference
      ----            ------------------           ---------
      att-field       (rid level)
                      max-width                     [RFCXXXX]
                      max-height                    [RFCXXXX]
                      max-fps                       [RFCXXXX]
                      max-fs                        [RFCXXXX]
                      max-br                        [RFCXXXX]
                      max-pps                       [RFCXXXX]
                      max-bpp                       [RFCXXXX]
                      depend                        [RFCXXXX]

   It is conceivable that a future document wants to define a RID-level
   parameter that contains string values.  These extensions need to take
   care to conform to the ABNF defined for rid-param-other.  In
   particular, this means that such extensions will need to define
   escaping mechanisms if they want to allow semicolons, unprintable
   characters, or byte values greater than 127 in the string.

      OPEN ITEM: Do we need to do more than this regarding escaping?

14.

13.  Security Considerations

   As with most SDP parameters, a failure to provide integrity
   protection over the a=rid "a=rid" attributes provides attackers a way to
   modify the session in potentially unwanted ways.  This could result
   in an implementation sending greater amounts of data than a recipient
   wishes to receive.  In general, however, since the "a=rid" attribute
   can only restrict a stream to be a subset of what is otherwise
   allowable, modification of the value cannot result in a stream that
   is of higher bandwidth than would be sent to an implementation that
   does not support this mechanism.

   The actual identifiers used for RIDs are expected to be opaque.  As
   such, they are not expected to contain information that would be
   sensitive, were it observed by third-parties.

15.

14.  Acknowledgements

   Many thanks to review from Cullen Jennings, Magnus Westerlund, and
   Paul Kyzivat.

16.

15.  References
16.1.

15.1.  Normative References

   [I-D.ietf-avtext-sdes-hdr-ext]
              Westerlund, M., Burman, B., Even, R.,

   [I-D.roach-avtext-rid]
              Roach, A., Nandakumar, S., and M. Zanaty, P. Thatcher, "RTP
              Header Extension for RTCP Source Description Items",
              draft-ietf-avtext-sdes-hdr-ext-02 Payload
              Format Constraints", draft-roach-avtext-rid-01 (work in
              progress), July
              2015. February 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, DOI
              10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
              RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
              2008, <http://www.rfc-editor.org/info/rfc5285>.

16.2.

15.2.  Informative References

   [I-D.ietf-avtext-rtp-grouping-taxonomy]
              Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
              B. Burman, "A Taxonomy of Semantics and Mechanisms for
              Real-Time Transport Protocol (RTP) Sources", draft-ietf-
              avtext-rtp-grouping-taxonomy-08 (work in progress), July
              2015.

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
              negotiation-23
              negotiation-25 (work in progress), July 2015. January 2016.

   [I-D.ietf-mmusic-sdp-simulcast]
              Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
              "Using Simulcast in SDP and RTP Sessions", draft-ietf-
              mmusic-sdp-simulcast-03 (work in progress), October 2015.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6236]  Johansson, I. and K. Jung, "Negotiation of Generic Image
              Attributes in the Session Description Protocol (SDP)", RFC
              6236, DOI 10.17487/RFC6236, May 2011,
              <http://www.rfc-editor.org/info/rfc6236>.

Authors' Addresses

   Peter Thatcher
   Google

   Email: pthatcher@google.com

   Mo Zanaty
   Cisco Systems

   Email: mzanaty@cisco.com

   Suhas Nandakumar
   Cisco Systems

   Email: snandaku@cisco.com

   Bo Burman
   Ericsson

   Email: bo.burman@ericsson.com

   Adam Roach
   Mozilla

   Email: adam@nostrum.com
   Byron Campen
   Mozilla

   Email: bcampen@mozilla.com