Subject: RE: [AVT] RTCP XR

From: "Gamze Seckin" <[email-masked]>
Date: Fri, 11 Apr 2003 17:07:02 -0700

Hi Marshall and all,

There are not many of them, but definitely worth separating them form the VoIP metrics for efficiency purposes.
We presented a set of parameters in 3gpp sa4 (in sa25 and sa25bis, documents 30008 and 30130, accessible via www.3gpp.org) in an collaborated work with 3 UK. Actually a new version is due end-of this month i can forward you the updated document/link soon. We proposed to send the information back over rtsp , but having an rtcp extension is also a valuable approach, we believe.

-g

Gamze Seckin, Ph.D. 
Director of Research 
Vidiator Technology (US) Inc., The multimedia technology company of Hutchison Whampoa Limited 
office:650.390.9989 x27 fax:650.390.9911 
This e-mail is a confidential communication. If you are not the intended recipient of this e-mail, please return the message to the sender and delete the original. Thank you.

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]]
Sent: Friday, April 11, 2003 3:12 PM
To: [email-masked]
Cc: Gamze Seckin; 'IETF AVT WG'
Subject: Re: [AVT] RTCP XR 

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:

>
> 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'
> 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
> <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/

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