[xiph-rtp] vorbis-rtp update

[David Barrett]

Thanks Luca, here are my comments:

Section 4
>    The delivery vectors in use are specified by an SDP attribute to
>    indicate the method and URI where the configuration and codebook data
>    can be obtained if applies.  Different delivery methods COULD be
>    advertized for the same session.  The in-band codebook delivery
>    SHOULD be considered as baseline, off-band delivery methods that
>    don't use RTP will not be described in this document. {FIXME add
>    reference to documents where it is described?  Remove the last
>    sentence?}

In this draft it sounds like you're saying that inline codebook delivery 
is not only the baseline, but the one and only method discussed in the 
document (though there are hooks for others, including HTTP and reliable 
inline with ACKs, to be documented elsewhere).  Personally I agree with 
this approach, but I thought the general consensus was that both 
unreliable inline *and* HTTP would be documented here, and that in fact 
*HTTP* was the baseline (ie, "implementations SHOULD use HTTP if possible").

But again, from my perspective, I like and agree with the approach 
you've taken.

Incidentally, I'd suggest avoiding the term "baseline" as I don't know 
if that has a universally precise meaning.  Rather, I'd recommend 
sticking with SHOULD, CAN, MUST, etc.


>    {FIXME keep the codebook ident field or use a shorter
>    tag field?}

I'm not passionate either way (rather, I see advantages to both ways), 
but I guess I'd vote keeping the "codebook ident" field.

However, I'd recommend adding a blurb somewhere to the effect of 
"implementations SHOULD handle gracefully (but MUST endure without 
critical failure) the the unlikely event of a CRC32 collision where two 
different codebooks have the same Codebook Ident."


> 4.1.  Initial SDP Header Setup
> 
>    The initial configuration MUST be reported in the configuration
>    parameter.  All the configuration headers known in advance SHOULD be
>    reported in the same way. {FIXME better wording, if the tag id will
>    be used instead of the Codebook hash here should go the mappings in
>    the for of list order -> tag id number.  Define the metadata/
>    configuration data in a non ambiguous way.  Define the format used.}

What precisely is "the initial configuration"?  I'd suggest we define 
these terms more explicitly.  For the meantime, I'm assuming this:

- "The Setup" the payload of the setup packet
- "The Codebook" the payload of the codebook packet
- "The Metadata" the payload of the metadata packet
- "The Configuration" a triplet of (setup, codebook)

So here, when you say the initial configuration "must be reported in the 
configuration parameter", what precisely do you mean?  Specifically:

By "initial" do you mean "the configuration of the first audio packet"?

By "configuration" do you mean "setup" or "setup+metadata"?

And furthermore, why make this a MUST requirement, or indeed a 
requirement at all?  Basically, I don't get the intent of this section. 
  Granted, I see that *something* must be defined in SDP in order for 
clients and servers to negotiate capabilties.  But given that everything 
can be changed on the fly, the SDP is only advisory -- the server is not 
bound to be limited by what was defined in the SDP.  (It obviously 
SHOULD stick within the client has agreed to accept, but it needn't.)


> 4.2.  In-band Header Transmission
> 
>    The three header data blocks are sent in-band with the packet type
>    bits set to match the payload type.  Metadata packets SHOULD be empty
>    and metadata information SHOULD be delivered using SDP.  Clients MUST
>    be capable of dealing with periodic re-transmission of the
>    configuration headers.
> 
>     ...
> 4.2.3.  Metadata Header
> 
>    {FIXME:I'd make it completely optional} With the payload type flag
>    set to 3, this indicates that the packet contain the comment
>    metadata, such as artist name, track title and so on.  These metadata
>    messages SHOULD be delivered using SDP and are not intended to be
>    fully descriptive but to offer basic track/song information.  The
>    message MUST be sent at the start of the stream, together with the
>    setup and codebook headers, the Metadata packet SHOULD be empty.
>    During a session the metadata associated with the stream may change
>    from that specified at the start, e.g. a live concert broadcast
>    changing acts/scenes, so clients MUST have the ability to receive
>    Metadata header blocks.  Details on the format of the comments can be
>    found in the Vorbis documentation [13].

The treatment and use of emtpy metadata packets is confusing to me.  I 
believe a more intuitive and semantically-correct approach is to make 
metadata headers optional, and say:

- Servers SHOULD define metadata in the SDP
- Servers SHOULD NOT send metadata packets if metadata has not changed
- Servers CAN send an empty metadata packet to clear the metadata

Thus when setting up a connection, you'd typically define the metadata 
in the SDP, and then NOT send it again inline because it hasn't changed 
from its last definition (in the SDP).


> 4.2.2.1.  Codebook CRC32 Generation

I just realized I've been totally mistaken about the meaning of the 
'Codebook Ident' -- I've been thinking it refers to the combination of 
(setup+codebook), but in fact it refers *exclusively* to a single 
codebook.  Hm...


> 4.2.1.  Setup Header

Given my above confusion about 'Codebook Ident', can you clarify for me 
the relationship between codebooks and setups?  It seems that the setup 
can and should be specified in the SDP, and the setup can change with 
inline transmission.  However, can I re-use the same codebook with 
multiple setups?  In practice does anyone do this?  If not, I'd advise 
we change 'Codebook Ident' to 'Configuration Ident', and then define a 
'Configuration' as "A setup and its matching codebook".  And given this 
definition, a 'Configuration Ident' would need its CRC32 calculated with 
the union of both configuration and setup payloads.

Basically, I'm confused about the relationship setups, codebooks, 
Codebook Idents, and configurations.  Can you straighten me out here?



Thanks Luca for your great work!

-david