Search Mailing List Archives
[liberationtech] Open-source GSM network update
moxie at thoughtcrime.org
Mon Jun 20 17:26:57 PDT 2011
On 06/20/2011 07:53 PM, Nathan of Guardian wrote:
> However, I do remember asking Daniel (of Access) at the moment we made
> the call "Hey is this thing routing UDP or dropping it?" and he replied
> "It should be dropping it". I know that with the transproxying rules we
> use for Orbot, we drop all UDP. If any of the Access team are on this
> list, please join in and clarify.
Sounds like there might be a bug in that stuff, then. Seems highly
unlikely that the audio was being routed through Tor.
> The Freeswitch box did not have a public IP, and we did not do any
> special configuration to open TCP or UDP ports. However, I assume
> Freeswitch supports some kind of UPNP/NAT traversal capability that
> could have made them open up, and caused the auto-Tor rules to be
> bypassed as well. (see: http://wiki.freeswitch.org/wiki/NAT)
It normally just does STUN. In this case, though, where you're doing RTP
through NAT to a public PSTN gateway, no special techniques should be
necessary. The default NAT behavior would let the UDP flow at the RTP
layer. That whole thing tends to be more a problem when using UDP for
SIP (given it's asynchronous nature), which is why that got shoved up
into TCP for client links.
> In general, the way I have looked at doing VoIP over Tor in the past is
> through an OpenVPN or SSH-tunnel, which could also solve the UDP
> problem... however with more layers, comes more problems.
It'd be sweet, but I'm not optimistic. You'd have to add another
FreeSwitch endpoint, because the PSTN gateway isn't going to want to
talk SSH or whatever. But based on the acrobatics we go through to get
encrypted VoIP working acceptably over low-latency UDP links, I imagine
that RTP over TCP alone would be mostly unusable, and that RTP over TCP
over Tor would probably just be totally fucked.
More information about the liberationtech