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

[Phil Kerr]

Hi Aaron,

On 20 Oct 2004, at 19:51, Aaron Colwell wrote:

> On Wed, Oct 20, 2004 at 08:30:03PM +0200, Tor-Einar Jarnbjo wrote:
>> Onsdag, 20 oktober 2004, skrev Aaron Colwell <acolwell at real.com>:
>>
>>> Why are chained streams not going to be supported? I looked at the 
>>> wiki
>>> pages and I don't agree with the arguments for dropping chaining
>> support.
>>
>> Well, one major obstacle is that common control protocols for RTP
>> sessions (RTSP and SDP) are not directly supporting all the chaining
>> mechanisms. E.g., you cannot simply change the sample rate or number
>> of channels within a session as these are specified in the session's
>> SDP descriptor.
>
> Why not just pick a master sample rate with sufficient resolution to
> acommodate all the chains. If you still want to maintain sample 
> accurate
> timestamps then you can put a field in the payload that contains the 
> part
> that got rounded off when converting to the master sample rate. This 
> allows
> the RTP timestamp sample rate to stay constant while the actual sample 
> rate
> of the stream contents can vary. This mechanism can also apply to 
> Theora
> streams where the frame rate changes.

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.

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

-P

> Aaron
>
>>
>> Tor
>>
>>
>>
>>
>