[AVT] [Fwd: Re: Review requested: draft-ietf-avt-rtp-toffset-04.txt]

Qiaobing was asked as a member of the AVT Review Team to comment on the 
toffset draft. I am assuming Qiaobing's consent to publish this to the 
list. There was some behind-the scenes discussion of these points that I 
will also forward. From now on, we will ensure a more efficient 
procedure by asking the review team to publish directly to the authors 
and the list.

Many thanks for your review, Qiaobing.

Qiaobing Xie wrote:
> Tom,
> 
> Here are my comments on the draft:
> 
> 1. I agree with the use case analysis in the draft and agree in general 
> this may be a useful extension.
> 
> 2. I would like to see a more crisp definition of the "transmission 
> timestamp" - what is it? Is it the time instance the first (or the last) 
> octet of the packet is put on the wire by the physical interface at the 
> RTP sender? Or is it the time instance the sending RTP stack passes the 
> fully assembled packet into the out-going buffer? Or, is it the time 
> instance the last media octet in the packet was assembled at the RTP 
> stack? and so on.
> 
> 3. The following statement in the draft:
> 
>    "In the RTP specification [RFC3550] it is implied that packets are
>     transmitted essentially in accordance with their RTP timestamps."
> 
> is a little misleading since RFC3550 only says:
> 
>    "The timestamp reflects the sampling instant of the first octet in
>     the RTP data packet."
> 
> I'd therefore suggest to say something like: "RFC 3550 does not specify 
> a transmission timestamp."
> 
> 4. The sentence:
> 
>    "When added to the RTP timestamp of the packet, it represents the
>     "effective" RTP transmission time of the packet, on the RTP
>     timescale."
> 
> seems to say that
> 
>    Adjusted RTP timestamp = RTP timestamp in RTP header +
>                             transmission offset
> 
> If so, it probably is helpful to spell this out clearly.
> 
> 5. If my understanding above (point 4) is correct, then I am confused 
> about the following statement:
> 
>     "The sign of the offset value depends greatly on the choice of the
>     initial mapping of RTP to NTP times.  In general, without scanning a
>     stream entirely it is not possible to ensure that this mapping would
>     keep all the offsets positive; therefore this specification allows
>     negative values."
> 
> Some more explanation would help.
> 
> 6. In section 4, it would help if more detail can be given on how to 
> "indicate the actual network jitter, excluding the source-introduced 
> jitter". An example calculation would help too.
> 
> regards,
> -Qiaobing
> 

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt