Subject: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio

From: Lars Immisch <[email-masked]>
Date: Tue, 12 Jun 2012 23:42:28 +0200

Hi,

I have integrated the Opus codec into a SIP UA (based on pjsip). The intended application is for a broadcast (podcast) studio: a guest calls into the studio, talks (and maybe even sings) with the host, and the conversation is broadcast.

For this application, the highest available quality is desirable. 

I have experimented with Opus in the appliation=audio setting and am pretty happy with it. But reading draft-spittka-payload-rtp-opus-00, I find no provision to encourage the other party to send an Opus stream encoded with the "audio" application setting.

I'd like to propose an additional "application" parameter that can take the value "audio", "lowdelay" (and maybe "voip"):

In my example, the studio would offer (or answer with):

  m=audio 54312 RTP/AVP 101
  a=rtpmap:101 opus/48000
  a=fmtp:101 application=audio

This would prompt the encoder on the other side to use the audio application mode of Opus.

I hope this makes sense. If it does, I'd be very pleased if it could be included in the next draft. 

- Lars Immisch

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 12 Jun 2012 18:03:54 -0400

Hi,

The idea here is that the sender should know better than the receiver
the optimal way to encode the audio. This is why there's no application=
parameter.

Cheers,

	Jean-Marc

On 12-06-12 05:42 PM, Lars Immisch wrote:
> Hi,
> 
> I have integrated the Opus codec into a SIP UA (based on pjsip). The
> intended application is for a broadcast (podcast) studio: a guest
> calls into the studio, talks (and maybe even sings) with the host,
> and the conversation is broadcast.
> 
> I have experimented with Opus in the appliation=audio setting and am
> pretty happy with it. But reading draft-spittka-payload-rtp-opus-00,
> I find no provision to encourage the other party to send an Opus
> stream encoded with the "audio" application setting.
> 
> I'd like to propose an additional "application" parameter that can
> take the value "audio", "lowdelay" (and maybe "voip"):
> 
> m=audio 54312 RTP/AVP 101 a=rtpmap:101 opus/48000 a=fmtp:101
> application=audio
> 
> - Lars Immisch _______________________________________________ codec
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/codec
> 
> 
>

---

From: Lars Immisch <[email-masked]>
Date: Wed, 13 Jun 2012 00:33:57 +0200

Hi,

> the optimal way to encode the audio. This is why there's no application=

I understand that reasoning. A hi-fi music on hold implementation would just use application=audio and send it unless the receiver asks for bandwidth restrictions.

But in our usecase (guest calls into broadcast studio), the receiver does know better. The recording will be broadcast and the receiver wants a way of saying: "Hey, send your best quality (because this will be broadcast)".

This addition would solve a real problem and create no interoperability concerns.

If you can think of other ways to solve this problem, I'd be pleased to hear them (I toyed with the idea of having an opus-audio codec, but dismissed it because application=audio seemed a better fit, in particular because the hypothetical opus-audio and the opus codec can interoperate).

- Lars Immisch

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 12 Jun 2012 20:38:09 -0400

On 06/12/2012 06:33 PM, Lars Immisch wrote:
> But in our usecase (guest calls into broadcast studio), the
> receiver does know better. The recording will be broadcast and the
> receiver wants a way of saying: "Hey, send your best quality
> (because this will be broadcast)".

Just saying "encode at high bit-rate" is enough to get the best
quality. Also, note that the "application" setting has nothing to do
with the Opus format. It's just an option in the current libopus API.
Other Opus implementation may not have that option at all, or may
expose the equivalent through a totally different API. This is why it
cannot be included in the SDP.

Cheers,

	Jean-Marc

---

From: Lars Immisch <[email-masked]>
Date: Thu, 14 Jun 2012 00:52:31 +0200

Hi,

> cannot be included in the SDP.

Well, the draft talks about "audio mode" and "voice mode" [1]. I should have suggested the parameter name "mode" and not "application" to stay within the draft's language.

But how can the receiver say: "encode at high bit-rate"? I don't see how that can be done.

a=fmtp: 101 maxaveragebitrate=128000 (or any x > 32000) is a bit weak, because that's always true per Table 1. 

What about maxaveragbitrate=unlimited?

And a bit of explanatory text like this (modified from Section 7.2.1):

   o  The parameter "maxaveragebitrate" is a unidirectional receive-only
      parameter. The value "unlimited" indicates that the local receiver 
      wishes to receive payload data that was encoded with the audio mode 
      of the codec. Other numerical values reflects limitations of the local 
      receiver and the sender of the other side MUST NOT send with an average 
      bit rate higher than "maxaveragebitrate" as it might overload the network
      and/or receiver.  The parameter "maxaveragebitrate" typically will
      not compromise interoperability; however, dependent on the set
      value of the parameter the performance of the application may
      suffer and should be set with care.

That would be good enough for the use case at hand, but it isn't easy on the reader of the draft. "mode=audio" seems clearer and needs less text. But I don't care how it is done as long as the receiver can indicate to the sender that it wants the highest quality that the sender can produce.

- - Lars

[1] There is a typo in the draft: the section title in 3.1.1 should probably be "Voice mode"

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 14 Jun 2012 11:07:25 -0400

On 06/13/2012 06:52 PM, Lars Immisch wrote:
> Well, the draft talks about "audio mode" and "voice mode" [1]. I 
> should have suggested the parameter name "mode" and not
> "application" to stay within the draft's language.

Actually, the audio mode/voice mode will go away in the next revision
- -- it's just not needed considering that the sender knows better.

> see how that can be done.

You can do that with the b=AS: parameter

> a=fmtp: 101 maxaveragebitrate=128000 (or any x > 32000) is a bit 
> weak, because that's always true per Table 1.

First, table is just a rule of thumb for the recommended bandwidth
bandwidth in each more. It's not about defining maxaveragebitrate.
Also, we've realised that maxaveragebitrate needs to be a hard cap and
that it's not a good idea to use it for controlling the rate.

> What about maxaveragbitrate=unlimited?

Indeed, we'll make maxaveragbitrate *default* to unlimited in the next
draft. Controlling the bitrate should be done with the b= attribute.

	Jean-Marc

---

From: Lars Immisch <[email-masked]>
Date: Thu, 14 Jun 2012 23:58:48 +0200

> You can do that with the b=AS: parameter

Ah, ok. RFC 3556

> draft. Controlling the bitrate should be done with the b= attribute.

That sounds like it would address my concerns.

Thank you,

- - Lars Immisch