Subject: [AVT] New draft-clark-avt-rtcpxr-video-00.txt

From: Alan Clark <[email-masked]>
Date: Thu, 05 Jan 2006 07:31:37 -0500

We submitted a new draft that describes an RTCP XR payload for video 
performance reports - formerly part of the RTCP XRbis draft.  This is a 
first pass and tries to deal with a number of practical issues with 
video transport, for example the potential use of FEC and different 
potential video transport layers (UDP or TCP with RTP/ MPEG TS, MPEG TS 
over RTP).

The draft can be found on the IETF site - we keenly await comments!!

URL  
http://www.ietf.org/internet-drafts/draft-clark-avt-rtcpxr-video-00.txt

Regards

Alan

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 18 Jan 2006 15:38:01 +0000

Alan,

On 5 Jan 2006, at 12:31, Alan Clark wrote:
> We submitted a new draft that describes an RTCP XR payload for  
> video performance reports - formerly part of the RTCP XRbis draft.   
> This is a first pass and tries to deal with a number of practical  
> issues with video transport, for example the potential use of FEC  
> and different potential video transport layers (UDP or TCP with  
> RTP/ MPEG TS, MPEG TS over RTP).
>
> The draft can be found on the IETF site - we keenly await comments!

My concern regarding both this and the high resolution VoIP metrics  
report blocks draft (draft-clark-avt-rtcphr-00.txt) is that  
signalling information is duplicated in RTCP as part of the RTCP HR  
configuration blocks. Have you considered including enough data to  
correlate an RTP flow with a signalling flow for offline analysis,  
rather than sending a partial duplicate of the signalling  
information? That would seem a cleaner fit to the RTCP model, and  
also more future proof (since you wouldn't need to revise the RTCP XR  
draft if the signalling changed).

Colin

---

From: Alan Clark <[email-masked]>
Date: Thu, 19 Jan 2006 18:37:13 -0500

Colin

I'll take a look at this - the intent with the "correlation ID" was to 
do what you suggest.  There is some duplicate information in some of the 
extended descriptions of payloads, which would also be present in SDP 
definitions within signaling protocols such as SIP, however since we 
can't rely on the signaling messages taking the same path as the RTP 
stream,  mid-stream monitoring systems may not be able to identify the 
codec type (e.g. if a dynamic payload type is used).

Regards

Alan

Colin Perkins wrote:

>> performance reports - formerly part of the RTCP XRbis draft.   This 
>> is a first pass and tries to deal with a number of practical  issues 
>> with video transport, for example the potential use of FEC  and 
>> different potential video transport layers (UDP or TCP with  RTP/ 
>> MPEG TS, MPEG TS over RTP).
>>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 20 Jan 2006 00:27:24 +0000

Alan,

On 19 Jan 2006, at 23:37, Alan Clark wrote:
> I'll take a look at this - the intent with the "correlation ID" was  
> to do what you suggest.  There is some duplicate information in  
> some of the extended descriptions of payloads, which would also be  
> present in SDP definitions within signaling protocols such as SIP,  
> however since we can't rely on the signaling messages taking the  
> same path as the RTP stream,  mid-stream monitoring systems may not  
> be able to identify the codec type (e.g. if a dynamic payload type  
> is used).

Indeed, I expect that mid-stream monitoring won't be able to  
determine the codec in an on-line basis. You'll need to correlate  
with the signalling later, if the signalling & media follow different  
paths. At some point you'll always need to do that, unless you convey  
full details of the SDP and SIP (or whatever control protocol used)  
signalling in-band. And I hope no-one is proposing to convey all  
those details in-band!

Colin