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

[Matthew Kaufman <[e-mail]>]

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.

For example: forcing the Opus codec to "music" mode no matter what the 
input.

Matthew Kaufman