Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

[Bernard Aboba <[e-mail]>]

No, I'm saying that *if* a developer remains within the "single origin" model, that a number of requirements for peer-to-peer operation do not apply. 

Also that the APIs should also enable media to be sent over a websocket to the "single origin" as well as a PeerConnection. 


> Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
> From: [e-mail]
> Date: Wed, 19 Oct 2011 20:13:25 -0600
> CC: [e-mail]
> To: [e-mail]
> 
> 
> On Oct 19, 2011, at 12:39 PM, Bernard Aboba wrote:
> 
> > However, if we are opening the RANT queue, I do have a concern that relates to IETF RTCWEB.  And that is the number of dependencies that are piling up, even for simple scenarios.  Fundamentally, many of the issues we have been talking about arise from the need to support peer-to-peer media.  This is what drives the need for ICE (so recipient can authorize sending of media),  end-to-end security (e.g. to know/authorize where P2P media is going),  and to some extend DoS and congestion control functionality.   While I understand the need for P2P support, we do need to avoid imposing all of these dependencies in simple client/server scenarios.  For example, if all a developer wants to do is send media and signalling down a websocket, many of the concerns arising from P2P media evaporate.  When operating within the "single origin" model, it should be possible to maintain a very high degree of legacy interop, with no requirements for ICE, e2e security, etc.  
> 
> Bernard, let me just make sure I have this right. You are proposing all the voice and video going from browser A to browser B should be sent over TCP (via websockets) through the web server?
> 
>