Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

----- Original Message ----- 
From: "Glen Zorn" <glenzorn@gmail.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "xrblock" <xrblock@ietf.org>
Sent: Thursday, December 20, 2012 6:20 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> On 12/20/2012 03:48 PM, Qin Wu wrote:
>>> On 12/17/2012 09:04 AM, Qin Wu wrote:
>>> ...
>>>
>>>>>>> *Section 3.2* The description of the "jitter buffer nominal delay"
>>>>>>> says that "It is calculated based on the time for packets spent in
>>>>>>> the jitter buffer." How is it calculated?
>>>>>> [Qin]:It will be calculate based on the difference between the time
>>>>>> when the packet enter into the jitter buffer and the time when the
>>>>>> packet come out from jitter buffer. It is mostly up to specific
>>>>>> implementation and doesn't need to spell out.
>>>>> So it's OK if two different implementations produce different numbers
>>>>> from the same data?  That doesn't seem very interoperable, somehow.
>>>>> Maybe one problem I'm having with this is that the way the word
>>>>> "nominal" is used doesn't map to any definition of which I'm aware.
>>>> [Qin]: Suppose a lot of packets are receieved in one measurement interval. Some packets arrive very earlier, some packets arrive very late.
>>>> some packets arrive extractly on time. Nominal packet are referred to the packet that arrives exactly on time
>>>> Since they have the same reference measurement point, usually they will get the same result.
>>> Usually?
>> [Qin]: one update (-05) was done to clear this ambiguity based on recent comment
>> from Kevin who has the similar concern as you. The change is
>> replace "It is calculated based on the time for packets spent in the jitter buffer."
>> with "It is calculated based on the difference between the receipt time and the
>> playout time for the packet that arrives exactly on time."
>>
>> With this justification text, you will see different implementations will not produce different numbers.
> Doesn't that depend upon what the application defines "exactly on time" 
> to mean?

[Qin]: I think you can rely on the synchronization metadata at the RTP layer or TS layer (e.g., DTS/PTS ) to know whether the packet arrives on time.

>>
>>>> For the definition, you also can see the metric "jitter buffer nominal delay  " defined in RFC3611,section4.7.7.
>>> Thanks for the reference, but it raises more questions than it answers
>>> for me.   The draft appears to duplicate most, but not all, of the
>>> fields related to jitter buffers included in the VoIP Metrics Report
>>> Block defined in RFC 3611, but says nothing about its relationship to
>>> that RFC (i.e., if it obsoletes or updates RFC 3611).  So as it stands
>>> it looks like if "jitter buffer absolute maximum delay" is to be
>>> reported the VoIP Metrics Report Block needs to be sent anyway.  I'm
>>> assuming that this is intentional but I don't recall any discussion of
>>> it on the list.  Was I just not paying attention?   Is there a plan to
>>> obsolete RFC 3611 at some point in the future (say, when all the XR
>>> blocks defined therein have been sliced & diced into the currently
>>> fashionable tiny hunks)?  It's not in the charter...
>> [Qin]: The metric has been defined in RFC3611. However the block format to carry
>> this metric need to be re-specified so that we can make such metric block can be
>> applicable to more other RTP applications rather than VOIP application since VOIP metric
>> report doesn't look reusable for video application. I don't think RFC3611 needs to be obseleted.
> 
> So this block is for use with any real-time application _except_ VOIP?'

[Qin]: Not necessary, it can apply to VOIP since the block is defined in the generic way.

>>>>> ...
>>>>>
>> >
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock