Re: Poll for preferred API alternative

On Aug 29, 2012, at 6:30 AM, Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> wrote:

> The discussions of Aug 28 showed that there are people with differing opinions on the structure of the API this WG should design.
> 
> Most of the work in front of this group currently is dependent on a basic decision between those two approaches - the issues to be resolved (for example congestion control and RTP stream mapping) are in many cases present in both proposals, but the API specifications that need to be developed look a lot different.
> 
> 
> It is not efficient use of the group’s time to work out detailed, implementable proposals that then are thrown away because of a later decision - nor is it a working environment conducive to inspiring volunteers.
> 
> The two alternatives, as the chairs see them, are the following:
> 
> 1) Continue with a design based on the PeerConnection object, using SDP as part of the API, roughly in the style of the current API description.
> 2) Remove the PeerConnection object and all use of SDP from the API, and pursue an API roughly in the style of Microsoft’s CU-WebRTC proposal.
> 
> In order to make this call, we’re calling for the WG participants to make their opinion known, by indicating one of three alternative opinions:
> 
> 1) The group should continue with a design based on the PeerConnection object, using SDP as part of the API.

Cisco prefers this choice - specifically we think the WG should stick with the previous decision to use 3264 Offer / Answer. Please note that a change in this decision would probably require coordination with IETF about scope of work between the two SDOs. 


> 2) The group should remove the PeerConnection and all use of SDP from the API, and pursue a design based on the CU-WebRTC proposal.

I will note that if we reverse the previous decision and decide to go with a low level API, we would want to make an alternative low level API proposal. Note this is not a new point - I've said this every time this has come up but we will need time to do that if we go down this path. 

> 3) This participant does not have enough information to state an opinion at this time.
> 
> The chairs will make the result of the opinion tally public after the end date.
> 
> If this call results in a clear preponderance for one of the alternatives, the WG chairs will take that as direction - if the last alternative has a clear preponderance, the WG chairs will direct the WG pursue further discussion of this topic only, putting all other work on hold until this is resolved; in the two other cases, the chairs will direct the WG pursue the chosen design option, and leave the other to others to follow up if they wish, but not drive it further in the WG.
> 
> This is not a vote - it is a tallying of opinions. If a preponderance of preference is clear, the chairs will ask the WG if it agrees that a consensus exists to proceed based on that preference.
> 
> Please state your opinion before Friday, Sept 7, and communicate this to the chairs. Mail to the list is an acceptable means of communicating your opinion.
> 
> Stefan for the chairs
>

Received on Wednesday, 29 August 2012 15:45:36 UTC