[xiph-rtp] Proposed RTP headers

[Phil Kerr]

Hi All,

Below are some proposals for the Vorbis RTP headers based on recent 
discussions.  The main change to the -03 I-D is a slight extension where 
the reserved, R, bitfield in the payload header has been changed to a 
type, T, bitfield to indicate what type of message it is.  If it's set 
to 0 then it indicated the packet is a Vorbis data packet and if it is 
set to 1 it is a Vorbis codebook message.
Hopefully your email client won't mangle the text layout below, if it 
does set the font to non-proportional.

Example Vorbis Headers.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          codebook id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|F|T| # pkts  |
   +-+-+-+-+-+-+-+-+


The above is a very small change to the spec and for normal Vorbis data 
packets there are no differences in operation.  For  codebook packets 
the format is:


Example Vorbis Codebook Packet.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Codebook ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|F|1| 0 pkts  | bsz 0 | bsz 1 |       Num Audio Channels      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vorbis Version                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Audio Sample Rate                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Bitrate Maximum                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Bitrate Nominal                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Bitrate Minimum                        |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                       Codebook checksum                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Codebook length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ..                          Codebook                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ..                          URI string                          |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


The example codebook above is essentially the RTCP message grafted onto 
a normal RTP packet.  As with Vorbis data packets fragmentation of the 
codebook packet is taken care of with the C and F bitfields, the T flag 
is set to 1 and the number of packets is set to 0.  The checksum field 
not only acts as a check for the integrity of the payload it's also the 
hash used for codebook identification and caching.  The checksum and 
length fields are for the  whole message and must be checked once the 
whole codebook has been received.  I've included the codebook URI field, 
as per the original, but I'm not 100% sure if it will be required.  It's 
nice in one sense as it allows for the client to be notified where a new 
set of codebooks can be fetched by HTTP if needed.  The timestamp field 
is no longer required as we have a hard association with each Vorbis 
data packet and the associated codebook with the CRC32 ID.

Nothing changes over the discussions we've had about sending codebook 
information via SDP, this proposal allows for in-line transmission as 
well which should satisfy chaining and unidirectional transmission systems.

An area we have not fully discussed yet is metadata, so what I'm 
proposing is to extend the T bitfield to two bits.  This does mean the 
number of Vorbis frames an RTP packet can hold would drop from 32 to 16 
but it allows for metadata and another message type to be sent.  The 
metadata packet format can be based on the existing Vorbis metadata 
structure or can borrow ideas from CMML.  

Thoughts/comments?

-P