On 02/04/13 10:58, Simon McVittie wrote: > On 30/03/13 09:23, Daniel Pocock wrote: >> It suggests that empathy gets TURN servers from Google. > (To be clear here: "peer" means the person you're calling or the person > who called you.) > > If you're using a Google account, telepathy-gabble will obtain a > temporary username/password for Google's TURN server and offer them to > the peer. If you and the peer can't communicate directly (even with > STUN), and the peer also supports TURN, you'll use TURN. > > If you're not using a Google account but the peer is, they'll obtain a > temporary username/password for Google's TURN server and offer them to > you. Again, if you and the peer can't communicate directly (even with > STUN), you'll use TURN. > >> I can't find >> anywhere to configure my TURN server manually. > No, I think that's a missing feature in telepathy-gabble. The TURN > server itself is the easy bit, really: the non-trivial part is getting > the necessary credentials to use it, either by obtaining a temporary > username/password per call via your XMPP server (similar to the > non-standard API offered by Google servers - I am not aware of any > standard equivalent), or prompting for a (username and?) password with a > SASLAuthentication channel. I'm familiar with the TURN credential concept, I've actually packaged both of the TURN servers in Debian and I'm keen to try empathy against them.
reTurn from reSIProcate - works for SIP or XMPP - available in wheezy - supports legacy STUN clients or full TURN clients - long term credentials configured statically in /etc/reTurnServer.config http://packages.debian.org/wheezy/resiprocate-turn-server Open TurnServer (from the Jitsi team): - works for SIP or XMPP - available in sid (just missed out for wheezy unfortunately) - no support for legacy STUN clients - long term credentials configured statically in text file http://packages.debian.org/sid/turnserver As both of these servers support long term credentials, I think it would be highly worthwhile to be able to use them with empathy. Possible config options in empathy: STUN/TURN server name: ? STUN/TURN server protocol: (UDP/TCP/TLS) Server supports TURN (checkbox) (Long term credential) username: (Long term credential) password: The implementation I made in Lumicall does TURN server discovery via DNS SRV and tries to use the SIP credentials as TURN credentials, this would also be a valid way to support TURN without changing the UI and without relying on Google. >> It would be a big >> surprise for many Debian users to find that all their media streams are >> silently routed via a Google TURN server. > This shouldn't happen unless both of these are true: > > * no other form of connectivity worked > * either you or the peer are using a Google account (in which case > Google is technically able to eavesdrop on your traffic anyway) > > On a reasonably non-hostile network (e.g. typical home or small office > NAT), STUN should usually be enough to get a call through. The STUN > server is configurable, and STUN is sufficiently low-bandwidth to not > need any special credentials or provisioning (Collabora provides a STUN > server, stun.telepathy.im, which is the default for Telepathy). Thanks for explaining this. For the issue at hand, - I've tested with two clients on the same LAN (against ejabberd on squeeze) and they still don't work. - TURN was a first guess because I saw the Google server messages in the log output, but your explanation suggests I should ignore that - could any other change in the recent upload (4 March) have contributed to the problem I am facing? http://packages.qa.debian.org/t/telepathy-gabble.html It was working for me before that with the same clients network setup. The only thing that has changed is that all clients updated to the latest wheezy within the last 2 weeks. _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
