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

[Mitsuyuki Hatanaka <[e-mail]>]

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/[e-mail]/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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt