Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Tim Panton <[e-mail]>]

On 12 Oct 2011, at 14:59, Timothy B. Terriberry wrote:

>> Lets assume we use a subset/variant of SDP as a codec capability
>> description 'language' - (i.e. we won't be using the parts that relate
>> to network properties).
> 
> I've seen this proposed a couple of times now, and I would like to point out that this is a terrible assumption. There are many things that one might want to control about a codec that will never show up in SDP, because they don't require explicit negotiation between sender and receiver (e.g., the sender gets to make a unilateral decision and the receiver simply deals with it... like, say, the amount of time a video encoder is willing to spend doing a motion search, etc.).
> 
> Limiting yourself to the parameters that do happen to show up in SDP is a pretty poor half-solution, if you really do think you need a low-level API of this kind, and may not have obvious extension points to get to a full solution.

Which leaves us with the choice of:
	a) having 2 different APIs - one for SDP params and one for everything else
	b) extending SDP to include things that will only be used locally 
	c) describing a mapping from SDP to javascript objects for a 'full' codec description object
	d) ?

Tim (P).