Re: default messaging/VoIP client for Debian 8/Jessie
On 31/03/14 12:12, Simon McVittie wrote:
> On 31/03/14 10:27, Josselin Mouette wrote:
>> Le dimanche 30 mars 2014 à 11:04 +0200, Daniel Pocock a écrit :
>>> Currently, Empathy is installed by default
> I think you might be conflating "present in a default desktop
> installation" with "recommended by the project for all of its possible
> functionality". IIRC we install nano and nvi by default, but I think
> most DDs would recommend emacs, vim and/or a GUI editor over either of
> those for many purposes :-)
>
>> Empathy is the default for GNOME, and I do not see a convincing reason
>> to change that.
> <hat type="Debian pkg-telepathy maintainer">
>
> Empathy is a simple UI for text chat, presence, file transfer and basic
> VoIP with excellent GNOME integration. It is appropriate to include it
> in some GNOME metapackage; I have no opinion on whether it should be in
> a tasksel-driven installation of Debian-with-GNOME[1].
Just to clarify, it is not mandatory to install any of Empathy at all
when installing a GNOME desktop and the whole of Empathy could be left
out if GNOME is the desktop and another client (like Jitsi or Pidgin)
was preferred by the Debian community?
>
> It is not currently a replacement for a fully-featured telephony stack:
> if you pick a random high-quality SIP implementation, it probably does
> several things that Empathy/Telepathy don't. Users with "enterprise"
> VoIP requirements are likely to be better off with something else. I
> have not assessed whether Jitsi is the correct "something else", but
> it's one possibility.
>
> Would it address your concerns about Empathy if the gnome metapackage's
> dependency on telepathy-rakia was weakened to Suggests, resulting in
> Empathy lacking SIP support in a default Debian-with-GNOME installation?
Quite the opposite - if somebody does choose Empathy, I'm quite happy
for them to automatically benefit from telepathy-rakia if that is the
only option for SIP support within Empathy. If there were two possible
SIP modules for Empathy, then it would be nice to have a way to choose
and not be locked in to one of them.
The bigger worry is choosing things like
a) which client handles the xmpp: and sip: URIs by default.
b) should the client run automatically on login (with an easy way for
users to disable it) and if so, which client
> </hat>
>
> <hat type="Telepathy upstream maintainer">
>
> Like Pidgin, Telepathy primarily comes from an "instant messaging"
> background/history: it mainly competes with Pidgin, Google Talk, Skype
> etc. The fact that some of its supported protocols can also be seen as
> competing with the PSTN is currently secondary.
The XMPP support is quite effective and compelling too, as long as TURN
is not required for an audio/video call. I've used Empathy a lot for XMPP.
> We don't currently have enough developer time to be trying to compete
> with a fully-featured telephony stack (and in particular, the former
> primary maintainer of our SIP implementation, which was never
> particularly comprehensive anyway, is no longer active). Anyone who
> wants to close the gap is more than welcome to help us.
>
> In particular, we would love to see:
>
> * an upstream maintainer for our SIP implementation and the library
> behind it (telepathy-rakia + sofia-sip), or a new SIP connection
> manager replacing Rakia using a more actively-maintained library
Just some comments on that:
a) reSIProcate is an excellent choice for a SIP stack, but as it is C++,
I don't know if you would go with it
b) Asterisk recently moved to PJSIP, so that might also be a better
choice than Sofia SIP
c) the FreeSWITCH people have forked Sofia SIP, so if there is no other
option, then it may be desirable to get in sync with their fork then
there will be a higher chance of packaging FreeSWITCH and also a higher
chance of keeping up to date with security
> * a reasonable UI design, and the implementation to back it up, for
> out-of-band configuration of TURN servers and TURN credentials
>
> * a XEP for automatic provisioning of TURN credentials from XMPP
> servers (functionality equivalent to what telepathy-gabble supports
> for Google Talk), so that users of XMPP services other than Google
> Talk can use their service's TURN servers transparently
>
> * encrypted RTP via keys negotiated through the server
> (trusting the server - more trust involved than full end-to-end
> security, but also much much easier)
WebRTC expects DTLS-SRTP negotiation. Many users also want ZRTP.
Libraries are available for both, but there is work involved to get it
into Empathy.
> * full end-to-end security (fair warning: this is Hard, and unlikely
> to be a good project for beginners - try something else first)
>
> but for any of those to happen, someone else is going to have to drive it.
Thanks for clarifying all of that
My reading of this situation is that these are not things that are
currently scheduled to happen before the Jessie freeze
If developers were keen to help and spend time in this area, would it be
better to spend that effort on getting Jitsi (or another softphone) to
work more smoothly within GNOME or to get Empathy to fill in the gaps
discussed in this email or something else?
Reply to: