[xiph-rtp] Lots of proposals

[Aaron Colwell]

It looks like you beat me to suggesting that a summary for each proposal be
written. The "Chaining" thread seemed to be getting out of control.

Here is my position.

1. I think inline codebook transmission should be part of the base spec. I
   don't think a inline codebook delivery strategy should be discussed in
   detail. It should just be noted that loss can occur and periodic
   transmission or selective retransmissions are ways to handle loss.

2. I wouldn't mind if inline transmission with some sort of RTCP feedback
   was also included in the base spec. I have some ideas on this topic that
   I'd be willing to discuss on a seperate thread. After much thought I
   prefer this solution now over the HTTP mechanism. 

   David, I'd be interested in your current solution. I think that would be
   a good starting point for developing a standard for this codebook delivery
   standard. Ideally I'd like to turn it into something more generic that
   allows reliablility of some packets in an RTP session.

3. I think the HTTP codebook delivery scheme should be a seperate draft and
   not part of the base spec. I have yet to see an RTP payload format that
   requires another protocol like HTTP to allow it to function. I think it may
   be a useful thing to specify, but I don't think it belongs in the base spec.

4. I think that we should create an SDP header that allows the available
   codebook delivery mechanisms to be advertised. We would also need a way to
   notify the server of what mechanism the client intends to use. 

   For RTSP at least, I belive that 3GPP's alt-group specifications provide the
   necessary SDP magic to allow for this. Basically the idea is that each
   delivery mechanism is associated with an alt-group. Since each alt-group
   has a different a=control: line the server will be able to determine which
   delivery mechanism the client wants by the URLs used in the SETUP requests.

   I'm not as familiar with SIP, but I believe that there is a similar way to
   pick a specific delivery profile in the offer/answer handshake.

   Here is an initial proposal.

   - For the case where the codebook delivery is completely handled by out of
     band means. This might be selected if the client alreays has the
     codebooks used in the stream.

     a=codebook-delivery:out-of-band

   - For a possible multicast case. This just indicates that the codebooks will
     will be delivered inline on a periodic basis.

     a=codebook-delivery:inline-periodic

   - For the case where you want to do selective retransmission.

     a=codebook-delivery:inline-selective-ack

   - For the case where you want to use the HTTP codebook retrieval mechanism.
     One could argue that you could just use the out-of-band case for this, but
     I feel that this helps the client to know what other headers it should
     look for when determining where to get the codebooks from.

     a=codebook-delivery:http

5. Codebook MDS5 hashes and the ident header should be in the fmtp field no
   matter what the codebook delivery mechanism is.


Aaron