Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-11.txt

On 19 Dec 2007, at 02:44, Mitsuyuki Hatanaka wrote:
> We have submitted our revised internet draft as
> "draft-ietf-avt-rtp-atracx-family-11.txt".
> You'll be able to get it from the on-line Internet-Drafts directories.
>
> In this draft we modified the draft based on the issues which  
> Mr.Perkins pointed out in 24 Sept. (refer to: http:// 
> www.archivum.info/avt@ietf.org/2007-09/msg00066.html )

Thanks for making this update. Most of the issues I raised have now  
been addressed. I have some minor comments below, answering your  
questions.

>> (1) Section 4.5.2: The -10 draft adds a restriction that, when  
>> using multi-session streaming, the RTP sequence numbers should  
>> match across layers. Why is this? Since frames are identified by  
>> the RTP timestamp, I would think it better to align timestamps  
>> across layers.
>
> We understood that the identification of sequential number is not  
> appropriate in some condition of transmission. So we will not use  
> the sequence number but timestamps for the synchronization method.

This is correct, but doesn't mean identical timestamps should be used  
across the layers. Instead, it means the timestamps should be aligned  
across layers using the standard RTP mechanism (using the NTP  
timestamp to RTP timestamp mapping conveyed in RTCP SR packets). I  
suggest changing "For decoding synchronization, Timestamp of RTP  
header of both sessions shall be set the same value at the sender  
side" to "The two sessions must be synchronised using the information  
in RTCP SR packets to align the RTP timestamps".

>> (4) Section 5.3.1: The terminology in this section is  
>> inconsistent, with some parts using "packet" and some using  
>> "frame". Please update this to use "frame" throughout for  
>> consistency with the rest of the draft.
>
> We used the terminology of "frame" for "unit of audio encoding".  
> But we agree that the meaning of "packet" and "frame" are confused  
> and ambigious in the section, so we changed the description here in  
> order to clarify the meaning and the usage of "frame" and "packet".

This is much better now, except for the Continuous Flag. In this case  
it is not the packets that are fragmented, but the frame which is  
fragmented across a series of packets.

>> (7) Section 7.8: Please update the examples to be complete (valid)  
>> SDP files, rather than m= line fragments.
>
> We changed the m= line according to the consideration of (6), but  
> still it is not clear for us. Could you please give some more  
> advice if it is not enough for the completion of SDP files?

Since there are multiple sessions in some of these examples, they  
have to be complete valid SDP files, according to RFC 4566. That is,  
the examples need to include the v=, o=, s=, c= and t= lines too.

Finally, reference 12 probably needs to be a normative reference now,  
since it's required to signal the layered coding.

Regards,
-- 
Colin Perkins
http://csperkins.org/

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