[RTW] New draft on WebRTC API draft-jennings-rtcweb-api

[Cullen Jennings]

On Mar 11, 2011, at 10:56 AM, Elwell, John wrote:

> Cullen,
> 
> I need some clarification on this.
> 
> 1. The Advertisement Proposal Model in section 1.1. No real surprises here, and I think it is consistent with the model I had in my mind from what various other folks have posted. Just one question: although the browser app would use the ad/prop pattern to interact with the browser, I assume the intention is that it would still permit offer-answer on the SIP path between servers (or between a server and a conventional SIP entity). Correct?

Yes - I view that as something I want in the solution. The mapping from Adv/Prop to SDP Offer/Answer could be written in Javascript running in the browser or it could be in server sitting somewhere in the web that some javascript communicated with over something as simple as just an RPC of the Adv/Prop. 

> 
> 2. The Offer Answer Model in section 1.2. From the figure, it is not clear whether the SIP UA is in JavaScript or in the browser, although the rest of the paper it seems to suggest the latter, so I assume that is the case.

Yes, the browser would have SIP stack that was capable of doing the part of SIP to set up a media session but not the rest of SIP. 

> I think the essence of this is a tradeoff between more functionality (SIP) in the browser versus more in the application. The paper seems to say that applications that just want to use a basic session capability without worrying about details could use this approach, without having to incorporate a SIP stack etc.. On the other hand, applications that want to provide a comprehensive real-time communications experience, e.g., with automated handling of incoming calls, multimedia/telepresence, fine-grained user controls over audio/video quality, media security, capabilities such as transfer and hand-off between devices, etc., would use the first approach. Is this a fair summary of what you are proposing?

Yep - fair enough. I'd think of it a bit more as the interface in 1.2 provides something so easy, that anyone that could use a video tag in HTML5 could use this. I think of the 1.1 interface as providing a rich enough interface that someone with a deep knowledge of real time unified communications could do whatever they wanted to do. Note I am not arguing for one vs the other but arguing we need both - if I had to pick one, I'd point out than on the web, simplicity for the person using the library beets simplicity for the person implementing the library. 

> 
> 3. With the offer-answer approach and a SIP/SDP stack within the browser, the bar for browser compliance is raised considerably. We all know that interoperability has proved difficult with SIP/SDP, more so than RTP and some codecs, say. I recognise this is somewhat alleviated by the limited SIP profile you propose (and presumably a limited profile of SDP could be used). However, it could certainly delay the availability of RTC-Web support in browsers and increase interoperability uncertainties. Your opinion?

Henry pointed out to me that SIP was complicated and had options that didn't work together because we made it that way. The range of SIP RFCs were meant to be a toolkit where particular tools could be selected to build a system. To make this RTCWeb stuff work, we are going to have to select a set of interoperable tools for this particular system and that is going to mean choosing. Obviously conversations about what to break to simplify things are complicated. 

The problem is that many of these types of decisions require that conversation to happen regardless if if is an Off/Ans style API or the Adv/Prop. The Adv/Prop needs to expose enough to create the SDP, and doing that results in the same arguments about what needs to be supported or not. Part of the reason I showed these API is because as you start looking at this, you realize that Adv/Prop has hard choices to be made too. My API assumes we can mandate the rate for G.711 is 8000 - that will break things. The 264 configuration has 41 parameters in it and I'm sure it is wrong and missing things. The parts of SIP that had interoperable problems were not if the SIP headers use the abbreviated forms or not, they are to do with things like what the SDP meant in the various states, how security keying worked, how DTMF was done, what codecs need to be there and more importantly the modes they supported. Theses issues impact both these API at about the same level. Other SIP interoperability issues like hold, transfer don't impact either of the Adv/Prop or Off/Ans API proposed here. Other issues like sips have caused interoperability problems in the past but we have learned how to avoid theses (don't do sips) and that will help make this work easier. 

So I agree with you that the hardest parts of interoperability on these APIs are the SDP issues. However, I don't think the SDP issues in the Adv/Prop model are any easier. Consider any of the hard interoperability problems we have had in SDP - we have to solve the same arguments about what we break in either API model. 


> 
> Nit: Both 4 and 4.2 have the title "Connection API".

Oops - thanks. This draft needs a lot of work. 

> 
> 
> John
> 
> 
>> -----Original Message-----
>> From: rtc-web-bounces at alvestrand.no 
>> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Cullen Jennings
>> Sent: 10 March 2011 20:21
>> To: rtc-web at alvestrand.no
>> Subject: [RTW] New draft on WebRTC API draft-jennings-rtcweb-api
>> 
>> 
>> I wrote up the start of a draft on requirements and a sketch 
>> of an API proposal. It is at
>> 
>> http://tools.ietf.org/html/draft-jennings-rtcweb-api-00
>> 
>> I view this as very early but starts to list some of the 
>> issues and an evolving sketch of how the API might look. 
>> 
>> Cullen
>> 
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>