RTP Payload Format for Vorbis Encoded Audio
draft-ietf-avt-rtp-vorbis-09

Received changes through RFC Editor sync (changed abstract to 'This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.

Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]')

[Ballot comment]
The -08 version addresses my discuss issues.

The new text states "The parameter MAY be included multiple time,
followed by the configuration or configuration-uri parameter
associated."

I believe that should be "times" instead of "time".  It is also very
unusual for the same MIME parameter attribute name to appear multiple
times.  However, I could find nothing in the MIME specification that
forbids doing so.  But be aware this could be a source of
interoperability problems (if an implementation ignores all but the
first attribute with a given name, for example).

A discussion of the security impact of the compression
algorithm as recommended by by RFC 4288 section 4.6 would improve
the document.

[Ballot discuss]
As the media type includes a parameter with a URI, it inherits the
security considerations of STD #66.  The document needs to state that.

One of the parameters uses base64 and thus the media type inherits
the security considerations of base64.  The document needs to state that.

The security considerations do not state whether or not the media
types contain active content.  BCP 13 requires such a statement.

The security considerations do not state whether the compression
mechanism can result in uncontrolled expansion on the recipient end
and what mechanisms are necessary to mitigate such problems.  BCP 13
recommends such a statement.

I don't understand what "MAY be included multiple times" means in this
context:
      delivery-method:  indicates the delivery methods in use, the
        possible values are: inline, in_band, out_band, MAY be included
        multiple times
Is this parameter value a comma-separated list?  Or are you saying the
parameter can appear multiple times?  Are different values allowed?

[Ballot comment]
The security considerations section is reasonable for a codec specification, but
could be enhanced by providing examples of secure protocols that fetch the
configuration payloads.  Otherwise, readers are guessing what the author had
in mind.

[Ballot discuss]
As the media type includes a parameter with a URI, it inherits the
security considerations of STD #66.  The document needs to state that.

One of the parameters uses base64 and thus the media type inherits
the security considerations of base64.  The document needs to state that.

The security considerations do not state whether or not the media
types contain active content.  BCP 13 requires such a statement.

The security considerations do not state whether the compression
mechanism can result in uncontrolled expansion on the recipient end
and what mechanisms are necessary to mitigate such problems.  BCP 13
recommends such a statement.

I don't understand what "MAY be included multiple times" means in this
context:
      delivery-method:  indicates the delivery methods in use, the
        possible values are: inline, in_band, out_band, MAY be included
        multiple times
Is this parameter value a comma-separated list?  Or are you saying the
parameter can appear multiple times?  Are different values allowed?

The IETF should own the media type registration (so it can continue to
be updated without an exception process when the AVT WG is
disbanded).

[Ballot comment]
References [10] and [12] are just pointers to the xiph.org Web site, and leave to the reader the challenge of searching for the respective documents. I suggest that the authors do this job instead and provide the exact reference - for example the Vorbis I specification is available at http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html.

[Ballot discuss]
The wording of what exactly to do in the packet loss section isn't worded quite right. In particular, all the specifics of decoding, dropping, etc need a double check. Also, loss of config data (sec 3.3)  has underspecification of what do in this scenario. "Halting of stream decoding" may be not clear enough to an implementor vs specifying the dropping of packets, sending event notification, reset connections, etc.

[Ballot discuss]
section 3 and 4: Lacks rule for how to assign RTP timestamp values to comment or configuration packet payloads. Unless there is clear rules for how to assign these timestamp there is a risk that they will be all over the place. This can affect both jitterbuffer handling and RTCP jitter measure function.

I would suggest that one uses a RTP timestamp value that reflects the transmission time for the particular packet.

Section 5. Fragmentation mechanism is missing explicit requirement to send all fragments consecutive without any other payloads being sent between the first and the last fragment. This is not strictly needed, however, any loss between the first and the last fragment will result in the loss of the whole data sequence.

Section 5. Fragmentation timestamp rule should note that this rule will affect RTCP jitter measurements.

Section 6.1:
"  The following IANA considerations MUST only be applied to the packed
  headers."

I think this text should be more explicit that the below media type registration applies binary objects following the format defined in section 3.2. Because that is quite loosely specified through the "packed header" reference.

8.  Congestion Control

  Vorbis clients SHOULD send regular receiver reports detailing
  congestion.  A mechanism for dynamically downgrading the stream,
  known as bitrate peeling, will allow for a graceful backing off of
  the stream bitrate.  This feature is not available at present so an
  alternative would be to redirect the client to a lower bitrate stream
  if one is available.

I think this should start with the statement that RTP receivers SHALL follow the rules existing in RTP and the applicable profile. Also the first sentence should probably be removed, because "Vorbis client" lacks definition and can't really be acted on. I think it is saftest to not mandate anything specific for Vorbis when it comes to how feedback is done.

I am also worried about the bitrate peeling bit. Is this a sender side only technique that is totally transparent for the receivers? Thus actually be deployed on senders without touching the receivers? If that is true then, I think one can be a bit more explicit about this. If not, how is it intended for a sender to know that it works?

Then I would also like to expand on how a sender can redirect to a lower bit-rate version? Isn't it actually simpler than that, as the sender can simply switch to a lower bit-rate version if needed. Which may require a new configuration however? I think some expanding on how this is done is needed.

* Issue with rate and channels parameter

It clearly is intended (which example in section 9 shows) to switch between different configurations. I lack some text that explains how to deal with content that has different sample rate, i.e. RTP rate, and different number of audio channels are going to be handled. From my perspective this would require switching between different RTP payload types. This is not without issues and should because of this be expanded.

[Ballot comment]
There seem to be some inconsistencies what the Vorbis data units are called. In Section 1, the data is called "Vorbis Packets" and in section 2 they are called Vorbis payload (data). The data varies depending on context. In the end of section 2.2 both payload and packet are used to refer to vorbis data. This alternation between packets and payloads continue in the following sections. Please address for clarity.

Section 2.2 also contains the usage of "RTP packet" or "packet" where in both cases "RTP Payload" would be more correct and clear.

[Ballot comment]
Section 12.1., paragraph 10:
>    [10]  "Ogg Vorbis I specification:  Codec setup and packet decode.
>          Available from the Xiph website, http://www.xiph.org".

DOWNREF? Not sure if Xiph qualifies as an SDO.

[Ballot comment]
Section 12.1., paragraph 10:
>    [10]  "Ogg Vorbis I specification:  Codec setup and packet decode.
>          Available from the Xiph website, http://www.xiph.org".

  DISCUSS: DOWNREF? Not sure if Xiph qualifies as an SDO.

IANA Last Call comments:

IESG NOTE: Expert Review Required.

Upon approval of this document, the IANA will make the following
assignments in the "Audio Media Types" registry located at
http://www.iana.org/assignments/media-types/audio/

audio
vorbis [RFC-avt-rtp-vorbis-07]
vorbis-config [RFC-avt-rtp-vorbis-07]

We understand the above to be the only IANA Action for this
document.

When the configuration is done in-band, how big are the typical configuration packets?I understand there is at some level no limit to this and that combined with the fact that loss of any fragment causes loss of the whole thing is very concerning.  I think more advice about the retransmission strategy for these is needed to build systems that will work.

The semantics around the configuration the configuration URI need work. Particularly what a sender needs to be able to assume that a receiver has implement.

---------------------

having base64string in the example SDP is very confusing. Please make the example a valid example.

This needs to address how it would be used in an offer answer type SDP model.

Need to specify what protocols the receiver needs to implementer for the configuration-uri

Is their a way to migrate from sha1 to a different hash

What does it mean to receive multiple delivery-method values - I read section 7.1.1 but I am still vague on this particularly when reading 7.2

Is there a secure way to retrieve configuration data.

Which base64 mapping alphabet is used

Are bzip2 and gzip mandatory to implement?

Need normative references to all the stuff the things that are implementer would need to implement this.

Are there any characters in the configuration-uri that need to be escaped?

There seem to be problem in !sha1hash to the end of an arbitrary URI.

Section 3 says that [13] requires a comment header before data can be interpreted but it is unclear to me how a client joining an existing stream reliably gets this.

I think this document needs to describe the out of band configuration deliver or provide a normative reference to a document that does. WIthout this, the stuff here does not seem implementable.

The document does not seem to give any advice on how and when and what to retransmit.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Colin Perkins. He believes this version is
ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had adequate review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this
document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director.
(It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the
document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document satisfies all ID nits. A media type review was conducted.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents
that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative
references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References have been split. There are no normative references to
internet drafts, and no normative down-references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and is consistent with the
rest of the draft. Registrations are in the appropriate registry.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

n/a

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document describes an RTP payload format for transporting
Vorbis
encoded audio. It details the RTP encapsulation mechanism for raw
Vorbis data and details the delivery mechanisms for the decoder
probability model, referred to as a codebook and other setup
information.

Also included within this memo are media type registrations, and the
details necessary for the use of Vorbis with the Session Description
Protocol (SDP).


Working Group Summary
Was there anything in WG process that is worth noting?
For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

The RTP payload format for Vorbis has been under discussion since the
50th IETF meeting and has changed author several times (which has
delayed its progress). The main technical issue has been transport of
configuration headers: Vorbis doesn't use statically configured code
books, and must receive a configuration header containing appropriate
code books for a stream before it can begin decoding. This is
problematic for RTP sessions using unreliable transports with limited
packet size, and required definition of both in-band and out-of-band
access methods for configuration headers, to ensure the configured
data can be retrieved.

Document Quality
Are there existing implementations of the protocol?
Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive
issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media
Type
review, on what date was the request posted?

I understand that there are a number of implementations.

The media type review request was posted 11 June 2007. During the
media type review, Bjoern Hoehrmann and Chris Lilley expressed
concern that this draft registers the audio/vorbis media type for use
only with RTP. We believe this concern is misplaced, since Vorbis
data must be framed (the application/ogg container provides the
framing for non-RTP use) and the registration of an RTP-only media
type is consistent with current practice, as documented in RFC 4855.

Personnel
Who is the Document Shepherd for this document? Who is
the
Responsible Area Director?

Colin Perkins is the document shepherd. Cullen Jennings is a
responsible area director.