Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-05.txt

[Stephan Wenger <[e-mail]>]

Hi Colin, AVTers,

first I want to thank Colin and Philippe for their careful review of the 
I-D.  A new version of the draft is in its final stages of preparation and 
will be made available shortly.  This new draft reflects Philippe's comment 
(by restructuring section 8.4 and several other places in the draft to 
avoid too much redundancy) and most comments of Colin as well.

Let me come back to a few items of Colin's list of which we don't know what 
to do with:

>  - In Section 5.7.2, is it correct that the DOND field is unsigned?
I believe this is correct.  We can set the DONB (Decoding Order Number 
Base) to make it possible that only positive values are necessary, and this 
definition makes the wrap-around language easier.  Is there a need to spell 
this out explicitely?

>  - It may be appropriate to move Section 7 to be an appendix?
We think it may be better to leave this where it is, because this section 
explains concepts that are helpful to understand some of the following MIME 
parameter definitions.  Also, many older RTP payload specs have the 
packetization and de-packetization sections next to each other -- it seems 
natural to me.

>- In the encoding considerations for the MIME type, may wish to note that
>    file formats are defined elsewhere?
The problem here is that all file formats are still in their specification 
phase -- we can't reference them (yet).  And what good would a simple 
"elsewhere" do?

>  - Is there any need to discuss use with RTSP in Section 8.2.2 or 8.2.3?
I believe that in RTSP a simple, declarative process is used.  This sems to 
be well enough defined, and I'm not aware of any special considerations 
needed for RTSP.  Colin, did you have anything in particular in mind?

>  - The draft needs to discuss congestion control, either within Security
>    Considerations, or as a separate section.
I don't see any issues of congestion control beyond those of RFC3550, maybe 
with the exception of what is written in section 7.3 (it is possible to 
discard certain NALUs in translators, mixers, and receivers under certain 
conditions, and that could be used for congestion control in scenarios 
where mixers and translators are in use).  Hence we suggest to add a 
sentence in the security section that people need to observe RFC3550 
congestion control, and can possibly make the network's life easier by 
implementing 7.3.  Is there a need to say anything beyond that?

Thanks again for your helpful comments,
Stephan



At 05:11 PM 5/3/2004, Colin Perkins wrote:
>On Friday 30 April 2004 16:33, Magnus Westerlund wrote:
>...
> > If more people has comments they are appreciated if they can be sent no
> > later than monday. I will try to do a update in the beginning of the
> > next week, and submit that as soon as possible.
>
>I have a few comments:
>
>  - In Section 3, I agree with the likely initial applications of the
>    payload format. I would suggest adding text to note that the format
>    is not limited to these applications, however.
>
>  - The last paragraph of Section 5.1 mentions that the RTCP jitter
>    statistic is not trustworthy. It would be more accurate to say
>    that the RTCP jitter is not a trustworthy indication of network
>    performance.
>
>  - Table 1 should make explicit reference to NAL unit types 0, 30 and 31,
>    even if just to indicate that they are undefined.
>
>  - A number of places talk about "optional" MIME parameters, but would be
>    better using the RFC 2119 "OPTIONAL" language. For example:
>     - Section 5.4, last paragraph on page 14
>     - Section 5.5, second paragraph
>     - Section 6.1, second paragraph on page 28
>     - Section 6.2, first paragraph
>     - Section 6.3
>     - Section 6.4
>     - Section 7.2
>     - Section 8.2.1, 4th bullet point
>
>  - In Section 5.4 (last paragraph on page 14) it states that `"No" in the
>    "type 1-23" row indicates that an RTP payload cannot contain a single
>    NAL unit whose type is in the range of 1-23, inclusive'. Please clarify
>    what this refers to.
>
>  - Section 5.5, second paragraph, is unclear what is done if the MIME
>    parameter is not present.
>
>  - The last paragraph of Section 5.7 mentions that Section 5.7.1 and 5.7.2
>    define the three different types of aggregation unit. Should this be the
>    four different types?
>
>  - In Section 5.7.1, I would recommend moving the paragraph starting "The
>    DON field specifies the value of the DON for the first NAL unit in an
>    STAP-B...." to be immediately after Figure 5.
>
>  - In Section 5.7.1, could an example of an STAP-A packet be provided?
>
>  - In Section 5.7.2, is it correct that the DOND field is unsigned?
>
>  - In Section 5.7.2, you might consider splitting the long paragraph on
>    page 22, perhaps starting new paragraphs with "The structure of the
>    multi-time aggregation units..." and "The timestamp offset field MUST
>    be set..."
>
>    If this was done, I would also move the contents last paragraph on page
>    21 to the end of the first on page 22 (immediately after "...whereby n
>    can be 16 or 24").
>
>  - In Section 5.7.2, an example of an MTAP24 would be valuable
>
>  - In Section 5.8, the penultimate paragraph mentions that "A FU payload
>    MAY have any number of octets and MAY be empty". Can you clarify when
>    an FU payload may be empty, and why that is useful?
>
>  - Section 6.1, second bullet point on page 28, should be clear that NAL
>    units are duplicated in the application, not be generating duplicate
>    RTP packets. Similarly, the discussion of gateway devices later in the
>    Section should explain how the gateway aggregates/deaggregates NAL units
>    without breaking RTP when gatewaying between IP networks with different
>    MTU size (it will be an RTP translator, and will need to rewrite RTCP)
>
>  - It may be appropriate to move Section 7 to be an appendix?
>
>  - In Section 7.2, it's unclear where the 4th paragraph fits?
>
>  - In Section 8.1, please clarify how the "max-dpb" parameter relates to
>    the jitter buffer size, if at all? Similar for the deint-buf-req,
>    deint-buf-cap and int-buf-time parameters (this is mentioned at the
>    end of page 40, but this is not obviously related to the earlier
>    definitions).
>
>  - In Section 8.1, please clarify how the "max-br" parameter relates to
>    congestion control, if at all?
>
>  - In the encoding considerations for the MIME type, may wish to note that
>    file formats are defined elsewhere?
>
>  - Section 8.2.2, first bullet point on page 44, suggest clarifying that
>    "...the answerer must either maintain all configuration parameters or
>    remove the media format..." is a MUST?
>
>  - Section 8.2.2, second bullet point on page 44, similarly suggest that
>    "The offerer must assume that the answerer supports the same
>    configuration and basic capabilities that it is offering" should be a
>    MUST?
>
>  - Section 8.2.2, second bullet point on page 44: this is different from
>    normal offer/answer usage. Do you have buy-in from the SIP community?
>
>  - Is there any need to discuss use with RTSP in Section 8.2.2 or 8.2.3?
>
>  - The draft needs to discuss congestion control, either within Security
>    Considerations, or as a separate section.
>
>Finally, the document could do with careful proof-reading for spelling and
>grammar mistakes.
>
>Colin
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/avt


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