[AVT] Re: Status of draft-kerr-avt-vorbis-rtp-01

[Colin Perkins <[e-mail]>]

Hi Phil,

--> [e-mail] writes:
>I'm checking on the status of draft-kerr-avt-vorbis-rtp-01 and how things can be
>moved forward with it.  The update was submitted just before the cutoff for the
>last AVT meeting and there seems to have been no action on it since.

I took the liberty of cc'ing the AVT mailing list, to encourage feedback.

>There are a few small changes I may wish to make to the draft, which will be
>discussed at a Vorbis meeting tomorrow, but I wanted to check with you first on
>if the 01 draft is good enough to move forward.

I think it's in good shape, although I have a couple of issues:

 - Section 2.1 notes that the P, X and CC fields of the RTP header are set
   to 0. I'm not sure it's appropriate for a payload format to specify this: 
   I can imagine valid scenarios where each of these can be used with Vorbis.

 - The discussion in section 3 can make use of normative language to be
   clear on how frames are packetized. I suggest the following changes:

       Any Vorbis packet that is larger than 256 octets and less than the
       path-MTU should be placed in a RTP packet by itself.
                ^^^^^^ MUST

       Any Vorbis packet that is 256 bytes or less should be bundled in the
                                                   ^^^^^^ SHOULD
       RTP packet with as many Vorbis packets as will fit, up to a maximum
       of 32.

       If a Vorbis packet will not fit into the RTP packet, it must be 
                within the network MTU ^^^^^^^^^^^^^^^^^^^     ^^^^ SHOULD
       fragmented.  A fragmented packet has a zero in the last five bits 
       of the payload header.  Each fragment after the first will also set 
       the Continued (C) bit to one in the payload header.  The RTP packet 
       containing the last fragment of the Vorbis packet will have the 
       Marker (F) bit set to one.
       ^^^^^^ Final Fragment 
                  (to avoid confusion with the RTP Marker bit)

 - The IANA considerations section needs to be expanded. Section 4 of RFC
   3047 is a good example, to illustrate the format.

 - Regarding the configuration headers, is there a need to send updates
   during a session? If not, it might be appropriate to define some SDP
   parameters to convey the configuration data at session initiation time,
   rather than relying on RTCP. If RTCP is to be used, it's necessary to
   discuss reliability, and how a receiver reacts if the information is
   lost.

I also have a few editorial comments:

 - The interpretation of key words and reference to RFC 2119 should be
   moved into the Introduction rather than being in the Status of this
   Memo section.

 - I suggest moving the last three paragraphs of the Introduction into
   section 2.3, where the packing of the payload data is discussed. It
   may also be appropriate to include a slightly longer description of
   the Vorbis codec and when it might be useful in the Introduction.

 - In section 3.1, it might be useful to include the RTP packet header 
   details, to show how the RTP sequence number and timestamp are used
   (sequence number increases by one for each packet, timestamp stays 
   the same for each fragment).

 - Section 7 might reference the discussion of congestion control in 
   the RTP spec and/or profile

 - References should be split into Normative and Informative sections.


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