[xiph-rtp] Lots of proposals

[David Barrett]

Aaron Colwell wrote:
> 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.

Agreed.


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

I agree, though I'd suggest implementors only SHOULD support the RTCP 
feedback method (and not MUST, in order to allow for unidirectional 
broadcasts).


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

Agreed.


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

This sounds great!


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

Agreed, on one condition: that decoders be hardened against the 
possibility of the encoder and decoder using mismatching codebooks that 
happen to have the same MD5 hash.  Given how astronomically slight this 
chance is I don't think it's necessary to really correct the situation 
-- I think garbled output is fine, so long as it doesn't crash.

-david