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

[[e-mail]]

Hi Colin,

Many thanks for the feedback.  I'll update the draft with your change
suggestions together with any further comments that come in.

Cheers

Phil

Quoting 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
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt