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

[Aaron Colwell]

On Thu, Oct 21, 2004 at 01:00:42AM +0100, Phil Kerr wrote:
> 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 :)

Don't forget that RTCP chat is bandwidth limited. By default it is only allowed
to consume 3.75% of the total session bandwidth and a minimal interpacket
interval of something like 2-5 seconds. I'm sure the codebooks will go over 
these constraints. You can use b=RR in the SDP to up the RTCP channel's share 
of the bandwidth, but you are still transmitting time critical stream info in 
a control channel. If you want to transmit the codebook inline, I'd suggest 
just interleaving it in the RTP channel because there are fewer constraints 
there. It also prevents the need to add non-standard RTCP packets which 
usually is an interop concern.

Packets from each group in chained file, should have a "group ID" in it. This
ID helps the client figure out that the group has changed. If the client 
doesn't have the codebooks for this group yet, then it can delay decoding until
it gets it. During normal streaming you would probably transmit the codebooks
inline. Since the http URL and MD5 info is periodically transmitted then the
client can go get the pieces it didn't get. You could also use RFC 3611 XR
RTCP packets to signal the loss and a server that supports these packets could
resend the lost packet. 

It's not clear to me how much loss to expect during normal streaming. Remember 
that these packet are likely going to be sparse and the probability of these 
ones being dropped often is unlikely. Yes they could be lost, but as long as 
we provide a recovery mechanism or 2 for recovering from that loss I think 
we'll be ok. I do think we need to do a lot of research in this area.

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

Agreed.

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

Agreed. I think for now HTTP will be the reliable recovery mechanism. Once
RTP retransmission drafts get finalized we could do the reliable transport over
RTP. There will be a adoption lag for that support which is why I'm pushing
HTTP for now. Everyone supports that right now.

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