Subject: RE: [AVT] RTCP XR

From: "Gamze Seckin" <[email-masked]>
Date: Fri, 11 Apr 2003 14:39:31 -0700

hi,

Regarding the draft rtcp xr, has there been an attempt/discussion to include any video/audio streaming quality metrics?

-gamze

-----Original Message-----
From: Alan Clark [mailto:[email-masked]]
Sent: Friday, April 11, 2003 2:04 PM
To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus
Westerlund'
Cc: 'IETF AVT WG'
Subject: RE: [AVT] SDP signaling for RTCP XR format

Timur, Colin, Steve

At the recent IETF meeting we agreed that the existing draft was getting fairly stable - there were some good detail points brought up during the AVT discussion however these were easily accomodated.  

We also agreed at the AVT meeting to include some simple SDP signaling at Magnus' request however felt at the time that this would be fairly straightforward and would not take much time.  The discussion on SDP appears to be getting much more involved than anticipated and there is no apparent end in sight.  

I would like to propose that we move to a final draft without SDP in order that we can reach closure.  In San Francisco we discussed the idea of creating a separate document to describe the use of SDP for negotiating reporting/ feedback for RTP XR, RTCP and other mechanisms.  This was suggested precisely because of some concern that the negotiation mechanism could get complex and that there were a wider variety of scenarios than anticipated .. which appears to be the case.

Regards

Alan Clark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Timur
Friedman
Sent: Wednesday, April 02, 2003 2:34 PM
To: Magnus Westerlund; Jose Rey
Cc: IETF AVT WG
Subject: Re: [AVT] SDP signaling for RTCP XR format

Magnus Westerlund wrote:

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

I agree that the signalling should allow each of these modes.  But also the
mode in which certain receivers calculate RTTs amongst themselves.  While
many applications might not use this mode, we do not want to unnecessarily
rule it out.

Here are two examples of when the mode could be used.  First, receivers
might measure RTTs amongst themselves as a prelude to some of them becoming
senders (multicast "repair servers", retansmitting lost packets, for
instance). Second, a network monitoring tool might wish to measure its RTT
to certain receivers.

- Timur Friedman

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

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

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 11 Apr 2003 17:39:46 -0400

The VoIP metrics could be applied to streaming video and audio.  For
streaming audio you would basically ignore the effects of delay and focus on
listening quality metrics.  

For streaming video the same approach can be used however it may be
advantageous to set the gmin value to say 128, due to the increased
sensitivity of video to packet loss.  There was some suggestion at the IETF
meeting to use the jitter buffer levels to provide feedback to the
transmitter and help to manage packet flows.

Regards

Alan Clark
Telchemy

-----Original Message-----
From: Gamze Seckin [mailto:[email-masked]]
Sent: Friday, April 11, 2003 5:40 PM
To: IETF AVT WG
Cc: [email-masked]; Timur Friedman; Colin Perkins; Stephen Casner;
Magnus Westerlund
Subject: RE: [AVT] RTCP XR 

hi,

Regarding the draft rtcp xr, has there been an attempt/discussion to include
any video/audio streaming quality metrics?

-gamze

-----Original Message-----
From: Alan Clark [mailto:[email-masked]]
Sent: Friday, April 11, 2003 2:04 PM
To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus
Westerlund'
Cc: 'IETF AVT WG'

Timur, Colin, Steve

At the recent IETF meeting we agreed that the existing draft was getting
fairly stable - there were some good detail points brought up during the AVT
discussion however these were easily accomodated.  

We also agreed at the AVT meeting to include some simple SDP signaling at
Magnus' request however felt at the time that this would be fairly
straightforward and would not take much time.  The discussion on SDP appears
to be getting much more involved than anticipated and there is no apparent
end in sight.  

I would like to propose that we move to a final draft without SDP in order
that we can reach closure.  In San Francisco we discussed the idea of
creating a separate document to describe the use of SDP for negotiating
reporting/ feedback for RTP XR, RTCP and other mechanisms.  This was
suggested precisely because of some concern that the negotiation mechanism
could get complex and that there were a wider variety of scenarios than
anticipated .. which appears to be the case.

Regards

Alan Clark

-----Original Message-----

- Timur Friedman

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Apr 2003 18:12:17 -0400

Hello;

Can you give references to the additional metric you have in mind ?

                                  Regards
                                  Marshall Eubanks

On Friday, April 11, 2003, at 05:39 PM, Alan Clark wrote:

> <winmail.dat>

T.M. Eubanks
Multicast Technologies, Inc.
e-mail : [email-masked]
http://www.multicasttech.com

  Our New Multicast Workshop :
  http://www.multicasttech.com/workshop
Test your network for multicast :
http://www.multicasttech.com/mt/