[xiph-rtp] [vorbis-rtp] Updates

[Ralph Giles]

On Wed, Oct 19, 2005 at 01:14:54PM +0200, Luca Barbato wrote:

> rfc: I recently removed the caching paragraph since doesn't apply 
> anymore. I'd like to have you have a review, tell me if that would work 
> for your purposes and notify me about any errors. I'd like to have this 
> draft committed to the rfc editor soon (say tomorrow or the day after).

Here's my review. I also checked in some minor wording changes. I think
we can still make a lot of the text more clear, but let's get the 
details worked out first. :)

The spec doesn't give a payload type. Do we assign that, or do we need 
the WG to do that? I note we've been using 96 in the reference 
implementations and 98 in the SDP examples.

In section 2.3, I'm confused by the paragraph on payload packing 
referencing RFC 3551. Is this a reference to bit/byte order? When
I first read it I thought it meant the ordering of vorbis packets
within a packed RTP packet. If it's that it has to be a MUST, since
there's no way to reorder the vorbis packets for correct decode.

We should also clarify that the vorbis packet should be zero-padded
out to the end of the last octet, and so the length field for the next
vorbis packet in a packed RTP payload will start on an octet boundary.
The vorbis spec implies this, but it's good to clarify the rules here.

Also in section 2.3, a reference is made to an ITU spec for channel
mapping. Maybe we should give some examples since that spec isn't
freely available? (and so we can make sure it matches the vorbis
mapping!) Is there a way to distinguish dolby-style 5.1 from other
six channel mappings?

Section 3: I can see the value of defining the packed header formats
here so we can refer to them from the descriptions of separate 
out-of-band retrieval methods, but I still don't see any particular
advantage to packing them into a fragmented series of RTP packets.
Using the same mapping we do for data packets, just like in Ogg,
seems simpler to me and would let us eliminate the payload type
field.

We should also explicitly say somewhere that the ident field in the 
payload header maps a given data packet to a given decoder 
configuration, and that for out-of-band retrieval methods, that
mapping is outside the scope of the current document.

I also think we should mention some of the examples of oob methods we've 
come up with in this document, e.g. URI in the SDP or equivalent 
pointing to an HTTP or RTSP url for unicast use, another SDP for a 
separate multicast channel containing just the headers for a multicast
session, or even a private fixed mapping for broadcast applications. 
Also, a hash could be included to allow caching. This helps illustrate 
what we're thinking even if we don't give any details.

In section 4: please remove "This packet SHOULD NOT be sent". We have 
people on both sides of that idea; being neutral seems the best course.

In section 5.2: we should probably ammend that to say that the client 
MUST discard any remaining fragments in a vorbis packet after one 
fragment is lost. Vorbis is designed to cope with packet truncation,
just not with complete packet loss. There will be still be signal loss
of course, but it's better than dropping the packet entirely.

I also think we should tone down the RTCP feedback references in this 
section. This is already covered by other RFCs. How about changing the 
last sentence to a SHOULD, or dropping it altogether.

In section 6.1, but MIME subtype is still listed as "VORBIS" instead of 
"vorbis".

So far, so good,
 -r