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

[Lars Immisch <[e-mail]>]

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.

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