[tor-talk] Ostel and WebRTC over Tor?

[Fabio Pietrosanti (naif)]

Il 2/12/14, 9:54 PM, Nathan Freitas ha scritto:
> On 02/12/2014 03:09 PM, Griffin Boyce wrote:
>> Jon wrote:
>>>> Guardian Project did a ton of experimenting with this in late 2012:
>>>> https://guardianproject.info/2012/12/10/voice-over-tor/
>>   That's *awesome!*  Maybe Ostel just relies on UDP / doesn't support
>> TCP fallback.  Their site FAQ states that "No Voice over IP services
>> work over a Tor connection due the limitations of the Tor network and
>> VoIP protocols," which is clearly not correct.  More research is needed,
>> but that post has some good insights.
> Yes, that is exactly the issue with stock VoIP clients. It is quite
> difficult (impossible?) to get Jitsi, CSip or Linphone to send the RTP
> stream over TCP. Perhaps it is also our server (Kamalaio) or media proxy
> configuration... something to dig into.
In the company i was CTO doing mobile voice encryption some years ago,
we made testing regarding this kind of problem, especially for
tunnelling voice over HTTP (that's over TCP).

That's a weird problem that can be fixed by using some "non
conventional" transmission techniques, together with very adaptive
jitter buffering techniques.

The "problem" is that a single TCP connection can "temporary hang on TCP
retransmission" (due to exponential backoff algorithm) and that's what
kill a voice connection, forcing jitter buffer to increase up to several
seconds of delay.

However by having "many" transport channels (many TCP connections) and
sending x5/x10 copies of the same audio payload over multiple streams
(as many as the copies of the payload), the likellyhood that a single
payload will "temporarly hang" between the sender and the receiver
drammatically decrease.

Given that today we have narrowband codecs  and that over high-latency
channel we can pack several 20ms sample together easily (also in packets
of 100ms size to reduce the amount of packets/s), the effective overhead
of sending/receiving 10 times more the amount of data is something
acceptable.

Obviously the multimedia transport channel must take into account all of
those kind of issues, must also trash channels that get congested
establishing new ones, etc, etc

The jitter buffer must also understand that's working in a quite shitty
environment, so all of the optimization of adaptive jitter buffers for
burst based networks (like GPRS CS1) apply.

-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org