I should have a REF for CORS to http://www.w3.org/TR/cors/ Let me over simplify CORS and explain the part that is key here - note this explication is not exactly accurate but it is close enough to the the key idea. The idea with HTTP, is that say a java script program in a page downloaded from X wants to send an HTTP request to Y. What happens is first the browser sends an OPTION request to Y. The javascript had no control over anything in the options request so it is hard to mount a useful attack on Y this way. In the response to the options, Y says if it is willing to accept HTTP request from the something that had origin of X. If Y is will to receive traffic from something that originated from X, then the browser sends the request from the javascript over to Y. The idea here is to do the same thing with SIP. Before the browser would send a SIP request that the browser applications wanted sent, the browser would send a SIP OPTIONS request and the SIP server would authorize future requests or not. The same headers used for CORS in HTTP could be used in SIP. It would be a pretty simple mapping. The nice part form my point of view is that the security properties of it are very close to the security properties of CORS. CORS is widely deploying so I don't see a security problems with this widely deploying. On Mar 11, 2011, at 10:19 AM, Bernard Aboba wrote:

Section 1.3.3 states:

The security issue of a browser sending a SIP packet to a device that does not meet the same origin policy is discussed in the section XXX, but the brief preview of the solution is that the SIP messages can

use CORS REF much like a HTTP does.

Can you elaborate? Unlike the media authorization discussion (where a STUN exchange is used to authorize media exchange), it isn't clear to me how authorization works here.

On Thu, Mar 10, 2011 at 12:20 PM, Cullen Jennings <fluffy@cisco.com> wrote:

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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

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@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Cullen Jennings Sent: 10 March 2011 20:21 To: rtc-web@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web