Subject: [AVT] RTCP XR updated SDP section.

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Apr 2003 17:58:23 +0200

Hi,

Here is an updated text of the SDP signaling of the RTCP XR format. 
Please read and comment. I think that I have addressed the comments I 
received. I am sorry that I has taken this time but I have been ill.

Best Regards

Magnus.

----------------------------------

5. SDP Signaling

   This section defines an SDP attribute that can be used for signaling
   in applications utilizing SDP [s3].  This is signaling is defined to
   be used with Offer-Answer [s1] and for applications using SDP to
   describe media and transport configurations, like in SAP [s4] and
   RTSP [s5]. There exist other potential signaling methods, which are
   not defined here.

   The XR blocks MAY be used without prior signaling.  This is in line
   with other RTCP packet types and follows the normal rules as written
   in [7]. Reasons for this can be an application that requires that one
   or more XR block is always used.  This may require the application to
   define this, if all implementations of this application must work in
   the same way. However for applications that is configured at session
   initiation, the use of some type of signaling is RECOMMENDED.  If any
   future defined report block does not allow usage without signaling,
   so should be noted and motivated in its specification.

   If an application is using the SDP signaling defined here it needs to
   be done as defined below.  It is the usage of SDP for signaling the
   are optional, not if one is going to follow it or not, if used.  If
   SDP signaling is used in an environment where XR blocks are only
   implemented by some fraction of the participants, the one's not
   implementing the XR blocks will ignore the SDP attribute.

5.1 The SDP attribute

   This section defines one new SDP attribute "rtcp-xr" that can be used
   to signal the participants in a media session that it should utilize
   any specified XR block(s).  This attribute can in the future be
   easily extended with new parameters to cover any new reporting
   formats.

Friedman et al.             Standards Track            FORMFEED[Page 32]

Internet-Draft                  RTCP XR                     2 March 2003

   The RTCP XR format's SDP attribute is defined below in ABNF [s2].  It
   is an session and media level attribute.  When specified at session
   level it applies to all media blocks part of the session.  Any media
   level specification MUST replace an session level specification, if
   present, for that media block.

   rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF

   xr-format = pckt-loss-rle
             / dupp-rle
             / recv-ts
             / stat-sum
             / rcv-rtt
             / voip-stat
             / format-ext

   pckt-loss-rle = "rle-pckt" ["=" max-size]
   dupp-rle      = "rle-dup" ["=" max-size]
   recv-ts       = "recv-ts" ["=" max-size]
   stat-sum      = "stat-sum"
   recv-rtt      = "recv-rtt" "=" recv-rtt-mode [":" max-size]
   voip-stat     = "voip-sum"
   max-size      = 1*DIGIT ; Maximum block size in bytes
   recv-rtt-mode = "all"
                 / "sender"
   format-ext    = non-ws-string

   non-ws-string = 1*(%x21-FF)

   The "rtcp-xr" attribute contains zero, one or more XR block related
   parameter.  Each parameter defines its own interpretation as this
   will depend on the XR block(s).  The attribute is extensible so that
   any future XR block can define its own parameter(s).  There may be XR
   blocks where an "rtcp-xr" parameter is not applicable.  However, for
   any future defined formats the need of a parameter SHALL be
   evaluated.

   The defined "rtcp-xr" parameters belong to two categories.  The first
   category, the unilateral parameters,  corresponds to reporting blocks
   that simple reports on the RTP stream and related things.  The second
   category, collaborative parameters, represents XR block(s) that
   requires more than one party to perform an action to accomplish the
   functionality, like the RTT measuring functionality for a RTP
   receiver. These collaborative functionalities MAY use two or more
   different XR blocks, that together provide the functionality.

Friedman et al.             Standards Track            FORMFEED[Page 33]

Internet-Draft                  RTCP XR                     2 March 2003

   For the unilateral category, this document defines the following
   parameters.  The parameter names and their corresponding XR format is
   given in table 1.

   Parameter name    XR format (Nr and Name)
   --------------------------
   rle-pckt          1  Loss RLE Report Block
   rle-dup           2  Duplicate RLE Report Block
   recv-ts           3  Timestamp Report Block
   stat-sum          4  Statistics Summary Report Block
   voip-sum          7  VoIP Metrics Report Block

   Table 1. The unilateral parameters and their XR formats.

   The "rle-pckt", "rle-dup", and "recv-ts" parameters MAY specify an
   integer value.  This value indicates the largest size the whole
   report block SHOULD have in bytes.  This shall be seen as an
   indication that thinning shall be applied if necessary to meet the
   target size.

   Any functionality belongs to the collaborative category, if it
   consist of one initiator block, and one or more types of response
   blocks. The functionality SHOULD include signaling to indicate which
   receivers that are required to respond to the initiator block.

   The collaborative category, currently consist only of the RTT
   measuring for RTP receivers functionality, which uses the XR formats
   "Receiver Timestamp Report Block" (5) and "DLRR Report Block" (6).
   These two formats and their functionality is represented by the
   "recv-rtt" parameter.  This parameter takes first a mode value and
   optionally a maximum size for the DLRR report block.  The mode
   values: "all" indicates that both RTP senders and receivers MAY send
   DLRR blocks. "sender" indicates that only active RTP senders MAY send
   DLRR blocks, i.e. non RTP senders SHALL NOT send DLRR blocks. If a
   maximum size in bytes is included any sent DLRR block SHALL NOT
   exceed the given size. The DLRR block sender SHOULD report on
   different timestamp sources in a round robin fashion if not all
   sources can be reported on due to size limitations.

   Any XR-block not represented in the parameter list of the attribute
   SHALL NOT be sent.  This is required so that bandwidth is not wasted
   and may be specially important for collaborative parameters, where a
   initiator block otherwise could trigger responses from all
   participants in a large multicast group.

   The "rtcp-xr" attributes parameter list MAY be empty.  This is useful

Friedman et al.             Standards Track            FORMFEED[Page 34]

Internet-Draft                  RTCP XR                     2 March 2003

   in cases where one needs to signal that one understands the SDP
   signaling but do not want to use any of the XR functionality.  One
   such example could be a SIP controlled session where one want to stop
   using all XR blocks and therefore remove all parameters in the re-
   invite's SDP.  If one do not desire to use any XR blocks from the
   beginning it is RECOMMENDED that one does not include the "rtcp-xr"
   attribute at all.

5.2 Usage in Offer-Answer

   When having reporting blocks, it is in the interest of the sender of
   media, to request that the receiver sends reports on this media
   stream. However the interpretation will be dependent on any direction
   attribute. In the below definition, text applying for media stream
   with "sendrecv" attributes does also apply to media streams without
   any direction attribute.  The definitions apply only for media
   streams with a unicast destination, unless otherwise noted.

   For media streams in offers with a "sendonly" or a "sendrecv"
   attribute the inclusion of "rtcp-xr" attributes with parameters
   belonging to the unilateral category, has the interpretation that the
   receiver of the offer SHOULD send the XR formats corresponding to the
   parameter to the sender of these streams.  When doing the answer the
   answerer MAY include the "rtcp-xr" attribute with any unilateral
   parameter for media streams with the "sendrecv" attribute to request
   that the offerer SHOULD send the corresponding XR blocks from the
   offerer to the answerer.

   For media streams in offers with "recvonly" attribute the offerer MAY
   include any unilateral parameters, this declare its capability of
   sending the corresponding XR block.  If the answerer includes a
   "rtcp-xr" attribute with an unilateral parameter the offerer SHOULD
   send the corresponding XR block.

   For media streams with multicast destinations the inclusion of an
   "rtcp-xr attribute with any unilateral parameters means that any
   media recipient SHOULD send the corresponding XR block(s).

   For an SDP offer with media streams containing the "rtcp-xr"
   attribute with an collaborative parameter, like "recv-rtt", the
   offerer declares itself capable of receiving the indicated initiator
   ("Receiver Timestamp Report Block") and send responses using the
   responder block ("DLRR Report Block").  This means that the offerer
   has offered a situation where: The answerer MAY send the indicated
   initiator and the offerer SHOULD send the response block(s) if an
   initiator is received. The sending of a response can be preveted, as
   the offerer may not belong to the group that has been declared by the
   parameter to be allowed to send. The response may also be prevented

Friedman et al.             Standards Track            FORMFEED[Page 35]

Internet-Draft                  RTCP XR                     2 March 2003

   by other factors, like congestion control or MTU.  The Answerer MAY
   include a collaborative parameter, like "recv-rtt" in the answer, and
   thereby declare its capability to receive and respond according to
   the indicated functionality.  If a collaborative functionality is
   declared by the Answerer the Offerer MAY send the initiator block to
   the Answerer and the Answerer SHOULD receive the initiator block and
   send the corresponding response block(s).

   For an SDP offer with media streams with multicast destinations
   containing the "rtcp-xr" attribute with an collaborative parameter,
   the parameter needs to indicate which participants that should
   respond to a received initiator.  A SDP offerer according to above
   has the interpretation that the indicated participants SHOULD send a
   response if a initiator is received.  A participant MAY send a
   initiator block.  A participant not indicated to respond for a
   functionality SHALL NOT send any response.  The answerer to a session
   with multicast destination SHALL NOT include any collaborative
   parameters in the response.

   If one receives an SDP offer and understands the "rtcp-xr" attribute
   but does not want to use any XR functionality or it does not apply in
   the answer, the answerer SHOULD include an "rtcp-xr" attribute
   without parameters.  This allows a party to declare capability to
   understand the signaling, and not request any functionality.

5.3 Usage out-side of Offer/Answer

   This applies to the usage of SDP that is currently defined in SAP and
   RTSP where SDP is used to declare what applies for a multi-media
   presentation.  This SDP applies to how a receiver of these media
   streams shall behave to receive the media and under what rules.
   Therefore the usage of the "rtcp-xr" format is simpler in this case
   then compared to offer/answer, however the functionality goal is the
   same.

   For media streams having the "rtcp-xr" attribute with any unilateral
   parameter, the receiver of this media stream SHOULD send the
   corresponding XR block.  If the attribute contains a collaborative
   parameter, the participants indicated by the collaborative parameter
   SHOULD send the response blocks, if the functionalities initiator
   block is received. A session participant MAY send initiator block if
   the collaborative parameter indicates that any participants will send
   responses.

   When the "rtcp-xr" attribute is present no other XR blocks than the
   ones indicated by parameters to the attribute SHALL be used.  This
   means that inclusion of a "rtcp-xr" attribute without any parameter,
   tells a participant that he SHALL NOT send any XR blocks at all.

Friedman et al.             Standards Track            FORMFEED[Page 36]

Internet-Draft                  RTCP XR                     2 March 2003

6. IANA Considerations

   This document defines a new RTCP packet type, the extended report
   (XR) type, within the existing Internet Assigned Numbers Authority
   (IANA) registry of RTP RTCP Control Packet Types.  This document also
   defines a new IANA registry: the registry of RTP XR Block Types.
   Within this new registry, this document defines an initial set of
   seven block types and describes how the remaining types are to be
   allocated.  Further this document defines a new SDP attribute
   "a=rtcp-xr" to be registered, and for its parameters a IANA registry
   is defined.

6.1 XR Packet Type

   The IANA SHALL register the RTP extended report (XR) packet defined
   by this document as packet type 207 in the registry of RTP RTCP
   Control Packet types (PT).

6.2 RTP XR Block Type Registry

   The IANA SHALL create the RTP XR Block Type Registry to cover the
   name space of the extended report block type (BT) field specified in
   Section 3 of this document.  The BT field contains eight bits,
   allowing 256 values.  The IANA SHALL manage the RTP XR Block Type
   Registry according to the Specification Required policy of RFC 2434
   [6].  Future specifications SHOULD attribute block type values in
   strict numeric order following the values attributed in this
   document:

      BT  name
      --  ----
       1  Loss RLE Report Block
       2  Duplicate RLE Report Block
       3  Timestamp Report Block
       4  Statistics Summary Report Block
       5  Receiver Timestamp Report Block
       6  DLRR Report Block
       7  VoIP Metrics Report Block

   The BT value 255 is reserved for future extensions.

   Furthermore, future specifications SHOULD avoid the value 0.  Doing
   so facilitates packet validity checking, since an all-zeros field
   might commonly be found in an ill-formed packet.

6.3 The "rtcp-xr" SDP attribute

Friedman et al.             Standards Track            FORMFEED[Page 37]

Internet-Draft                  RTCP XR                     2 March 2003

   One SDP attribute is to be registered using the below information:

   SDP Attribute ("att-field"):

     Attribute name:     rtcp-xr
     Long form:          RTP Extended Report Parameters
     Type of name:       att-field
     Type of attribute:  Session and Media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document and registrations below

   The attribute has an extensible parameter field and therefore a
   registry for these parameters are needed.  IANA is requested to
   create one "rtcp-xr" SDP parameter registry and register the defined
   values. This registry is managed according to the Specification
   Required policy of RFC 2434.  Any registration MUST contain the
   following information:

   - Contact information of the one doing the registration, including at
     least name, address, and email.

   - An ABNF definition of the parameter, in accordance with the
     "format-ext" definition.

   - A description of what the parameter represents and how it shall be
     interpreted, both normally and in Offer/Answer.

   This document registers the six parameters defined in chapter 5.1,
   "rle-pckt", "rle-dup", "recv-ts", "stat-sum", "voip-sum", and "recv-
   rtt".

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt