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

From: Mitsuyuki Hatanaka <[email-masked]>
Date: Wed, 19 Dec 2007 11:44:10 +0900

Dear all,

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/[email-masked]/2007-09/msg00066.html )

> (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.

> (2) Section 5.2: In the definition of the marker bit usage, remove
> the text
>      "The details of usage SHALL be defined by the RTP profile used",
> since
>      this draft defines the usage itself.

Yes, we removed it.

> (3) Section 5.2: Add a note that the SSRC, CC, and CSRC fields are
> used as
>      defined in RFC 3550.

We added the description of SSRC, CC and CSRC fields which refers the
RFC 3550.

> (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".

> (5) Section 5.3.2.1: Please change "It provides..." to "This payload
> format
>      provides..." for clarity.

We changed the pointed sentence.

> (6) Section 7.6: How is multi-session transport signalled in SDP? The
>      mechanism in draft-schierl-mmusic-layered-codec-04.txt would seem
>      to be appropriate. Can you add some discussion, and a reference?

We introduced the new signalling mechanism according to the mannar of
draft text by Schierl, in order to clarify that the ATRAC Advanced Lossless
is a kind of structured coding.

> (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?

> (8) Section 8: Need to specify the top-level media types that are to be
>      registered, i.e. "Three new media subtypes, for audio/ATRAC3,
>      audio/ATRAC-X and audio/ATRAC-ADVANCED-LOSSLESS are requested..."

OK, we specified the top-level media types as you advised.

> Once these changes are made, I believe this draft will be ready for
> working group last call.

We are looking forward to be ready for it!

Best Regards,
Mitsuyuki Hatanaka

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 30 Dec 2007 18:25:32 +0000

On 19 Dec 2007, at 02:44, Mitsuyuki Hatanaka wrote:
> 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/[email-masked]/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.
>
> 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.
>
> 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/