[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#682010: [mumble] Communication failures due to CELT codec library removal

I've updated the summary with the suggested changes (at the end).

On Sat, 21 Jul 2012, Ron wrote:
> I think that's roughly right. If there's anything more people need
> clarified or answered, just ask.


> 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

The objection is that the issue has been raised before the CTTE, so it
needs to be resolved first before action is taken. From what I
understand now, while we could fix up some of the RC issues with the
client/server in testing and unstable, we'd need yet another upload of
mumble to unstable with propagation to testing in order to actually
fix the client inter-operation bug.

From what I can tell now, the ideal solution is to wait until Thorvald
has a chance to enable speex for all bandwidths. If that is
impractical/impossible then we get to choose between a convenience
copy of celt, not releasing mumble, or releasing with opus. Is that
the understanding of everyone else?

* Issue http://bugs.debian.org/682010 http://bugs.debian.org/675971
** Mumble in unstable/testing currently cannot interact with other clients and servers
   + Due to the removal of celt http://bugs.debian.org/676592 and disabling of celt compilation options
   + Mumble dropping speex in unstable and speex not being selected at higher bandwidths
   + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971#51
   + Interoperation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971#61
* Possible solutions
** Use speex instead
   + Server (and clients?) do not select speex as an option unless bandwidth is low
     + May be resolved by Thorvald Natvig with a hack
   + Clients cannot currently report speex version during codec selection process
   + Requires code modification for selection process and re-enabling speex
** Include celt 0.7.1 as a convenience copy
   + Security Issues with embedded copies
     + Mitigated as mumble would have the only copy
   + Unspecified possible security issues
     + Potential remote crasher
   + -348 is currently this way in testing
** Do not release with mumble
   + Unsatisfactory to users of mumble
** Upload a celt 0.7.1 package
   + No maintainer desires to deal with this (apparently?)
   + Upstream do not wish additional packages to use celt; wish transition to opus
   + Unspecified possible security issues
   + Proliferates celt library downstream
   + Deprecated upstream
** Use only opus
   + Opus itself released upstream
   + Code to enable opus in mumble has not been released
   + Will not communicate with non-opus clients or servers
   + Unlikely to be RM acceptable at this point
* Open questions
** Can speex be made to be an option?
   + Thorvald thinks so; no patch as of yet (off for a week?)
** Is a convenience copy acceptable, assuming mumble is the only thing with it?
   + Possible remote crasher bug is the primary objection to allowing this
** What are the other clients that we want to make sure the mumble servers can communicate with?
| client/server      | Deb 1.2.2-6+squeeze1 | Deb 1.2.3-2+b2 | Deb "348" | Deb "349" |
| Deb. Client "348"  | Yes                  | Yes            | Yes       | Yes       |
| Deb. Client "349"  | No                   | No             | Yes       | Yes       |
| Win. Client 1.2.3a | Yes                  | Yes            | Yes       | Yes       |
| Win. Client "361"  | Yes                  | Yes            | Yes       | Yes       |
| Mac  Client 1.2.2  | Yes                  | Yes            | Yes       | Yes       |
* Resolutions
* Involved parties
** Chris.Knadle@coredump.us, Ron <ron@debian.org>, 682010@bugs.debian.org, 675971@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>

Don Armstrong

Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38

http://www.donarmstrong.com              http://rzlab.ucr.edu

Reply to: