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

[Randell Jesup <[e-mail]>]

[not responding to the other items mentioned in this post; perhaps later]

On 10/12/2011 12:49 PM, Roman Shpount wrote:
> This being said, I would also argue that we need to have an API that can
> be used with new codecs implemented by the browser without explicitly
> extending the JavaScript signaling code. The current proposed API
> assumes that JavaScript code understands the meaning of all the codec
> parameters to negotiate them on behalf of the user. If new codec is
> added, JavaScript would need to be updated to correctly select the
> parameters for new codec. We should provide a programming model where it
> is possible to delegate the codec selection and codec parameter
> negotiation to the RTC API while still allowing to do this negotiation
> from JavaScript.

Agreed, I think.

> P.S. I do find the current API proposal a bit deficient due to its
> inability to support forking, asymmetric codec selection, and delegating
> codec negotiation to the RTC implementation.

See my much earlier discussion of Forking support by modifying Harald's 
OFFER/ANSWER messages to include ACCEPT, which also helps solve the 
answer-time clipping issues.

(I'll try to dig it out of the archives and repost a link.)


-- 
Randell Jesup
[e-mail]