Re: Cisco's position on the WebRTC API

On 24/07/2013 1:52 AM, Eric Rescorla wrote:
> I assumed you had other (unannounced) meetings since then because it's 
> almost been 2 months.stopping developers from posting directly here.
>
> Which developers have been stopped from posting directly here and how?
> As far as I know this is an open list.

     Looks like a typo caused while I was deleting quoted text. I didn't 
write the part after "almost been 2 months."



>         I understand that. All I was saying is I don't understand the
>     coupling between the Browser API and Telecom requirements. I mean,
>
>       * If the WG is producing an API for web browsers (not Telecom
>         gateways), and
>       * It's technically feasible to layer a Telecom API on top of
>         this (that uses SDP)
>
>         then why is the WG mandating this part of the spec? Why isn't
>     it "out of scope" like the initial offer/answer transport I layer?
>
> I don't understand this question. There was extremely extensive debate 
> about
> the API style and a WG decision was taken to proceed along the lines 
> of the
> current API. It's neither appropriate for useful for me to try to 
> recapitulate
> the entire debate here. I refer you to the archives and meeting minutes.

     My understanding is that:

 1. Telecoms need to be able to use an SDP transport layer.
 2. We are keeping SDP in the existing API order to save time (release
    1.0 as soon as possible, then review).

     I brought this up because:

  * We agreed that our goal is to generate Constraints for all major
    use-cases so users wouldn't have to interact with SDP directly.
  * For the remaining cases (experimental use-cases), we initially said
    that users could manipulate SDP directly but then I brought up the
    possibility of using experimental Constraints behind a flag instead.
    It was my understanding that you agreed to investigate this possibility.

     My assumption (am I wrong?) was that there were no remaining 
reasons for users to interact with SDP directly. If that's truly the 
case, you can continue using SDP under the hood but remove it from the 
public API at no additional cost to the WG.

Gili