[Telepathy] empathy broken during Debian freeze

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Apr 2 08:08:00 PDT 2013


On 02/04/13 11:14, Daniel Pocock wrote:
> 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:

This is not going to happen in Debian wheezy, which is already several
months behind its various upstreams due to the freeze, but yes.

Would it be desirable to support having STUN server != TURN server? I
suspect that the answer might be "yes in telepathy-gabble, but no in the
Empathy UI"? (If neither is given, the STUN server should default to
stun.telepathy.im, whereas the TURN server should default to nothing.)

Ideally, the TURN server should probably be discovered from DNS SRV if
not configured, like SIP does (daniel at example.com ->
_turn._udp.example.com or something).

Rather than having the password in the account settings in clear text,
it would probably be better to have a SASLAuthentication channel pop up
and ask for it, like we do for the main account password (in GNOME, that
channel is handled by the Empathy.Auth component, using gnome-keyring).
We don't yet have D-Bus API for asking for passwords other than the
server's "main" password. The first step would be for someone interested
in this to describe the use case on a Telepathy (freedesktop.org) bug.

> The implementation I made in Lumicall does TURN server discovery via DNS
> SRV and tries to use the SIP credentials as TURN credentials

That's all very well for SIP, where credentials are frequently passed
around without TLS anyway, but XMPP servers conventionally use TLS and
we default to strict SSL validation, so I doubt we should be handing out
the XMPP password on a clear-text TURN connection? I suppose we could
try using it if require-ssl = FALSE or something, but in an ideal world,
nobody would ever have that set anyway.

> 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.

I've asked for further logs on the Debian bug, with details of how to
get them. Hopefully that'll be more enlightening...

> - 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

The timing does sound suspicious, but I've re-checked the diff that I
sent in the unblock request, and nothing there seems relevant.

    S


More information about the telepathy mailing list