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 -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
