[xiph-rtp] Re: [Speex-dev] new RTP development list

[Phil Kerr]

On 20 Oct 2004, at 22:22, Aaron Colwell wrote:
>>
>> This solves one of the problems for chaining, but there is still the
>> reliable delivery of the codebook if they have changed from the
>> previous chained file.
>
> I propose that an inline packet be periodically sent that contains an
> HTTP URL to the codebook and an MD5 hash of the codebook. This amount 
> of
> data is small so periodic transmission increases handles the 
> possibility of
> loss and the data is small and sparse so it shouldn't have a large 
> bitrate.
>

The stream overhead for this (about 120 bytes per packet including 
headers) is really nothing when you consider the overall stream bitrate 
(for Speex this would be a problem)  But as you mention in a previous 
email about temporally linking together metadata and the main 
bitstream, this approach breaks the association.

With using RTCP for transport at least codebook delivery is using the 
same protocol and, might, be routed the same.   If we rely on 
time-critical components being transported over HTTP then any QoS 
settings on a router could mess-up this delivery, and if a stream 
switch happens with the wrong codebook in place the results could be 
nasty :)

I think in order for chaining to work we need to:

a.) Deliver the codebooks via RTP so they are temporally linked to the 
main bitstream.

b.) Use a reliable mechanism for delivery and/or have a mechanism to 
check and re-acquire if a received codebook is corrupted.

>>
>>>
>>>>
>>>> A simple workaround would be to use RTSP for the same functionality
>>>> as chaining is used now. If I'm not completely wrong, it would be
>>>> a straight forward task for an RTP server to inform the client using
>>>> RTSP that the session is about to end and recommend the client to
>>>> switch over to another specified session, which is then setup using
>>>> completely different parameters if necessary.
>>>
>>> I think creating this sort of binding between RTSP and RTP is a large
>>> burden
>>> and defeats the purpose of having the 2 protocols decoupled to begin
>>> with.
>>> With the solution proposed above, you wouldn't need this anyways.
>>>
>>
>> To an extent I agree with Aaron, a hybrid approach between RTP and 
>> RTSP
>> may be less than optimal, but what Tor has suggested does solve the
>> codebook problem as the switched stream should be able to refresh its
>> settings from SDP.
>>
>
> I think the solution I mentioned above solves the problems without the 
> need
> for an SDP update.
>
>>  I think it would be best if we could keep the chaining option, but if
>> supporting this overtly complicates things then perhaps we need to 
>> make
>> a pragmatic decision to not support this feature.  We should try and
>> come up with a workable solution, so at least we can say we've tried 
>> to
>> keep it.
>
> The main reason I want to keep chaining is because I'd like to be able 
> to
> stream any file over RTP that HTTP currently can.

Agreed.  Lets see if we can work out a solution for this, but accept 
that if we can't work one out we may have to, reluctantly, drop this 
feature.

-P

>
> Aaron
>
>>
>> -P
>>
>>> Aaron
>>>
>>>>
>>>> Tor
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>