Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)

["Timothy B. Terriberry" <[e-mail]>]

> I haven't seen the definitions for signalling Opus in SDP, so don't know
> if such a capability is described there (which may or may not illustrate
> your point).

It's described in Section 7 of the current payload draft: 
https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/

There's no facility for forcing a "music" mode in the SDP because this 
can be done unilaterally by the encoder, as Opus currently requires 
decoder support for all modes to avoid negotiation failure. Also, as 
I've said before, this is about more than just the encoding format. It 
has (arguably more important) ramifications for the front-end filtering 
done on the input audio signal (i.e., whether or not you're sending 
input from a low-quality mic vs. the direct output of a synth or even 
pre-recorded/generated content).

What we proposed before was a simple means of passing in a "hints" 
object (whether a JS object of some undetermined form or a string or 
something else) which could be used to control optional parameters like 
these. That's sufficient for the "music mode" case, where support on the 
encoder side is optional and you don't really need to know if it 
succeeded (i.e., it's not something that will show up in the SDP, 
whether it's generated by the browser or by script). I don't think it's 
sufficient for Matthew.