[guardian-dev] WebRTC

[Lee Azzarello]

I have anecdotal evidence of webrtc throughput based on using this
example application

https://chatb.org

There were connectivity issues surrounding NAT traversal with a few
parties during a conference but I got two video channels. I don't
think the protocol itself is the bottleneck for throughput.

-lee

On Fri, Aug 9, 2013 at 9:45 PM, Tim Prepscius <timprepscius at gmail.com> wrote:
> Hey there,
>
> does anyone have any real world data on throughput using webrtc?
>
> I'm running in Chrome, and I swear I'm getting about 1kBytes/s
> throughput (data not video/audio) on localhost (browser to same page
> browser).
>
> It's pathetic to say the least.  Are other people seeing the same
> thing for non localhost.
>
> Is this what other people are seeing?
>
>
>
>
> I have a proof of concept done - where the browser intercepts google
> searches and forwards them over a webrtc connection  - and then sends
> back the results, which then get wamped back to the google page using
> a fake XMLHttpRequest object.
>
> But the bandwidth issue is putting a damper on things.  I can zip
> things, but still will be too slow.
>
> -tim
>
>
> On 8/7/13, Timur Mehrvarz <timur.mehrvarz at riseup.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/07/2013 03:53 PM, Michael Rogers wrote:
>>> On 07/08/13 13:27, Timur Mehrvarz wrote:
>>>> I can now demonstrate how WebRTC traffic can be
>>>> redirected/relayed/forwarded (not using ICE/TURN) so it becomes
>>>> impossible for clients to discover each others IP addresses
>>>> etc., while still using WebRTC end-to-end encryption.
>>>> http://mehrvarz.github.io/rtcchat2/#relayed
>>>
>>> "Starting a session, both browsers will send their SDP (Session
>>> Description Protocol) "offers" and "answers" over HTTPS to the rtc
>>> chat rendezvous service. To establish a relayed WebRTC
>>> communication link, the rendezvous service will modify the SDP data
>>> on the fly."
>>>
>>> It worries me that the clients don't detect this modification!
>>> Isn't there any end-to-end integrity checking in SDP?
>>>
>>> Cheers, Michael
>>>
>>
>> The worst that can happen is that, while you are trying to talk to
>> Bob, you are being tricked into talking to Jim. No SDP end-to-end
>> integrity check could prevent this from happening. If identity
>> verification is needed, it should take place on top of an established
>> WebRTC link. In most cases, you will be interested in knowing who you
>> are talking to. Not what their IP address is. The true Bob could be
>> anywhere.
>>
>> Timur
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJSAmSwAAoJEBdAei8mIIKcPm0H/jqArXw2rRSnNMtRQooX8O5W
>> 87h8STjVDLuL3HQvyHBWnnfuUMVPUztmxYL7ZVnlxt98SSQVvUx7k4Y0cm9RO+3d
>> H7zJCBAfT/I4/W76JikmClcoEnpd9JZ8uMuKnMA2EPHAecFrIKZAfQNlflejAufy
>> NgqskHfYxLahiFMGDjs3Eu5E6vQUcUAWctQ6/cTypv3YVypof/fBhJc+clrRplmz
>> XtyrOo+M3Qx39iEM2/9C+yfwv/seEgM+1r/UPNeXCyhYE2lBOp8usP7S1K4WXaAu
>> McpzVIXEZlRO/hVBZA/NTDaBfi5GMt/Eprv2dp16TEc+I2NZefT5oJSU2nyNBOc=
>> =x5z0
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/guardian-dev/timprepscius%40gmail.com
>>
>> You are subscribed as: timprepscius at gmail.com
>>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info