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

[Harald Alvestrand <[e-mail]>]

On 09/16/2011 11:12 PM, Matthew Kaufman wrote:
> On 9/15/11 3:09 PM, Harald Alvestrand wrote:
>> The disadvantage of parsing to another structure (I am fond of JSON 
>> myself) is that one has to maintain a data definition for the format 
>> being parsed to, a defined transform between that and the "canonical 
>> SDP structure" has to be implemented in user space when one does SDP 
>> interoperability, both of those have to be updated for every SDP 
>> extension that someone defines somewhere, and one is still not free 
>> to define extensions on the non-SDP side if one still requires the 
>> ability to map them into SDP.
>>
>> If one uses the "native" SDP format, which is the format in which 
>> every extension to the format gets documented, the browsers are the 
>> ones who *have* to parse it (although others are likely to).
>
> Of course what you're also saying here is that it takes a trip to the 
> IETF to make every extension. So if the *only* Javascript API for 
> controlling the codec (or getting its capabilities by triggering an 
> offer) is a pile of SDP in string form, then nothing that hasn't been 
> standardized can be described.
1) No reason that this should be the only interface. I've just argued 
that I think this interface needs to be supported
2) SDP has a relatively clean "ignore what you don't understand" 
extension model. It's not my impression that people who want to deploy 
stuff wait until the standards are done.
>
> For example: forcing the Opus codec to "music" mode no matter what the 
> input.
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).
>
> Matthew Kaufman
>
>