Subject: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 07 Apr 2015 11:01:05 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-payload-rtp-opus-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Very clear document; well written.

The Abstract and Introduction both understate what this document is.  It
doesn't just define the payload format and registrations, but also
provides what I would consider an Applicability Statement in Section 3:
normative, Standards Track advice about how to use the Opus codec,
complete with MUST and SHOULD and SHOULD NOT.  That's fine, but both the
Abstract and Introduction should say that.

-- Section 4.1 --

   Opus supports 5 different audio bandwidths, which can be adjusted
   during a call.

Wouldn't "during a stream", or "during active streaming", or perhaps
"during an RTP session", or some such be better than referring to "a
call"?

-- Section 5 --

   It is RECOMMENDED that senders of Opus encoded data apply congestion
   control.

Does this SHOULD come with any reference to how to do congestion control?
 The previous paragraph has some vague statements about doing congestion
control, but is there anything more concrete that I could refer to if I
were implementing this?

-- Section 6.1 --
I see that the document shepherd asked for a media-types review in
December, and that there were no comments.  Thanks for making sure that
got done, Ali.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 08 Apr 2015 16:13:15 -0400

Hi,

Thanks for the review. See my comments below.

> Abstract and Introduction should say that.

Would adding a sentence along the lines of: "This document also provides
an applicability statement for the use of Opus over RTP" to both the
abstract and introduction be sufficient to address the issue?

> "during an RTP session", or some such be better than referring to "a

I totally agree. I would just go with "during a stream".

> control, but is there anything more concrete that I could refer to if I

There is no recommended way to do congestion control here and it would
be beyond the scope of this draft. I guess it is something that needs to
be done for any kind of streaming. The main reason it's more relevant to
mention it for Opus than for some other VoIP codecs (e.g. G.711, G.729)
is that Opus supports a large range of bit-rates which means that it's
actually possible to adjust the bandwidth.

Cheers,

	Jean-Marc

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Apr 2015 16:45:14 -0400

> abstract and introduction be sufficient to address the issue?

Completely; thanks.

> actually possible to adjust the bandwidth.

Hm.
The problem I have is that if I'm new to all this -- say, I have a
startup company that's implementing streaming with Opus -- and I see
that, I'm going to need to know what to do or where to go to find out.
Can you think of a sentence or two to add that will help me, even if
it's just to let me know that there's nothing written about it yet?

Barry

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 08 Apr 2015 16:55:47 -0400

> it's just to let me know that there's nothing written about it yet?

I would be tempted to simply reword the abstract from
http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01

"Since UDP does not provide congestion control, applications that use
RTP over UDP have to implement their own congestion control above the
UDP layer. [draft-ietf-rmcat-app-interaction-01] describes the
interactions and conceptual interfaces necessary between the application
components that relate to congestion control, including the RTP layer,
the higher-level media codec control layer, and the lower-level
transport interface, as well as components dedicated to congestion
control functions."

Would that do?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Apr 2015 17:34:22 -0400

> transport interface, as well as components dedicated to congestion

That'd give me a place to look for more information; I think that
would help, yes.  And I think it's fine for the rmcat document to be
an informative reference.

Barry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Apr 2015 07:40:59 -0500

On one minor point ...

> an informative reference.

As best I can tell, RMCAT is doing some fairly heavy lifting on
app-interaction (as in, splitting into two documents, one targeting
application developers and the other targeting codec developers).

I know we can cite work in progress as informative, but this work is still
pretty active (the two drafts would be individual drafts, and I don't
believe either exists at this moment in time - the working group decided to
do this in Dallas, so that's not surprising).

Is that going to be OK?

Thanks,

Spencer

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Apr 2015 10:22:19 -0400

> do this in Dallas, so that's not surprising).

I'd be happy even with something that referred to "work being done in
the rmcat working group".  The point is just not to leave the reader
wondering.

b