[xiph-rtp] [vorbis-rtp] Updates

[Ralph Giles]

On Thu, Oct 20, 2005 at 12:54:39AM +0200, Luca Barbato wrote:

> >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.
> 
> dynamic numbers are dynamic. The fixed payload number will be decided on 
> a second time IIRC

If Mike is correct we should just say it must be dynamically assigned in 
a consistent manner.

> >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.
> 
> If they are sent in-band they will obey the same rules for the other 
> vorbis data, thus they could be fragmented (they will be for sure).

Yes, but I still don't see what this has to do with the advantage of
defining a special packed format to combine the info and setup headers.
Why shouldn't we just send those the same way with send data packets?
With perhaps the proviso that they shouldn't be packed together with
any data packets.

> It would allow mixing packets of different type (should be forbidden).
> I we could consider the issue but if it lasted for that many revision of 
> the rfc there could be a reason I don't figure now.

We'd decided to remove the packet-type field in the discussion after the 
January 31st draft. The headers can be distinguished from data packets 
and each other by examining the first byte of packet data.

I guess I can see having an explicit "packet type" in the payload header 
to help enforce the no-packing restriction, but not duplicating this 
information feels more "xiph-like" and treating the headers as part of
the vorbis packet-stream is definitely more "vorbis-like".

Anyone else have comments?

 -r