RE: Poll for preferred API alternative

After careful studies and internal discussions, Huawei representatives have formed the following opinion on the poll.

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.

We prefer this choice at this point.

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.

CU-WebRTC is also a well-structured proposal that provides applications with flexible control over transports, media streams and their relations. However, we think completely removing PeerConnection and SDP from the API is risky at this stage since such radical change may delay the API that has been demonstrated to work by some browser implementations. 

We hope that the Microsoft team can work with the WG to bring the useful ideas, solutions and components from their proposal into the standard so we can have a standard that is supported by all major browser vendors.

Thanks.

Li Li and Sun Yang
Huawei Technologies Co., Ltd

> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: Wednesday, August 29, 2012 8:30 PM
> To: public-webrtc@w3.org
> Subject: Poll for preferred API alternative
> 
> 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.
> 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.
> 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 Friday, 7 September 2012 00:32:51 UTC