Subject: RE: [AVT] SDP signaling for RTCP XR format

From: Jose Rey <[email-masked]>
Date: Tue, 01 Apr 2003 17:54:36 +0200

Hi Magnus, 

please see my asnwers inline, I cut much of the text for readibility.

> 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 think Colin's comment solves this question:

	> 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

---
---

As to the behaviour in O/A model, I went over it again and this is what I got:

* answers to offers of cat1-params (sendonly from O->A): if present in response -> SHOULD be sent; if not present -> MAY be sent, whereby
 - this last MAY allows for undeclared use of any extension and, 
 - the SHOULD is based on the supposition that if both the offerer and answerer declare a cat1-param it is because it should be better(or even necessary) for the streaming session and will be used, otherwise the A could omit it. 

* answers to offers of cat2-params (sendonly from O->A): whether present in answer or not-> MAY be sent; 
- this is more flexible since the decision (and probably the benefit) on whether to use cat2-params lies at the receiver. A MUST would avoid sending an undeclared extension and also it cannot be assumed the sender is reporting on all extensions it supports. 

Moreover, it should be stated that answerer must have some mechanism to realize that if feedback of cat2 being sent doesn't not get an answer then it should stop doing so. Is this complete? Comments?

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

Ok, I was missing that.

>  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.
> 
Yes , the last sentence reflects my intention.

cheers,

José

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 02 Apr 2003 13:47:38 +0200

Hi Jose,

Comments below:

> - the SHOULD is based on the supposition that if both the offerer and answerer declare a cat1-param it is because it should be better(or even necessary) for the streaming session and will be used,…

Yes, I can agree with this. There is no significant harm in sending XR 
blocks that are not desired. However I think one should have a good 
motivation why one would not signal this. I would like to have some 
cautioning wording regarding the MAY. That one should have some reason 
why one sends them after all.

>- this is more flexible since the decision (and probably the benefit) on whether to use cat2-params lies at the receiver. A MUST would avoid sending an undeclared extension and also it cannot be ass…

I think one should make a firm distinction here. If one uses the SDP 
signaling and declares a cat-2 functionality in a offer, then the 
answerer knows that it supports the functionality. If not included a 
answerer MAY try but the situation is unknown. There is also need for a 
receiver of SDP to follow any declaration if present. To avoid this miss 
use of RTCP bandwidth any receiver of the SDP MUST follow the 
declaration that DLRR blocks SHALL NOT be sent.

>Moreover, it should be stated that answerer must have some mechanism to realize that if feedback of cat2 being sent doesn't not get an answer then it should stop doing so. Is this complete? Comments?
I agree, however I think this belongs in the section on the XR block 
definition. Stop sending timestamp reports if no one is answering. And 
don't send DLRR blocks unless someone is sending timestamp reports.

I think we are converging on intentions and what needs to be clarified. 
I will updated the text a republish it. However I suffer from a cold and 
do not know how much I can work. I will do my best to provide an 
 updated text as soon as possible.

Best Regards

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]

---

From: Jose Rey <[email-masked]>
Date: Wed, 02 Apr 2003 14:40:48 +0200

Hi Magnus,

see inline,

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2003 1:48 PM
> To: Jose Rey
> Cc: IETF AVT WG
> Subject: Re: [AVT] SDP signaling for RTCP XR format
> 
> 
> Hi Jose,
> 
> Comments below:
> 
> Jose Rey wrote:
> 
> >Hi Magnus, 
> >
> >
> >* answers to offers of cat1-params (sendonly from O->A): if 
> present in response -> SHOULD be sent; if not present -> MAY 
> be sent, whereby
> > - the SHOULD is based on the supposition that if both the 
> offerer and answerer declare a cat1-param it is because it 
> should be better(or even necessary) for the streaming session 
> and will be used, otherwise the A could omit it. 
> >  
> >
> 
> >* answers to offers of cat2-params (sendonly from O->A): 
> whether present in answer or not-> MAY be sent; 
> >- this is more flexible since the decision (and probably the 
> benefit) on whether to use cat2-params lies at the receiver. 
> A MUST would avoid sending an undeclared extension and also 
> it cannot be assumed the sender is reporting on all 
> extensions it supports. 
> >  
I am not sure I understand this paragraph. You want to prohibit it if not present in the offer? For that we should require that O always lists ALL of the extensions it supports, so that it makes no sense for A to request a cat-2 parameter. Makes this requirement sense? Also for other future cat-2 parameters? If 
 
> >Moreover, it should be stated that answerer must have some 
> mechanism to realize that if feedback of cat2 being sent 
> doesn't not get an answer then it should stop doing so. Is 
> this complete? Comments?
> >
> >  
> >

Yes.

>  updated text as soon as possible.

Don't worry, just get well first :)

cheers,

José

---

From: "Timur Friedman" <[email-masked]>
Date: Wed, 2 Apr 2003 21:22:29 +0200

> > don't send DLRR blocks unless someone is sending timestamp reports.

How would we define the time after which an application, having received no
DLRRs, should stop sending Timestamp Report blocks?  The time period seems
to me highly application dependent, and so best left out of the document.

Agreed that a DLRR block makes no sense in the absence of a Timestamp Report
block.

- Timur Friedman