Subject: [AVT] SDP signaling for RTCP XR format

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Mar 2003 16:36:10 +0100

Hi,

Below is an proposal for an chapter on SDP signaling in the RTCP XR 
format. Please provide any comments as soon as possible. This will be 
included in the next revision of the draft.

Best Regards

Magnus Westerlund

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

5. SDP Signaling

   This section defines a 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 configurations, like in SAP [s4] and RTSP [s5]. There
   exist other potential signaling methods, which are not defined here.

   The RTCP XR formats MAY be used without prior signaling. This is in
   line with other RTCP packet types and follows the normal rules as
   written in [7]. All the reporting blocks defined in this document can
   be used without prior signaling. If any future defined report block
   does not allow usage without signaling, so should be noted and
   motivated in its specification.

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 reporting format(s). This attribute can in the future
   be easily extended with new parameters to cover any new reporting
   formats.

   The RTCP XR format SDP attribute is defined as 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
             / rcv-ts
             / stat-sum
             / rcv-rtt
             / voip-stat
             / format-ext

   pckt-loss-rle = "rle-pckt" ["=" 1*DIGIT]
   dupp-rle      = "rle-dup" ["=" 1*DIGIT]
   rcv-ts        = "recv-ts" ["=" 1*DIGIT]
   stat-sum      = "stat-sum"
   recv-rtt      = "recv-rtt"
   voip-stat     = "voip-sum"
   format-ext    = non-ws-string

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

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

   The defined "rtcp-xr" parameters belong to two categories. The first
   category corresponds to reporting formats that simple reports on the
   RTP stream and related things. The second category is formats that
   perform some type of functionality, like the RTT measuring
   functionality for a RTP receiver. This functionality uses two
   different XR formats, that together provide the functionality.

   For category 1, the reporting formats, 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 category 1 parameters and their XR formats.

   The "rle-pckt", "rle-dup", and "recv-ts" parameters MAY all take
   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.

   Category 2, consist of the RTT measuring formats using 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.

5.2 Usage in Offer-Answer

   When having reporting formats, 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 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 category 1, 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 category 1 parameters for
   media streams with the "sendrecv" attribute to request that the
   offerer SHOULD send the corresponding XR formats from the offerer to
   the answerer.

   For media streams in offers with "recvonly" attribute the offerer MAY
   include a parameter to declare its capability of sending the
   corresponding XR formats. If the answerer includes a "rtcp-xr"
   attribute with an category 1 parameter the offerer SHOULD send the
   corresponding XR formats.

   For media streams with multicast destinations the inclusion of an
   rtcp-xr attribute with category 1 parameters means that any media
   recipient SHOULD send the corresponding XR formats in RTCP.

   For an SDP offer with media streams containing the "rtcp-xr"
   attribute with the "recv-rtt" parameter the offerer declares itself
   capable of receiving the "Receiver Timestamp Report Block" and send
   responses using the "DLRR Report Block". The answerer MAY also
   include the parameter (recv-rtt) and thereby declare its capability
   to receive and respond to the RTT measuring XR formats. The inclusion
   of the parameter does not require the receiver of an offer or answer
   to actually send any "Receiver Timestamp Report Block". Note that the
   usage of the Receiver Timestamp Report Block is only useful for a
   receiver only, as any media sender will have this functionality in
   the RTCP Sender Report packet type.

   For an SDP offer with media streams with multicast destinations
   containing the "rtcp-xr" attribute with the "recv-rtt" parameter the
   participants SHOULD respond with a "DLRR Report Block" to any
   received "Receiver Timestamp Report Block". A participant SHOULD NOT
   respond to a "Receiver Timestamp Report Block" if the parameter are
   not present in the offer. The answerer SHALL NOT add the "recv-rtt"
   parameter in a "rtcp-xr" attribute in any response for a media stream
   with multicast destination.

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 category 1
   parameter the receiver of this media stream SHOULD send the
   corresponding reports. If the attribute contains the "recv-rtt"
   parameter the recipient of the media stream MAY send "Receiver
   Timestamp Report Block". The receiver of an "Receiver Timestamp
   Report Block" SHOULD send a "DLRR Report Block" in response if and
   only if the "recv-rtt" parameter is present.

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

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

7. Security Considerations

   This document extends the RTCP reporting mechanism.  The security
   considerations that apply to RTCP reports also apply to XR reports.
   This section details the additional security considerations that
   apply to the extensions.

   The extensions introduce heightened confidentiality concerns.
   Standard RTCP reports contain a limited number of summary statistics.
   The information contained in XR reports is both more detailed and
   more extensive (covering a larger number of parameters).  The per-
   packet information contained in Loss RLE, Duplicate RLE, and
   Timestamp Report Blocks facilitates MINC inference of multicast
   distribution trees for RTP data packets, and inference of link
   characteristics such as loss and delay.  This inference reveals
   information that might otherwise be considered confidential to
   autonomous system administrators.  The VoIP Metrics Report Block
   provides information on the quality of ongoing voice calls.  Though
   such information might be carried in application specific format in
   standard RTP sessions, making it available in a standard format here
   makes it more available to potential eavesdroppers.

   No new mechanisms are introduced in this document to ensure
   confidentiality.  Standard encryption procedures can be used when
   confidentiality is a concern to end hosts.  Autonomous system
   administrators concerned about the loss of confidentiality regarding
   their networks can encrypt traffic, or filter it to exclude RTCP
   packets containing the XR report blocks concerned.

   Any encryption or filtering of XR report blocks entails a loss of
   monitoring information to third parties.  For example, a network that
   establishes a tunnel to encrypt VoIP Report Blocks denies that
   information to the service providers traversed by the tunnel.  The
   service providers cannot then monitor or respond to the quality of
   the VoIP calls that they carry, potentially creating problems for the
   network's users.  As a default, XR packets SHOULD NOT be encrypted or
   filtered.

   The extensions also make certain denial of service attacks easier.
   This is because of the potential to create RTCP packets much larger
   than average with the per packet reporting capabilities of the Loss
   RLE, Duplicate RLE, and Timestamp Report Blocks.  Because of the
   automatic bandwidth adjustment mechanisms in RTCP, if some session
   participants are sending large RTCP packets, all participants will
   see their RTCP reporting intervals lengthened, meaning they will be
   able to report less frequently.  To limit the effects of large
   packets, even in the absence of denial of service attacks,
   applications SHOULD limit the size of XR report blocks and employ the
   thinning techniques described in this document in order to fit
   reports into the space available.

   The usage of the SDP parameters defined affect the behavior of the
   RTCP XR format blocks. However the security implications are
   dependent on the report formats. Due to the fact that behavior can be
   changed by the SDP signaling, the SDP is RECOMMENDED to be
   authenticate to prevent tampering by intermediates.

References

   The references are divided into normative references and non-
   normative references.

Normative References

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," BCP 14, RFC 2119, IETF, March 1997.

   [s2] D. Crocker, P. Overell, "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, Internet Engineering Task Force,
   November 1997.

   [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
   TS 101 329-5 V1.1.1 (2000-11), November 2000.

   [s3] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
   RFC 2327, Internet Engineering Task Force, April 1998.

   [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
   Standards Process," best current practice BCP 11, RFC 2028, IETF,
   October 1996.

   [4] ITU-T, "The E-Model, a computational model for use in
   transmission planning," Recommendation G.107 (05/00), May 2000.

   [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2,
   RFC 1700, IETF, October 1994.

   [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
   Considerations Section in RFCs," best current practice BCP 26, RFC
   2434, IETF, October 1998.

   [s1] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
   Session Description Protocol (SDP)", RFC 3264, Internet Engineering
   Task Force, June 2002.

   [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
   transport protocol for real-time applications," RFC 1889, IETF,
   February 1996.

Non-Normative References

   [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J.
   Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The
   Use of End-to-End Multicast Measurements for Characterizing Internal
   Network Behavior," IEEE Communications Magazine, May 2000.

   [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
   measurement infrastructures using RTP," Proc. IEEE Infocom 2002.

   [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
   Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
   2001.

   [s4] M. Handley, C. Perkins, E. Whelan, "Session Announcement
   Protocol", RFC 2974, Internet Engineering Task Force, October 2000.

   [s5] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming
   protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
   1998.

   [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
   Control Framework for Heterogeneous Multicast Environments", Proc.

-- 

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

---

From: Jose Rey <[email-masked]>
Date: Thu, 27 Mar 2003 16:23:24 +0100

Hi Magnus,

I've got some comments/questions on your proposal...

1.- The term "RTCP XR format" to address the Loss RLE Report Block, Duplicate RLE ..., is not consistent with the rest of the draft. I prefer "XR blocks" which is used throghout the text.
2.- Just curious, why are the report blocks used without signalling? It would be helpful to include the reason for this in the draft (if it's not there already and I missed it)
3.- I like your classification of parameters because is needed afterwards to define the usage, however I don't understand your reasoning since both types of parameters define a functionality. Why not rename it to unilateral (category 1) and collaborative (category 2) or something alike? 
4.- Section 5.2 par. 5: This is a bit confusing. The receiver may declare its capability for the XR blocks and not send the report blocks themselves? Shouldn't it be that by declaring its capability is also declaring its willingness to use them? Or is it maybe because the receiver decides itself when to send (them dynamically during the session) them and thus might be that they are not needed at all? Does this make sense? Maybe is the text that confuses me.

thanks,

José

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Magnus
> Westerlund
> Sent: Wednesday, March 26, 2003 4:36 PM
> To: IETF AVT WG
> Subject: [AVT] SDP signaling for RTCP XR format
> 
> 
> Hi,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Mar 2003 09:57:00 +0200

Hi Jose,

Thanks for giving some comments, it helps improving the text quickly. 
Responses below:

>1.- The term "RTCP XR format" to address the Loss RLE Report Block, Duplicate RLE ..., is not consistent with the rest of the draft. I prefer "XR blocks" which is used throghout the text.

Yes, I agree that I may not have used a totally aligned language. It 
should be corrected.

>2.- Just curious, why are the report blocks used without signaling? It would be helpful to include the reason for this in the draft (if it's not there already and I missed it)
>

As I understand it the use case for having report blocks without 
signaling is that you know that you are using application foo. Foo has 
defined that we will use certain report blocks. Then it is not necessary 
to use the signaling, which may in fact not exist. Certain report blocks 
may be used to discover if the other end parts understand them. For 
example the RTT measurement can be tried a few times to see if any 
receiver responds to them.

>3.- I like your classification of parameters because is needed afterwards to define the usage, however I don't understand your reasoning since both types of parameters define a functionality. Why no…

Yes, good proposal. I will see what I can do about the text.

>4.- Section 5.2 par. 5: This is a bit confusing. The receiver may declare its capability for the XR blocks and not send the report blocks themselves? Shouldn't it be that by declaring its capability…

The text might not be the best. However the functionality provided is 
that only the receiver can choice to use the Receiver Timestamp Report 
Block or not. The other end does only need to know if the other end part 
actually understands them and will respond with a DLRR Report block. If 
the other ends does not understand it is wasted bandwidth.

Here one issue actually surface. Is it the right thing to restrict a 
receiver to not send DLRR report block unless the usage has been 
explicitly signaled in multicast? The reason why I see a need to 
restrict it is the potential to create enormous report blocks in large 
multicast groups. And the only result is that the different receivers 
will determine there RTT to other receivers which seems to be rather 
pointless in most application. It seems that you would in fact like to 
control this operation to a few different operation modes in multicast.
1. fully meshed, both senders and receivers return DLRR blocks.
2. Sender only, only senders return DLRR blocks.
3. functionality off, no one responds with DLRR blocks.

Should we define such a distinction in the signaling?

Best Regards

Magnus Westerlund

---

From: Jose Rey <[email-masked]>
Date: Mon, 31 Mar 2003 15:40:36 +0200

Hi Magnus,

please see inline:

> >2.- Just curious, why are the report blocks used without 
> signaling? It would be helpful to include the reason for this 
> in the draft (if it's not there already and I missed it)
> >
> 

I think such a reasoning should be included in the text. The problem I see is that if someone is not aware of this fact, he could just download the SDP description and start a session. Since the offerer might "secretly" need some category1 parameters which the answerer is (of course) not providing as he wasn't requested to do so, the reception would be probably not of good quality, thus making a total waste of bandwidth out of the whole procedure...

To solve this, why not declare some kind of attribute in SDP that defines the set of feedback messages that the application needs of?
> 
> >3.- I like your classification of parameters because is 
> needed afterwards to define the usage, however I don't 
> understand your reasoning since both types of parameters 
> define a functionality. Why not rename it to unilateral 
> (category 1) and collaborative (category 2) or something alike? 
> >
> 

Good.

> 
> >4.- Section 5.2 par. 5: This is a bit confusing. The 
> receiver may declare its capability for the XR blocks and not 
> send the report blocks themselves? Shouldn't it be that by 
> declaring its capability is also declaring its willingness to 
> use them? Or is it maybe because the receiver decides itself 
> when to send (them dynamically during the session) them and 
> thus might be that they are not needed at all? Does this make 
> sense? Maybe is the text that confuses me.
> >
> >  
> >
> 

I agree with the above. My comment was more that I think declarations in answers to category1-offers should be binding: if declared -> MUST be sent; if not declared -> MUST not be sent. Declarations in the offers just indicate the offerer SHOULD send them if supported, as it is now.
For the category2 parameters it is different, since it is the receiver that benefits from such metrics, thus: if declared in the answer-> MAY be sent; if not declared -> MUST NOT be sent because the answerer does not wish to have such metrics. This is valid both unicast and multicast. Is this also your view? Would this work with the Offer/Answer model?

> multicast groups.

I disagree with your last sentence: RRs only report on RTP packets, not on RTCP. Thus, the size of the RRs would be equal, whether XRs are sent or not. It is only the number of RTCP packets ("traditional" and XR) that would be different. Still... a waste of bandwidth if it is not needed for every session member to know the RTT to every other one ...

> And the only result is that the different receivers 

Yes, I find this useful. The third one would be the one without rtcp-xr attribute in the offer (if you assume declaration/omission is binding).

One more thing: how about the RTCP bandwidth sharing of the XR packets? how is, for example, the order of transmission defined relative to the "traditional" RTCP packets? I think this is not specified, a short comment would do like "the profile in use SHALL ensure that the RTCP bandwidth is equally shared by packets sent by this RTP server or sender".

cheers,

José

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Mar 2003 16:26:27 +0200

Hi Jose,

>I think such a reasoning should be included in the text. The problem I see is that if someone is not aware of this fact, he could just download the SDP description and start a session. Since the off…

Yes, I will try to clarify this. My intention is that the SDP parameters 
should be used if there is SDP signaling available for this application. 
The one exception is that application  foo always uses these reports. 
And since you are running the client for application foo it knows that 
it shall use the report formats.

>To solve this, why not declare some kind of attribute in SDP that defines the set of feedback messages that the application needs of?

You mean in the general case for like SDES information types, etc.?

>I agree with the above. My comment was more that I think declarations in answers to category1-offers should be binding: if declared -> MUST be sent; if not declared -> MUST not be sent. Declarations…

I think SHOULD is a good requirement levels for something that is simply 
information. If you have very good reason not to send a report format 
you should not be forced to do it. However you should have really good 
reasons before you don't. When it comes to the other direction I might 
be more willingly to adopt a MUST NOT send policy. The question is how 
you can make it work with the MAY at top level. Some better language may 
solve this. I also need to consider what implications this have in 
interactions with clients not understanding the attribute. Probably no 
problem as they will not send it. 

>For the category2 parameters it is different, since it is the receiver that benefits from such metrics, thus: if declared in the answer-> MAY be sent; if not declared -> MUST NOT be sent because the…

Yes, it is my view. So far I don't see any problems in Offer/Answer 
usage. Please think this trough one more time.

>I disagree with your last sentence: RRs only report on RTP packets, not on RTCP. Thus, the size of the RRs would be equal, whether XRs are sent or not. It is only the number of RTCP packets ("tradit…

No, I think you are missing one thing where the DLRR blocks can become 
enormous. If you are part of an ASM group with 100 participants and they 
all send the Receiver Timestamp block in there RTCP reports. Normally 
you will send on average at the same pace as all others. Therefore your 
DLRR response will contain 100 sources. As everybody is doing this the 
average RTCP size will be large.  Therefore the usage of  option 1 below 
seems to be limited to small groups. When using option 2 only a few out 
of all sending the Receiver Timestamp block actually answers with the 
delay information. Therefore only the sender reporting will be effected 
by this.

>One more thing: how about the RTCP bandwidth sharing of the XR packets? how is, for example, the order of transmission defined relative to the "traditional" RTCP packets? I think this is not specifi…
Are you meaning the sharing of bandwidth between different RTCP packet 
types? And also within a XR packet that the different blocks are sent 
not all the time? The first problem is that the RTCP compound packet can 
reach the MTU and some packets has to be excluded. I think round robin 
in that case is a reasonable strategy if not defined elsewhere. This 
would mean equal share for all non mandatory packets. I think the same 
strategy can be used within a XR packet to ensure that all types of 
report blocks may send. However looking at the block types that can be 
sent that has variable size I has proposed a way of limiting the packet 
size. I think such a limitation should also be possible to defined for 
the DLRR packet.
 I hesitant to write policy that actually is application or profile 
dependent. However defining a default behavior I find acceptable with a 
side note that this can be replaced by application or profile 
specifications.

Best Regards

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 31 Mar 2003 10:46:44 -0500

--> Magnus Westerlund writes:
...
>>2.- Just curious, why are the report blocks used without signaling? It
>>would be helpful to include the reason for this in the draft (if it's not
>>there already and I missed it)
>

RTP allows applications to send new types of RTCP packet, even if these are
not explicitly signalled. RTCP XR shouldn't impose additional restrictions.

Colin

---

From: "Timur Friedman" <[email-masked]>
Date: Mon, 31 Mar 2003 21:00:57 +0200

> not explicitly signalled. RTCP XR shouldn't impose additional
restrictions.

The draft will be sure to specify that SDP signalling is an optional
mechanism, to avoid any confusion.

- Timur