Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-01.txt
Randell Jesup <rjesup@wgate.com> Mon, 03 December 2007 18:58 UTC
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGVJ-0007nK-Cg; Mon, 03 Dec 2007 13:58:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGVI-0007lN-Bh for avt@ietf.org; Mon, 03 Dec 2007 13:58:52 -0500
Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGVH-0002g0-Rc for avt@ietf.org; Mon, 03 Dec 2007 13:58:52 -0500
Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 13:58:51 -0500
To: Alan Clark <alan.d.clark@telchemy.com>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-01.txt
References: <20071203162932.1924A4DC002@mail.globalsuite.net>
From: Randell Jesup <rjesup@wgate.com>
Date: Mon, 03 Dec 2007 13:58:50 -0500
In-Reply-To: <20071203162932.1924A4DC002@mail.globalsuite.net> (Alan Clark's message of "Mon, 3 Dec 2007 11:27:35 -0500")
Message-ID: <ybufxyjd2qd.fsf@jesup.eng.wgate.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 03 Dec 2007 18:58:51.0815 (UTC) FILETIME=[8B6B8370:01C835DE]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: 'Colin Perkins' <csp@csperkins.org>, 'AVT WG' <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Randell Jesup <rjesup@wgate.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org
"Alan Clark" <alan.d.clark@telchemy.com> writes: >>Why is Round Trip Time reported - can't this be derived from RTCP SR/ RR >>packets?/ > >I agree that endpoints can do this. It is non-trivial for any midpoint >system (e.g. a probe or router) to calculate RTD from SR/RR and requires the >capture of a series of SR/RR exchanges, maintaining state etc. This is a valid point - it's hard to calculate if you're not an endpoint; various types of midboxes can use this info, and it can be useful for overall network-health monitoring. I've seen it proposed (in the area of RFC 3611) recently (and also via end-of-call SIP PUBLISH). I should note that RFC 3611 also reports delays in ms (section 4.7.3), using RTCP NTP times per the normal spec for DLRR/etc. >>The playout buffer metrics seem very similar to the jitter buffer metrics >>defined in RFC 3611. Can't the existing metrics be reused? > >The main issues are: > >(i) Size - playout buffers can be much larger, potentially 10's of seconds Greater than 65 seconds? That's how long the jitter buffer params in 3611 can cover (16 bits at 1ms/per). >(ii) The playout metrics allow problems such as playout interruptions due to >buffer starvation in TCP based systems to be monitored. That may be useful, depending on definition (note: I haven't read the spec to see how this is defined/transmitted). >>Why is there a need to signal the measurement interval? The baseline RTCP >>reports operate on the interval since the last report - is that not simpler? > >This requires monitoring systems to recognize sequential RTCP reports, would >not deal properly with lost RTCP reports, and for midpoint systems would >cause problems if routes changed. I don't think this adds siginificant complexity, at least not the sequential aspect. The RTCP has info that lets you know the sequence numbers/timestamps received/transmitted, and the time and period. It's easy to figure out if an RTCP was "lost", just by retaining the last one (see note). However, whether the period is fixed or not, what does a midbox/etc do if an RTCP is lost anyways? How is this really different (let alone tough) if the packets are of variable length? (Note: in AVPF scenarios, you can get a number of RTCPs sent in a very short period, and *in theory*, they could be received out-of-order due to route-flapping, etc. Something to realize can happen, even if it's rare. The simplest solution (depending on what you use RTCP for) is to ignore the "stale" out-of-order RTCP as if it were lost.) >>Why are intervals measured in milliseconds, rather than RTCP timestamp >>units? The use of milliseconds seems to require an additional clock at the >>receiver. > >Really just convenience - this does not require an additional clock, just >some simple math. It also means that if the RTP clock rate associated with >the stream changed, or the video clock rate was different to the audio clock >rate, it may be complex for any entity other than the endpoint to figure out >what the interval was. There still is confusion over RTP streams switching timestamps - whether it's really allowed (it appears to be), and the side-effects (very confusing for RTCP, and other things): Random example (I probably have the G722 media type wrong): m=audio 2345 RTP/AVP 0 99 a=rtpmap:0 PCMU/8000 a=rtpmap:99 G722/16000 This means the timestamp rate can change at any point, on a packet-by-packet basis. It's even theoretically allowable to alternate G711 and G722 packets. Totally odd and non-useful, but it illustrates the point. More realistic is a change from one to the other half-way through an RTCP monitoring period. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-01.t… Internet-Drafts
- RE: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Schwarz Albrecht
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Colin Perkins
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Colin Perkins
- RE: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Alan Clark
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Randell Jesup
- RE: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Alan Clark
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Randell Jesup
- RE: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Schwarz Albrecht
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Randell Jesup
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-… Colin Perkins