Re: [AVT] comments on draft-ietf-avt-rfc3189bis-04

[Kazuhiro Mishima <[e-mail]>]

Hi,
Roni and all

I send my answer for your comments.
If there are no problem, we'll update our draft soon.

1.       In section 1 you mention version 2 of RTP. RFC 3550 is not
version 2 . Just delete the version 2

I'll delete it.

2.       In section 2.2 you mention VAUX and AAUX what are these.

VAUX is "Video Auxiliary information". AAUX is "Audio Auxiliary data".
These are mentioned in sec.1.2 (encoding format's termiology).

3.       In Section 2.2 you have the following paragraph " In the case
of unbundled transmission where both audio and video are sent in the
DV format, the same timestamp SHOULD be used for both  audio and video
data within the same frame to simplify the lip   synchronization
effort on the receiver.  Lip synchronization may also  be achieved
using reference timestamps passed in RTCP as described in  RFC 3550."
In the previous paragraph you recommend sending the audio not as a DV
format  in the unbundled case so when do you send it as DV format.

This description is for having no choice but to use DV for audio stream.
I'll change it to "In the case of unbundled transmission which is
compelled to use both audio and video in the DV format".

4.       In the same paragraph you suggest using the same timestamp
for the audio so does it mean that the audio clock will be 90Khz and
the timestamp behave as the video. Please clarify.

Yes. I'll add "In this case, the audio stream uses the 90kHz clock
rate, and  the timestamp as the video." description.

5.       In section 3.1 in the registration you give as reference for
the audio and video SMPTE 314M (for backward compatibility). I assume
you meant 306M

It' my mistake, I'll change to 306M.

6.       In 3.1.2 in the audio registration you have audio as an
optional parameter. I assume you do not need it. It is not appear in
RFC3189

In RFC3189, the audio registration is shown in sec.5.2.
I want to keep its description.

7.       In 3.1.2 in the encoding consideration you have DV video, you
meant DV audio

I'll change it.

8.       In 3.2.1 I suggest changing the 3rd paragraph to "Note that
the examples in RFC3189 (older version of this document)  provides
incorrect SDP "a=fmtp" attribute usage."

OK. I'll change it.

9.       In 3.2.1 when you explain the syntax of the audio parameter I
suggest "a=fmtp:<payload type> encode=<DV-video encoding>;
audio=<audio bundled>" since encode is a required parameter.

I agree with it. I'll change it.

10.   In section 3.2.2 first paragraph the reference to offer answer
is RFC 3264 and not SDP

It's my mistake. I'll change it.

11.   In 3.2.2 first bullet and in the section you use bi-directional,
mono directional and multicast. The terms use in offer answer are
sendrecv, sendonly and recvonly. By multicast I assume you mean
declarative SDP since multicast can be used also in offer/answer mode.
I suggest changing the first bullet to  " The "encode" parameter can
be used for sendRecv, sendonly and recvonly streams.  each encode type
MUST use a separate payload type number" because of the terminology
and because each encoding parameter requires a separate payload type
number so the receiver do not get one payload type number with
multiple encodings but multiple payload type numbers from which is
need to select.

I agree with it. I'll change it.

12.   In section 3.2.2 the third bullet "The optional "audio"
parameter is only used for the bundled stream.  On the offerer sets a
audio bundled type on a=fmtp field,  then the answerer MUST select
whether the DV stream should be  included audio data or not, and reply
with selected value." . I am not sure what you meant here. Do you mean
that if the offer include audio=bundled the answer can delete it. What
will be the result, how will the audio be sent in this case. My
thought is that if the answer do not want bundled audio he should
reject the stream. The offer can send a separate offer with DV video
without audio and a separate audio stream.

In this case, this description is not appropriate. So I'll delete this bullet.

13.   When you have the audio unbundled. How do you associate between
the audio and video in the offer for lip-synch. For example if there
is more than one video or audio stream. I suggest you use grouping in
the example look at RFC3388 using LS semantics

I'll add this notice, "In order to associate between the audio and
video in the offer for unbundled stream, Grouping of Media Lines in
SDP [cite for RFC3388] can be used for description.".
14.   In section 3.2.2 last bullet discuss multicast. If you meant
declarative SDP (for example for streaming applications) this bullet
is redundant and can be deleted

OK. I'll delete it.

15.   In section 5  you discuss multiple frames in one packet. I think
that this cannot happen for DV video.

I'll update it to fix the multiple-frames description.

16.   In the IANA consideration, this is not a new payload subtype
name. this registration updates the DV registration from RFC 3189

I'll update the draft to add the description that this consideration is
just *update*, not for new registration.

17.   In section 8 on interoperability with older systems I think that
it will be good to explain that an offer may include SMPTE306M
encoding coming from a legacy system and that the receiver should
support it. It also need to address the other case where the offer
does not include SMPTE306M since it is using this draft and the
answerer reject the offer. The offerer may try a new offer with
SMPTE306M.

Since rejecting the 1st offer does not include SMPTE306M, the offerer
may try a new offer with SMPTE306M. For this case, an RTP application
MAY handle a stream identified as SMPTE314M encoding instead of as
SMPTE306M one.

Best regards,
Kazuhiro


2010/4/30 Roni Even <[e-mail]>:
> Hi,
>
> I read the draft and have some comments
>
>
>
> 1.       In section 1 you mention version 2 of RTP. RFC 3550 is not version
> 2 . Just delete the version 2
>
> 2.       In section 2.2 you mention VAUX and AAUX what are these.
>
> 3.       In Section 2.2 you have the following paragraph " In the case of
> unbundled transmission where both audio and video are sent in the DV format,
> the same timestamp SHOULD be used for both  audio and video data within the
> same frame to simplify the lip   synchronization effort on the receiver.
> Lip synchronization may also  be achieved using reference timestamps passed
> in RTCP as described in  RFC 3550." In the previous paragraph you recommend
> sending the audio not as a DV format  in the unbundled case so when do you
> send it as DV format.
>
> 4.       In the same paragraph you suggest using the same timestamp for the
> audio so does it mean that the audio clock will be 90Khz and the timestamp
> behave as the video. Please clarify.
>
> 5.       In section 3.1 in the registration you give as reference for the
> audio and video SMPTE 314M (for backward compatibility). I assume you meant
> 306M
>
> 6.       In 3.1.2 in the audio registration you have audio as an optional
> parameter. I assume you do not need it. It is not appear in RFC3189
>
> 7.       In 3.1.2 in the encoding consideration you have DV video, you meant
> DV audio
>
> 8.       In 3.2.1 I suggest changing the 3rd paragraph to "Note that the
> examples in RFC3189 (older version of this document)  provides incorrect SDP
> "a=fmtp" attribute usage."
>
> 9.       In 3.2.1 when you explain the syntax of the audio parameter I
> suggest "a=fmtp:<payload type> encode=<DV-video encoding>; audio=<audio
> bundled>" since encode is a required parameter.
>
> 10.   In section 3.2.2 first paragraph the reference to offer answer is RFC
> 3264 and not SDP
>
> 11.   In 3.2.2 first bullet and in the section you use bi-directional, mono
> directional and multicast. The terms use in offer answer are sendrecv,
> sendonly and recvonly. By multicast I assume you mean declarative SDP since
> multicast can be used also in offer/answer mode. I suggest changing the
> first bullet to  " The "encode" parameter can be used for sendRecv, sendonly
> and recvonly streams.  each encode type MUST use a separate payload type
> number" because of the terminology and because each encoding parameter
> requires a separate payload type number so the receiver do not get one
> payload type number with multiple encodings but multiple payload type
> numbers from which is need to select.
>
> 12.   In section 3.2.2 the third bullet "The optional "audio" parameter is
> only used for the bundled stream.  On the offerer sets a audio bundled type
> on a=fmtp field,  then the answerer MUST select whether the DV stream should
> be  included audio data or not, and reply with selected value." . I am not
> sure what you meant here. Do you mean that if the offer include
> audio=bundled the answer can delete it. What will be the result, how will
> the audio be sent in this case. My thought is that if the answer do not want
> bundled audio he should reject the stream. The offer can send a separate
> offer with DV video without audio and a separate audio stream.
>
> 13.   When you have the audio unbundled. How do you associate between the
> audio and video in the offer for lip-synch. For example if there is more
> than one video or audio stream. I suggest you use grouping in the example
> look at RFC3388 using LS semantics
>
> 14.   In section 3.2.2 last bullet discuss multicast. If you meant
> declarative SDP (for example for streaming applications) this bullet is
> redundant and can be deleted
>
> 15.   In section 5  you discuss multiple frames in one packet. I think that
> this cannot happen for DV video.
>
> 16.   In the IANA consideration, this is not a new payload subtype name.
> this registration updates the DV registration from RFC 3189
>
> 17.   In section 8 on interoperability with older systems I think that it
> will be good to explain that an offer may include SMPTE306M encoding coming
> from a legacy system and that the receiver should support it. It also need
> to address the other case where the offer does not include SMPTE306M since
> it is using this draft and the answerer reject the offer. The offerer may
> try a new offer with SMPTE306M.
>
> Thanks
>
> Roni Even
>
> As individaul
>
>
>
>
>
>
>
>
>
>
>
> ________________________________
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>