RE: Poll for preferred API alternative

I vote for alternative 1.

Even an imperfect SDP implementation will be easier to work with than one based on a completely new (and as yet undefined) model.  I share many concerns that have been expressed about SDP and the realization of the offer/answer model, but it will be easier to fix them than to start from scratch.

Regarding the level of the API, I resonate most with the argument that no use case has been described to motivate a new lower level API.  A potential reason to revisit this is to allow more flexibility to implement options (such as raw RTP or optional consent) that were precluded by past decisions of the groups.  If that is the goal it would still be easier (technically) to modify the current API than to create a brand new one.  A new lower level API will just complicate and delay specification, interop testing and deployment of the technology.

Let's fix what we've got.

Richard

Received on Friday, 7 September 2012 23:51:38 UTC