Bug#682010: [mumble] Communication failures due to CELT codec library removal
Thanks Don,
I've dropped Thorvald from the CC list, because he's on VAC for a week,
and wasn't looking forward to coming back to a mailbox full of stress.
If others would be good enough to do the same, I'm sure he can more
quickly come up to speed with whatever summary we've got when he's back.
It's all in the BTS log if he needs to dig deeper than that.
On Fri, Jul 20, 2012 at 11:50:16AM -0700, Don Armstrong wrote:
> summary 682010 0
> forwarded 682010 http://git.donarmstrong.com/?p=debian-ctte.git;a=blob;f=682010_celt_and_mumble/682010_celt_and_mumble.org
> thanks
>
> * Issue #682010
> ** Mumble in unstable/testing currently cannot interact with other clients and servers
> + Due to the removal of celt 0.7.1 (?)
Due to Debian and the Xiph authors dropping celt,
and mumble dropping speex in the unstable version.
> * Possible solutions
> ** Include celt 0.7.1 as a convenience copy
> + Security Issues with embedded copies
> + Unspecified possible security issues
Embedding a copy doesn't add to the baseline risk here, since mumble
is the only thing with any excuse at all to still be using celt today.
It actually minimises the risk, because then only mumble can be exposed.
This was the original plan we (Thorvald and I) made before the squeeze
release, since celt being obsoleted by a final bitstream stable codec
for all other users was a known future at that time. Mumble also
planned to drop it too, but that was going to take longer to do, so
this was the transition period solution for it.
What stopped that plan from going to plan was the advice received about
a potential remote crasher, and the total absence of anyone prepared to
take responsibility for continuing 'upstream' maintenance of celt.
> ** Upload a celt 0.7.1 package
> + No maintainer desires to deal with this (apparently?)
> + Unspecified possible security issues
It's not so much a "lack of desire" as an explicit (and reasonable IMO)
request from the celt authors that we no longer distribute this obsolete
version in a way that might cause confusion about whether it should be
used by new or current projects (which it should not, since it is
bitstream and API incompatible with versions shipped by all other distros).
The only thing with a valid reason to still use it at all is mumble,
because it specified it as the default high bandwidth codec for use
in its private protocol, and is not required to be interoperable
with any other application. As the only user, it doesn't need a
public dev package, or separate lib for this. On every other distro
except Debian, mumble already builds using its own embedded version
(since no other distro shipped 0.7.1 or a version compatible with it).
> ** Use speex instead
> + Server (and clients?) do not select speex as an option unless bandwidth is low
Speex (and Opus) are much lower bandwidth codecs than celt. If the
configured bitrate is above 32kb/s then pre-opus mumble will prefer
to use celt. This limitation is what Thorvald thinks he can remove
when he gets back, in a way that will be backward compatible for all
clients. If that works as expected, then speex is a viable (and also
maintained) baseline codec for people without Opus.
> ** Use only opus
> + Not yet (?) released upstream
> + May not communicate with non-opus clients
Just in case the distinction isn't clear, Opus itself is released.
(since there was some FUD earlier about that). A good summary of
its current status can be found here:
http://hacks.mozilla.org/2012/07/firefox-beta-15-supports-the-new-opus-audio-format/
The code to enable using Opus is available in mumble's git repo.
A formal release of that is bottlenecked behind Thorvald being
available, but he said he plans to do that when he gets back
next week too. That's mostly only an issue for windows users.
All clients need Opus in this case. There are released servers that
already support this (since the server doesn't need explicit codec
support, only some protocol tweaks which were done a while back)
but the server version in squeeze is apparently too old for that.
> * Open questions
> ** Can speex be made to be an option?
> ** Is a convenience copy acceptable, assuming mumble is the only thing with it?
> ** What are the other clients that we want to make sure the mumble servers can communicate with?
> * Involved parties
> ** Chris.Knadle@coredump.us, Ron <ron@debian.org>, 682010@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>
>
> The above is my current understanding of this bug. Please correct
> anything that I've gotten wrong or misunderstood or missed.
I think that's roughly right. If there's anything more people need
clarified or answered, just ask.
The plan from yesterday, which seemed to have agreement from everyone
but Ian is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#94
And I'm still not quite clear what his objection was, because the
response I got was:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124
And I wasn't able to elicit what else he was actually concerned about,
but if there is something we missed, I do really want to know about it.
Cheers,
Ron
Reply to: