[xiph-rtp] header caching and chaining

[Aaron Colwell]

On Thu, Feb 10, 2005 at 03:58:08PM -0800, Ralph Giles wrote:
> On Thu, Feb 10, 2005 at 10:10:35AM -0800, Aaron Colwell wrote:
> 
> > ok. I sort of lost track of what has happened here. Could someone provide a
> > summary of the problem and solutions being proposed?
> 
> Oops. That's what I was trying to do when I started the thread.
> 
> > Here is what I've gotten from this discussion.
> > 
> > - There are concerns about collisions in the CRC
> 
> Yes. And we don't want to spend more per-packet bits on the ident.
> 
> > - The use of a unique ID is being proposed so that collisions are avoided,
> >   but this brings up a problem of mapping the unique ID to the codebooks and
> >   ident header.
> 
> It makes the mapping definition more pressing anyway.
> 
> > - There are some concerns that using a unique ID adversely effects the players
> >   ability to cache codebooks and avoid retrieval when it isn't necessary.
> 
> Yes.
> 
> > If so here is a possible solution.
> > 
> > - Generate a unique ID for each chain. This could simply be the chain index 
> >   (ie the Nth chain in the file will have a unique ID of N)
> > 
> > - The server publishes a base URL in the SDP that allows the client to retrieve
> >   hashes and URLs for the codebook and ident header associated with each 
> >   unique ID. The url for info associated with a particular unique ID is 
> >   constructed by appending the unique ID to the base URL.
> 
> How many bits are you proposing for this id?

I figure we could use the 32 bits that were proposed for the CRC field or 
maybe even 24 or 16 bits. This basically just limits how many chains with
different ident,codebook pairs you want to support in a single broadcast.

> 
> Using a regularized URL scheme also means clients can at least take 
> advantage of HTTP caching mechanisms. That might be simpler than 
> specifying some way to retrieve the hash separately.

I'm not sure I follow you here. The reason I am proposing the base URL scheme
is because you may not always know what the ident,codebooks pairs are at
SDP generation time. By using the base URL mechanism the client knows how to
take a new ID it gets and retrieve information about the codebooks involved.
Unless you want to send this mapping info periodically in the data stream I'm
not sure how else you can do this.

> 
> I'd really like to see what the SDP would actually look like for 
> this codebook transmission stuff. Can someone work up some examples? If 
> we can somehow include a larger hash for the chain idents in the 
> SDP, that would restore caching.

I'll take a stab at this.

Here is the case where all the chains are known at SDP generation time

v=0
o=- 1105605563 1105605563 IN IP4 207.188.30.165
s=<No title>
i=<No author> .2000
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=range:npt=0-202.297000
m=audio 0 RTP/AVP 101
b=AS:8
a=control:TrackID=0
a=rtpmap:101 VORBIS/44100/2
a=fmtp:101 chain-ids=0,1,2;
a=chain-info:0 ident=42; codebook=98
a=chain-info:1 ident=43; codebook=98
a=chain-info:2 ident=45; codebook=23
a=ident-info:42 url="http://foo.com/ident-441k"; hash=987234BC8D92DFE2987234BC8D92DFE2
a=ident-info:43 url="http://foo.com/ident-8k"; hash=2186461716517578792145688D92DFE2
a=ident-info:43 url="http://foo.com/ident-11k"; hash=218646687642f4AEFD2145688D92DFE2
a=codebook-info:98 url="http://foo.com/codebook-lowBW"; hash=309573098520975ABEFC34768D92DFE2
a=codebook-info:23 url="http://foo.com/codebook-speech"; hash=4567319735186778271C34768D92DFE2

If you allow the urls to be relative that you could also do this

v=0
o=- 1105605563 1105605563 IN IP4 207.188.30.165
s=<No title>
i=<No author> .2000
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=range:npt=0-202.297000
m=audio 0 RTP/AVP 101
b=AS:8
a=control:TrackID=0
a=rtpmap:101 VORBIS/44100/2
a=fmtp:101 chain-ids=0,1,2; baseURL="http://foo.com/ident-441k/"
a=chain-info:0 ident=42; codebook=98
a=chain-info:1 ident=43; codebook=98
a=chain-info:2 ident=45; codebook=23
a=ident-info:42 url="ident-441k"; hash=987234BC8D92DFE2987234BC8D92DFE2
a=ident-info:43 url="ident-8k"; hash=2186461716517578792145688D92DFE2
a=ident-info:43 url="ident-11k"; hash=218646687642f4AEFD2145688D92DFE2
a=codebook-info:98 url="codebook-lowBW"; hash=309573098520975ABEFC34768D92DFE2
a=codebook-info:23 url="codebook-speech"; hash=4567319735186778271C34768D92DFE2


If the chain ID set is not known at SDP generation time then you could have
an SDP that looks like this

v=0
o=- 1105605563 1105605563 IN IP4 207.188.30.165
s=<No title>
i=<No author> .2000
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=range:npt=0-202.297000
m=audio 0 RTP/AVP 101
b=AS:8
a=control:TrackID=0
a=rtpmap:101 VORBIS/44100/2
a=fmtp:101 chainIDBaseURL="http://foo.com/chainIDs/"

If the client got a packet with an ID of 63 then it would request
http://foo.com/chainIDs/63

This would contain a chunk of data that would look like

+--------------+
|   Ident MD5  |
+--------------+
| Codebook MD5 |
+--------------+
|   Ident URL  | <- Null terminated string
+--------------+
| Codebook URL | <- Null terminated string
+--------------+


The client can differentiate the 2 cases by what fields are present in the 
fmtp header.


Aaron

> 
>  -r
>