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

[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

 

 

 

 

 

  _____