[xiph-rtp] Lots of proposals
dbarrett at quinthar.com
Fri Sep 2 16:35:16 PDT 2005
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.
> 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
> 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.
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.
More information about the xiph-rtp