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

[Chris Knadle]

On Tuesday, August 14, 2012 11:36:33, Ian Jackson wrote:
[…]
   13. The mumble maintainers, with appropriate help from other
  interested parties, should prepare an upload of mumble for wheezy
  with
- embedded celt 0.7.1 enabled
- no other version of celt enabled
- whatever other release-critical bugfixes they consider
   relevant (subject to any appropriate discussion with the
   release team as necessary)
- closing #675971.

Option 1:

I've prepared another version of Mumble based on the mumble-1.2.3-412-g6c9694d 
release snapshot on August 3rd.  This pacakge is built as described above, and 
also supports Opus via the Debian opus system library which uses Opus version 
0.9.14.  I've tested:

   - communication via Opus with the 349-2 version in Sid
   - communication via Opus with another version of the 412 pacakge
 that uses the embedded 0.9.8 version of Opus that ships with the
 Mumble upstream source
   - communication via Celt 0.7.1 with several other clients



Option 2:

Using the mumble-348-fixes-embedded patch I sent on Aug 1st, and upload a new 
version of 348 that's in Wheezy.  [Needs modification to add a Closes: 
#675971 in the changelog.]  I haven't yet gotten any feedback on the patch.

Related question: Can a DD upload a package to Sid with a lower version number 
than what is currently in the archive?



Option 3:

Manipulate the 349-2 source in Sid, fix it, and upload a 349-3.  I was 
investigating this in order to minimize the diff necessary, but I'm not sure 
what all of the implications are of the modifications done to the 
orig.tar.gz tarball compared to the upstream repo it's based on.  Some of 
the changes simply look like they might be innocuous autoconf stuff added, but 
there are also some scripts and build files removed.  File containing the list 
of differences attached.  This option would inolve reverting one Git commit in 
order to remove debian/patches/10-use-celt-guard.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
# Steps to repeat results above:
# From local clone of upstream Mumble git repo, make tarball of the 315b5f5 
commit from 2012-05-31 06:46:56
git archive --prefix=mumble-1.2.3-349-g315b5f5/ -o 
mumble-1.2.3-349-g315b5f5-upstream.tar 315b5f587910983d764955f456fe64e696a786cc
# make a new directory somewhere, untar 'upstream' tarball and rename
# directory with a -upstream added, untar orig mumble tarball and rename
# with a -sid added, do a recursive diff on the two directories
diff -u -r ./mumble-1.2.3-349-g315b5f5-upstream ./mumble-1.2.3-349-g315b5f5-sid


$ colordiff -u -r ./mumble-1.2.3-349-g315b5f5-upstream 
./mumble-1.2.3-349-g315b5f5-sid 
# Note: Only in .. upstream means the file is missing in the Sid version
#   and Only in .. sid  means the file doesn't exist in the upstream 
version

# Not in the Sid source tarball:
Only in ./mumble-1.2.3-349-g315b5f5-upstream: 3rdPartyLicenses
Only in ./mumble-1.2.3-349-g315b5f5-upstream/celt-0.11.0-build: win32
Only in ./mumble-1.2.3-349-g315b5f5-upstream/celt-0.7.0-build: win32
Only in ./mumble-1.2.3-349-g315b5f5-upstream: doc
Only in ./mumble-1.2.3-349-g315b5f5-upstream: Doxyfile
Only in ./mumble-1.2.3-349-g315b5f5-upstream: .gitignore
Only in ./mumble-1.2.3-349-g315b5f5-upstream: .gitmodules
Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons/flags: readme.txt
Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons: g15helper.ico
Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons: mumble.osx.installer.png
Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons/publicdomain: readme.txt
Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons/tango: README
Only in ./mumble-1.2.3-349-g315b5f5-upstream: installer
Only in ./mumble-1.2.3-349-g315b5f5-upstream/macx/overlay: avail.h
Only in ./mumble-1.2.3-349-g315b5f5-upstream/macx/overlay: avail.pl
Only in ./mumble-1.2.3-349-g315b5f5-upstream/macx: scripts
Only in ./mumble-1.2.3-349-g315b5f5-upstream/opus-build: Win32
Only in ./mumble-1.2.3-349-g315b5f5-upstream/plugins: mumble_plugin_win32.h
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: addban.php
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: binserver.pl
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: ermine.conf
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: git2cl.pl
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: glacier
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: idle.php
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: ListUsers.cs
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mkflags.pl
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mkini.sh
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mklic.pl
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mkwrapper.pl
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mumble-auth.py
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: php.ini
Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: qt.conf
Only in 

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

[Chris Knadle]

Ron --

Can you please let me know the procedure for how to verify the orig tarball 
for the 349 version in Debian Sid?

Up to and including the 348 version of Mumble in Wheezy that Patrick Matthäi 
had been packaging, the tarballs clearly came from the upstream snapshots 
located at [1], so those are simple to verify via 'diff' directly.

But the 349 version in Debian Sid doesn't come from there; instead the 
tarball is somehow created from the upstream Git repo.  'pristine-tar list' 
doesn't come up with any tarballs, so in a local clone of the upstream Git 
repo I did a checkout on commit 315b5f587910983d764955f456fe64e696a786cc that 
the 349 orig tarball seems to be based on, a checkout of commit 
43a04a7e813d3e420409c5465b71af148e779717 in your Git tree that the 349 orig 
tarball seems to be based on -- but when I try to compare the directories I 
see a bunch of files that are only in the upstream directory or vice-versa.

So would you mind giving me a pointer for how to verify the tarball?
Thanks.

[1] http://mumble.info/snapshot/

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ian Jackson]

I think the rate at which we are gaining new reliable information has
reached diminishing returns.  I think it is time to dispose of this
issue.

I think the right answer for a TC decision looks something like this:

  Context:

  1. The questions surrounding the codecs in mumble, especially celt,
 have been referred to the Technical Committee.

  2. The mumble maintainers have stated their willingness to follow
 our advice (Constitution 6.1(5)).  This may or may not amount to
 a delegation to us of the decision (6.1(3)) but in any case we
 merely need to state our reasoning and conclusions and are not
 being asked to overrule the maintainer.

  Release Critical status of celt 0.7.1 in mumble:

  3. mumble is a useful and fairly widely-used voice chat program.

  4. Distributions of mumble (from other distros and upstream)
 currently implement the celt 0.7.1 codec as a baseline.  It does
 not appear to the TC that (in wheezy) the provision of any other
 codec obviates the need for mumble to support celt 0.7.1.

  4. Consequently, we consider the lack of celt 0.7.1 support in
 mumble a release-critical bug.

  Security risks from celt 0.7.1:

  5. While the upstream security support situation for celt 0.7.1 is
 not ideal, the TC does not consider that the security risks
 associated with celt 0.7.1 in mumble are intolerable.

  6. The Debian Security Team have stated that they have no objection
 to including celt 0.7.1 in mumble in wheezy.

  7. Consequently, mumble should remain in wheezy with celt 0.7.1
 (the alternative being to remove mumble as unfit for release).

  Packaging approach:

  7. There are no other packages intended for wheezy which ought to
 want this codec.

  8. Providing separate celt library in wheezy is undesirable because
 it might promote the use of a codec which we are planning to
 retire in the medium to long term.

  9. While embedded code copies are in general to be avoided because
 lead to proliferation of multiple versions, that therefore does
 not apply in this case.

  10. The upstream mumble source already contemplates building with
 various embedded versions of celt.

  11. There is no reason to support any other version of celt in
 mumble.

  12. Consequently, the mumble source package should be configured to
 use an embedded copy of celt 0.7.1.  (If necessary the embedded
 copy of celt in the source package should be updated to the
 actual 0.7.1.)

  We therefore recommend that:

  13. The mumble maintainers, with appropriate help from other
 interested parties, should prepare an upload of mumble for wheezy
 with
   - embedded celt 0.7.1 enabled
   - no other version of celt enabled
   - whatever other release-critical bugfixes they consider
  relevant (subject to any appropriate discussion with the
  release team as necessary)
   - closing #675971.

  14. #675971 should remain at an RC severity, be untagged wontfix,
 and maintained open until it is closed as discussed above.

  15. If the release team are content with the other changes
 in the new mumble package, the new version should be unblocked
 to propagate into wheezy.

  16. After that propagation, the separate celt packages should be
 removed from wheezy.  This should be requested by the celt
 maintainer filing a removal bug in the normal way, after mumble
 with embedded celt 0.7.1 has propagated to wheezy.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ian Jackson]

Ian Jackson writes (Bug#682010: [mumble] Communication failures due to CELT 
codec library removal):
   13. The mumble maintainers, with appropriate help from other
  interested parties, should prepare an upload of mumble for wheezy
  with

On rereading, prepare an upload of mumble for wheezy is wrong.  I
should say something like upload to sid, intended for wheezy, a
version of mumble with.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
 On Mon, 23 Jul 2012, Chris Knadle wrote:
  On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
   Of these 2. would seem to be the best option.
  
  I agree.
 
 [...]
 
 I believe in order to actually evaluate any of these solutions,
 someone is going to have to prepare binaries, and do an table showing
 the tested (not theoretical) compatibility of with multiple different
 clients (and servers?) to their solution's server and client.
 
 I propose that whoever wants to see a particular solution actually sit
 down and do the work for their particular solution, with sources,
 binaries, interdiffs, and compatibility table conveniently available in
 some public location.

Attached is a patch for fixing the build for the 348 version of Mumble in 
Wheezy, which includes embedding celt 0.7.1 into the mumble package and 
removing the dependency on the celt library.  There are two versions attached: 
a diff that can be applied directly via 'patch -p1  diff', and an mbox file 
that can be applied to the git repository via 'git am mbox file' against tag 
v1.2.3-348-g317f5a0-1.

Quick summary of changes:
  - Remove broken mumble-server-web package
  - Change maintainer from Debian VoIP team to Ron Lee
  - Remove Patrick Matthäi from Uploaders
  - Hardcode use of and add dependency on g++-4.6
  - Remove boost 1.46 dependency resolution
  - Remove libgl dependency resolution
  - Depend on ice34 and drop resolution via older versions
  - Build and embed celt 0.7.1 (and not celt 0.11.0)

One interesting difference when using the embedded version rather than the 
celt library is that Mumble reports using Celt 0.7.0 in the Server - 
Information screen, rather than Celt 0.0.0 that is reported when using the 
external celt library.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
diff --git a/debian/MurmurPHP.ini b/debian/MurmurPHP.ini
deleted file mode 100644
index 4937106..000
--- a/debian/MurmurPHP.ini
+++ /dev/null
@@ -1 +0,0 @@
-ice.slice=/usr/share/slice/Murmur.ice
diff --git a/debian/changelog b/debian/changelog
index e0fa95f..79bd682 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+mumble (1.2.3-348-g317f5a0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Remove broken mumble-server-web package
+  * Change maintainer from Debian VoIP team to Ron Lee
+  * Remove uploader Patrick Matthäi
+  * Hardcode use of and add dependency on g++-4.6
+  * Remove boost 1.46 dependency resolution
+  * Remove libgl dependency resolution
+  * Depend on ice34 and drop resolution via older versions
+  * Use embedded celt 0.7.1
+
+ -- Christopher Knadle chris.kna...@coredump.us  Wed, 01 Aug 2012 06:42:30 -0400
+
 mumble (1.2.3-348-g317f5a0-1) unstable; urgency=low
 
   * New upstream snapshot from 20.05.2012.
diff --git a/debian/control b/debian/control
index 435588e..066ad12 100644
--- a/debian/control
+++ b/debian/control
@@ -2,27 +2,25 @@ Source: mumble
 Section: sound
 Priority: optional
 Homepage: http://mumble.sourceforge.net/
-Maintainer: Debian VoIP Team pkg-voip-maintain...@lists.alioth.debian.org
-Uploaders: Patrick Matthäi pmatth...@debian.org,
- Thorvald Natvig thorv...@debian.org
-Build-Depends: debhelper (= 7.0.8),
+Maintainer: Ron Lee r...@debian.org
+Uploaders: Thorvald Natvig thorv...@debian.org
+Build-Depends: debhelper (= 7.0.8), g++-4.6,
  po-debconf,
- libboost1.46-dev | libboost-dev (= 1.38.0),
- libboost-python1.46-dev | libboost-python-dev (= 1.38.0),
+ libboost-dev (= 1.42),
+ libboost-python-dev (= 1.42),
  libqt4-dev (= 4.5.0),
  hardening-wrapper,
- libgl1-mesa-dev | libgl-dev,
+ libgl1-mesa-dev,
  libasound2-dev,
  libpulse-dev,
  libogg-dev,
  libspeex-dev,
  libspeexdsp-dev,
- libcelt-dev (= 0.7.0),
  libsndfile1-dev,
  libssl-dev,
- libzeroc-ice34-dev | libzeroc-ice33-dev | libzeroc-ice32-dev | libzeroc-ice-dev,
- ice34-translators | ice33-translators | ice32-translators | ice-translators,
- ice34-slice | ice33-slice | ice32-slice | ice-slice,
+ libzeroc-ice34-dev (= 3.4.2-8.1),
+ ice34-translators (= 3.4.2-8.1),
+ ice34-slice (= 3.4.2-8.1),
  libg15daemon-client-dev,
  libspeechd-dev,
  protobuf-compiler,
@@ -38,7 +36,6 @@ Package: mumble
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- libcelt0 (= 0.7.0) | libcelt0-0 (= 0.7.1~),
  libqt4-sql-sqlite,
  lsb-release
 Recommends: speech-dispatcher
@@ -87,21 +84,3 @@ Description: Low latency VoIP client (debugging symbols)
  .
  This package contains the debugging symbols for the 'mumble' and
  'mumble-server' packages.
-
-Package: mumble-server-web
-Architecture: all
-Depends: ${misc:Depends},
- ${perl:Depends},
- mumble-server (= ${binary:Version}),
- apache2,
- exim4 | mail-transport-agent,
- libnet-dbus-perl,
- libcgi-session-perl,
- libhtml-template-perl,
- php-zeroc-ice,
- ice34-translators | ice33-translators | ice32-translators | ice-translators,
- ice34-slice | ice33-slice | ice32-slice | 

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

[Chris Knadle]

On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
 On Mon, 23 Jul 2012, Chris Knadle wrote:
  On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
   Of these 2. would seem to be the best option.
  
  I agree.
 
 [...]
 
 I believe in order to actually evaluate any of these solutions,
 someone is going to have to prepare binaries, and do an table showing
 the tested (not theoretical) compatibility of with multiple different
 clients (and servers?) to their solution's server and client.
 
 I propose that whoever wants to see a particular solution actually sit
 down and do the work for their particular solution, with sources,
 binaries, interdiffs, and compatibility table conveniently available in
 some public location.

Attached is a patch for fixing the build on the 348 version of Mumble in 
Wheezy.  Two files, of which only one or the other is required: one is a 
standard diff which can be used to patch the 348 version as-is via patch -
p1  diff file while in the source package directory.  The other is an mbox 
file for importing via 'git am mbox file' against the latest tagged version 
of 348, v1.2.3-348-g317f5a0-1.

The patch consists of cherry-picked git commits from the 349 version, plus 
one commit after doing a 'dch -i' to add a changelog entry [automatically 
marked as a .1 NMU, which for the moment I haven't changed].  This version 
still requires libcelt.  I'm currently testing this -1.1 on both client and 
server -- all seems well so far.  [Tables of compatability to follow.]  I 
think the 348 version includes the Speex codec, but I haven't been able to 
trigger its use yet experimentally.

Quick summary of changes:
  - Remove broken mumble-server-web package
  - Change maintainer from Debian VoIP team to Ron Lee
  - Remove Patrick Matthäi from Uploaders
  - Hardcode use of and add dependency on g++-4.6
  - Remove boot 1.46 dependency resolution
  - Remove libgl dependency resolution
  - Depend on ice34 and drop resolution via older versions



I'm also still working on how to do the embedded celt version; by default 
embedding CELT will enable both embedded 0.7.1 and 0.11.0 so enabling only 
0.7.1 will require a quilt patch to modify the original source build 
directives slightly.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


mumble-348-fixes.mbox
Description: application/mbox
diff --git a/debian/MurmurPHP.ini b/debian/MurmurPHP.ini
deleted file mode 100644
index 4937106..000
--- a/debian/MurmurPHP.ini
+++ /dev/null
@@ -1 +0,0 @@
-ice.slice=/usr/share/slice/Murmur.ice
diff --git a/debian/changelog b/debian/changelog
index e0fa95f..d53fa2b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+mumble (1.2.3-348-g317f5a0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Remove broken mumble-server-web package
+  * Change maintainer from Debian VoIP team to Ron Lee
+  * Remove uploader Patrick Matthäi
+  * Hardcode use of and add dependency on g++-4.6
+  * Remove boot 1.46 dependency resolution
+  * Remove libgl dependency resolution
+  * Depend on ice34 and drop resolution via older versions
+
+ -- Christopher Knadle chris.kna...@coredump.us  Mon, 30 Jul 2012 02:00:32 -0400
+
 mumble (1.2.3-348-g317f5a0-1) unstable; urgency=low
 
   * New upstream snapshot from 20.05.2012.
diff --git a/debian/control b/debian/control
index 435588e..b360e0f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,16 +2,15 @@ Source: mumble
 Section: sound
 Priority: optional
 Homepage: http://mumble.sourceforge.net/
-Maintainer: Debian VoIP Team pkg-voip-maintain...@lists.alioth.debian.org
-Uploaders: Patrick Matthäi pmatth...@debian.org,
- Thorvald Natvig thorv...@debian.org
-Build-Depends: debhelper (= 7.0.8),
+Maintainer: Ron Lee r...@debian.org
+Uploaders: Thorvald Natvig thorv...@debian.org
+Build-Depends: debhelper (= 7.0.8), g++-4.6,
  po-debconf,
- libboost1.46-dev | libboost-dev (= 1.38.0),
- libboost-python1.46-dev | libboost-python-dev (= 1.38.0),
+ libboost-dev (= 1.42),
+ libboost-python-dev (= 1.42),
  libqt4-dev (= 4.5.0),
  hardening-wrapper,
- libgl1-mesa-dev | libgl-dev,
+ libgl1-mesa-dev,
  libasound2-dev,
  libpulse-dev,
  libogg-dev,
@@ -20,9 +19,9 @@ Build-Depends: debhelper (= 7.0.8),
  libcelt-dev (= 0.7.0),
  libsndfile1-dev,
  libssl-dev,
- libzeroc-ice34-dev | libzeroc-ice33-dev | libzeroc-ice32-dev | libzeroc-ice-dev,
- ice34-translators | ice33-translators | ice32-translators | ice-translators,
- ice34-slice | ice33-slice | ice32-slice | ice-slice,
+ libzeroc-ice34-dev (= 3.4.2-8.1),
+ ice34-translators (= 3.4.2-8.1),
+ ice34-slice (= 3.4.2-8.1),
  libg15daemon-client-dev,
  libspeechd-dev,
  protobuf-compiler,
@@ -87,21 +86,3 @@ Description: Low latency VoIP client (debugging symbols)
  .
  This package contains the debugging symbols for the 'mumble' and
  'mumble-server' packages.
-
-Package: mumble-server-web
-Architecture: all
-Depends: ${misc:Depends},
- ${perl:Depends},
- mumble-server (= 

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

[Nicos Gollan]

Hi,

On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote:
 The way you've described this, /if/ the trick with Speex does work, and the
 Debian version of Mumble ships without CELT, it would mean that if any
 Debian user shows up on a public server then all users would switch to
 using Speex. If that's the case, then the audio quality of Speex vs Celt
 and the latency each has matters to an extent.

If the trick with speex works and is actually deemed necessary, then we're 
talking about a package providing the absolute minimum of interoperability 
without any ambition to providing quality. And yes, for it to work, it would 
need to switch all clients within hearing range to using speex with all the 
penalties in quality and latency that brings.

However, as suggested earlier, statistics also show that users on Linux 
platforms make up not quite 2% of the overall userbase, and users affected by 
the hack would be well below that (my guess would put them under one per mil). 
With that in mind, it would be easy for users to just kick the offending 
handful of clients worldwide off their servers if the need arises, since it 
would be a very rare occurrence. That makes the impact on the overall userbase 
absolutely negligible.

Regards,
Nicos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Wednesday, July 25, 2012 03:40:52, Nicos Gollan wrote:
 Hi,
 
 On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote:
  The way you've described this, /if/ the trick with Speex does work, and
  the Debian version of Mumble ships without CELT, it would mean that if
  any Debian user shows up on a public server then all users would switch
  to using Speex. If that's the case, then the audio quality of Speex vs
  Celt and the latency each has matters to an extent.
 
 If the trick with speex works and is actually deemed necessary, then
 we're talking about a package providing the absolute minimum of
 interoperability without any ambition to providing quality. And yes, for
 it to work, it would need to switch all clients within hearing range to
 using speex with all the penalties in quality and latency that brings.

Yeah... I'm not liking the sound of that.  For instance one of the things that 
are common on public Mumble/Murmur servers are one or more music channels 
among the many other channels for teams of gamers.  Forcing all of that 
through a low-quality codec meant only for voice communication sounds very 
undesirable from the user perspective.

 However, as suggested earlier, statistics also show that users on Linux
 platforms make up not quite 2% of the overall userbase, and users affected
 by the hack would be well below that (my guess would put them under one
 per mil). With that in mind, it would be easy for users to just kick the
 offending handful of clients worldwide off their servers if the need
 arises, since it would be a very rare occurrence. That makes the impact on
 the overall userbase absolutely negligible.

[I'm sure you know the following, but I'm explaining this in more detail for 
those that may not be familiar with it.]

Normally users cannot kick nor ban another user off the server.  To kick an 
offending client off the server would require SuperUser priviliges in the 
Mumble/Murmur server, or for kick/ban priviliges to be delegated to specific 
users via Groups or ACL rules in the server.  After that, this would involve 
right-clicking on the suspected offending client and getting Information on 
the client version, *somehow* figuring out that that version of Mumble was 
causing the problem (i.e. the Debian version of Mumble is a problem from a 
web search), and then finding someone with kick/ban priviliges to get the 
offending client off.  Then presumably someone has to leave the server and 
return in order to get the server to renegotiate the codec used.

I wouldn't characterize the above as easy -- although it is easy in the 
sense that it doesn't require reconfiguring the host machine to do it.  It 
would be easier for users to text the offending client and ask that the user 
leave, but this would also involve understanding and explaining the situation.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Nicos Gollan]

On Saturday 21 July 2012 03:35:56 Ron wrote:
 Sorry to keep this going with one more message, but since it seems apropos
 to the question of building an accurate table of where we might expect
 compatibility, and the earlier question of what people use on Ubuntu and
 other derivatives:
 
 [cut IRC log about Mint 9 having a client version without baseline client]
 
 So it would appear that shipping with celt 0.7.1 support is actually
 not sufficient on its own for people to communicate with the existing
 deployed base, and this is the advice people are given in those cases,
 by the developer who disabled the speex support ...

Please cut the unsubtle trolling against what happens upstream in development 
versions for now, especially when the situation has been explained to you 
repeatedly and patiently by upstream developers.

If certain server or client versions do not support the baseline, then that 
was so far universally a problem of maintainers not understanding the baseline 
contract and insisting on exclusively using bitstream incompatible 
distribution packages of the CELT library (some other distributions that shall 
remain unnamed have also been repeat offenders), and catering to that is 
certainly not on anyone's list, since it would, indeed, be crazy.

And in another message, he wrote:
 Speex is our most certain baseline, because all clients support it,
 and no server support is required.

Support for speex was a hack around disabilities of CELT at low bandwidths, 
and it could easily be added because the decoder was already in the client, so 
it was a non-breaking change to have clients just send speex encoded audio and 
be universally understood. Still, there is no way for a client to make other 
clients use speex. I will, however, happily declare being wrong about that 
once the magic fix-all speex patch hits and actually works.

**Sidenote:** Discussion about the qualities of different codecs, what they 
were made for, or what people want to use Mumble for, is certainly out of 
scope for this issue. With the qualities of Opus, it would certainly make a 
worthwhile topic on the Mumble forum.

Regards,
Nicos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ian Jackson]

Ron writes (Re: Bug#682010: [mumble] Communication failures due to CELT codec 
library removal):
 My primary concern is with the fact we would be shipping very complicated
 code, that only about 3 people in the world really understand, and which
 has no committed ongoing maintainer from among them or anyone else.

I don't think this is really a huge issue.  As I understand it the
code in the celt codec has been reused in the implementation of opus -
obviously not quite identically, but that means that it's not really
right to say that no-one understands this code and that it's dead
upstream.  It's been incorporated as a key part of opus, renamed and
developed.  So celt 0.7.11 is really best seen as an old, pre-release,
version of opus.

 If there is a consensus among the members of the TC and the security
 team that the risk of doing that is justified by other factors, then
 I'll consider the peer decision making process to have worked as it
 should, and quite the opposite of being 'irritated', I'll be quite
 relieved that this decision and its possible consequences do not fall
 on my head alone.

Well I asked this question of the security team, and while they
weren't particularly positive about it they did not object to the
inclusion in wheezy.

 So ...  really the only decision I see to be made here, is will we
 ship with celt 0.7.1 enabled or not.  If -ctte and -security weighs
 up the risks and tells me they are happy doing that, then I'm happy
 to make that happen with no further delay.

I don't speak for the whole TC, but my personal view at the moment is
that this tradeoff is worthwhile.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Tue, Jul 24, 2012 at 01:17:10PM +0100, Ian Jackson wrote:
 Ron writes (Re: Bug#682010: [mumble] Communication failures due to CELT 
 codec library removal):
  My primary concern is with the fact we would be shipping very complicated
  code, that only about 3 people in the world really understand, and which
  has no committed ongoing maintainer from among them or anyone else.
 
 I don't think this is really a huge issue.  As I understand it the
 code in the celt codec has been reused in the implementation of opus -
 obviously not quite identically, but that means that it's not really
 right to say that no-one understands this code and that it's dead
 upstream.

I understand your line of thinking there, and for 99% of the code in the
world, I'd be in complete agreement.  I'm not someone who is afraid of
code, or of getting my hands dirty in it, but we're not talking about
simple programming errors here - if and where there are problems, they
are in the boundary conditions of some very deep math that often still
confuses the people who created it until they stop and think very hard.

There's a simplified description of some of that here:
http://people.xiph.org/~xiphmont/demo/celt/demo.html

(be sure to mouse-over the block diagram too)

If there is anybody reading this who thinks they understand all the
concepts there enough to analyse code implementing them, then please
do put your hand up, we may need your expert attention at some point
in the future. (and we have other codecs we'd love you to help out
with too :)

For those who don't, I probably should note that was described as the
lies for children simplification by the people who wrote it.  Which
wasn't meant to be rude to anyone else, it just really does skip over
an enormous amount of the actual complexity that is really there, to
try and give ordinary people some broad idea of how it works, and
things to go research if they want to learn more.


I agree that saying nobody understands it is also an oversimplification
on my part, but I'm not aware of there being anybody at present in the
intersection set of people who care about mumble using old celt and
people who do understand this.  If that wasn't an empty set, I'd also
be less concerned.  (and I did spend quite some time asking around to
try to find someone who might fill that void)

I have no reason to doubt that the upstream maintainers who said they
have no further interest in this codebase really do mean that.  I've
been involved with them long enough to see them move from one project
to the next before and it really will be our problem, and our problem
alone if we continue using this.


 It's been incorporated as a key part of opus, renamed and
 developed.  So celt 0.7.11 is really best seen as an old, pre-release,
 version of opus.

There is a sense in which you are 100% correct there.  But it is also
the same sense which gave us the aphorism:

 This is Ned Kelly's original axe.
 (only the handle has been replaced 5 times and the head twice)

There's a 'spiritual' connection between these codebases, but so much
has been rewritten and reinvented so many times now, that backporting
anything from the new code to the old won't be a case of understanding
the code.  It will likely require reverse engineering the math and
then completely re-analysing the problem in a very different domain,
just to see if it still applies, let alone to figure out a fix.

If that wasn't the case, the problems identified in later code would
have already had fixes backported to the code we have.  As it is, nobody
has yet figured out how those things really map together, to confirm
or deny the old code is affected -- all the people who cared enough to
try got lost at the very first step.

For a more empirical clarification of how much has changed, see the
diffstat below.


  If there is a consensus among the members of the TC and the security
  team that the risk of doing that is justified by other factors, then
  I'll consider the peer decision making process to have worked as it
  should, and quite the opposite of being 'irritated', I'll be quite
  relieved that this decision and its possible consequences do not fall
  on my head alone.
 
 Well I asked this question of the security team, and while they
 weren't particularly positive about it they did not object to the
 inclusion in wheezy.

Yes, I did see nion's earlier response to that:
http://lists.debian.org/debian-ctte/2012/07/msg00192.html


  So ...  really the only decision I see to be made here, is will we
  ship with celt 0.7.1 enabled or not.  If -ctte and -security weighs
  up the risks and tells me they are happy doing that, then I'm happy
  to make that happen with no further delay.
 
 I don't speak for the whole TC, but my personal view at the moment is
 that this tradeoff is worthwhile.

I think I've made my concerns are clear as I can, so in my mind then,
if Don and Steve agree with your assessment, then I'm happy to consider
that a sufficient

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

[Ian Jackson]

Ron writes (Bug#682010: [mumble] Communication failures due to CELT codec 
library removal):
 I understand your line of thinking there, and for 99% of the code in the
 world, I'd be in complete agreement.  I'm not someone who is afraid of
 code, or of getting my hands dirty in it, but we're not talking about
 simple programming errors here - if and where there are problems, they
 are in the boundary conditions of some very deep math that often still
 confuses the people who created it until they stop and think very hard.

In order to support this in wheezy we do not need to be able to fix
general bugs in the codec or analyse and understand its signal
processing behaviour.

We have only to be able to fix security problems, and it is normally
possible to find and fix such security problems without needing to
understand the purpose of the signal processing algorithms; typically
they would occur (as with decompressors) in the handling of invalid
packets.

I have some experience of this as in a past life one of my
responsibilities was security audit and response for a manufacturer of
HSMs, so I have some idea of what's involved.

Looking at the code I agree with Nico that it's not marvellous.  And
it's rather too voluminous to audit.  But I don't think it's
significantly worse than other codecs.  In particular looking at the
opus code in sid it seems very similar in style and quality.  The only
difficulty is that it's different enough to make backporting changes
nontrivial.

Looking at some sample diffs there seem to be a lot of variable and
type name changes and so on, as well as the algorithmic differences,
so a diffstat doesn't give an accurate picture.

 If there is anybody reading this who thinks they understand all the
 concepts there enough to analyse code implementing them, then please
 do put your hand up, we may need your expert attention at some point
 in the future. (and we have other codecs we'd love you to help out
 with too :)

I don't think this is relevant.  Doing security support for this does
not need a degree in signal processing.  (And my first degree
contained an awful lot of signal processing and I have a background
and advanced degree in computer security, so I should know.)

  It's been incorporated as a key part of opus, renamed and
  developed.  So celt 0.7.11 is really best seen as an old, pre-release,
  version of opus.
 
 There is a sense in which you are 100% correct there.  But it is also
 the same sense which gave us the aphorism:
 
  This is Ned Kelly's original axe.
  (only the handle has been replaced 5 times and the head twice)

Having eyeballed some diffs I don't think this is a fair
characterisation at all.

 There's a 'spiritual' connection between these codebases, but so much
 has been rewritten and reinvented so many times now, that backporting
 anything from the new code to the old won't be a case of understanding
 the code.  It will likely require reverse engineering the math and
 then completely re-analysing the problem in a very different domain,
 just to see if it still applies, let alone to figure out a fix.

There is no need to backport anything other than security fixes.  As I
say, sorting out security fixes does not involve anyone having to
understand FFTs.

And I disagree that the code is so different that the connection is
`spiritual' as you put it.  Backporting a hypothetical security fix
from opus to celt 0.7.1 might well not be trivial (although depending
what it touched it might well be) but would also very likely be by no
means impossible.

 I'll leave trying to understand and review the diff itself as an
 exercise for the truly dedicated reader :)

It didn't seem to need that much dedication.  Although I haven't read
the whole diff, just eyeballed pieces chosen essentially at random.

 And while that may not look like the most horrifyingly large diff that
 has ever been sent to -release as a minimal 'harmless' proposed fix,
 let's put it into perspective as a proportion of the total codebase:

Currently celt 0.7.1 is in wheezy.  Its removal is blocked by the fact
that stripping it out introduces the RC bug in mumble.

The proposed fix involves moving the source code for celt 0.7.1 from
one source package to another, not introducing it newly into wheezy.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Tue, Jul 24, 2012 at 06:25:04PM +0100, Ian Jackson wrote:
 Ron writes (Bug#682010: [mumble] Communication failures due to CELT codec 
 library removal):
  I understand your line of thinking there, and for 99% of the code in the
  world, I'd be in complete agreement.  I'm not someone who is afraid of
  code, or of getting my hands dirty in it, but we're not talking about
  simple programming errors here - if and where there are problems, they
  are in the boundary conditions of some very deep math that often still
  confuses the people who created it until they stop and think very hard.
 
 In order to support this in wheezy we do not need to be able to fix
 general bugs in the codec or analyse and understand its signal
 processing behaviour.

I wasn't trying to imply that, and agree.

 We have only to be able to fix security problems, and it is normally
 possible to find and fix such security problems without needing to
 understand the purpose of the signal processing algorithms; typically
 they would occur (as with decompressors) in the handling of invalid
 packets.

This however is only 'trivial' if someone hands us a trigger stream
on a platter - and I don't believe that anyone is in the habit of
recording raw mumble protocol streams that their client receives.

Since nobody else is using this, our odds of a friendly agent stumbling
upon the problem first are greatly reduced, and in the event of such
a problem it would still require a sufficiently deep understanding to
avoid introducing new problems with any fix.

None of this is impossible, but nobody has volunteered to take on the
role of stewarding this.

 Looking at some sample diffs there seem to be a lot of variable and
 type name changes and so on, as well as the algorithmic differences,
 so a diffstat doesn't give an accurate picture.

Nobody has really been just renaming variables for fun and profit, so
I suspect you'll find most or all of those cases are also tied to some
semantic difference in meaning and/or use as the codec evolved.

   It's been incorporated as a key part of opus, renamed and
   developed.  So celt 0.7.11 is really best seen as an old, pre-release,
   version of opus.
  
  There is a sense in which you are 100% correct there.  But it is also
  the same sense which gave us the aphorism:
  
   This is Ned Kelly's original axe.
   (only the handle has been replaced 5 times and the head twice)
 
 Having eyeballed some diffs I don't think this is a fair
 characterisation at all.

Aside from the basic MDCT and PVQ, almost everything has changed at least
once, some things several times.  Things have been tried and discarded,
and new things have been added.  Though to be fair, surely not all those
things will be reflected in this single diff between two versions.

They are near the outer ends of all these changes though.  And the encoder
is _still_ evolving (since only the decoder and bitstream are normalised,
improvements in encoding are ongoing).  Again by way of mitigation though,
we will hopefully be mostly only concerned with the decoder, since that's
the obvious open vector for a remote exploit.


 There is no need to backport anything other than security fixes.  As I
 say, sorting out security fixes does not involve anyone having to
 understand FFTs.

Actually the FFTs need to go away entirely, just nobody has got around
to actually optimising that code yet (but that's a total aside :)


  And while that may not look like the most horrifyingly large diff that
  has ever been sent to -release as a minimal 'harmless' proposed fix,
  let's put it into perspective as a proportion of the total codebase:
 
 Currently celt 0.7.1 is in wheezy.  Its removal is blocked by the fact
 that stripping it out introduces the RC bug in mumble.
 
 The proposed fix involves moving the source code for celt 0.7.1 from
 one source package to another, not introducing it newly into wheezy.

Yes, I wasn't implying this was the diff -release would need to review,
just that for people used to looking at half-million line diffs sent
requesting a freeze exception, it may not look very daunting on number
of lines changed alone.  This was solely directed to making it clear
that the maintained opus codebase was not just some minor incremental
change to celt 0.7.1.  It carried on the name for the MDCT coding mode,
but in most respects aside from a couple of fundamentals is actually
an entirely different codec altogether.


My current understanding is that the code given as celt 0.7.0 in the
current mumble source *is* in fact 0.7.1, though I need to diff that
against the upstream 0.7.1 to be absolutely certain still.  So the
diff for 'adding' this to the mumble package itself should be very
minimal.  Sorry if I wasn't totally clear about that bit here.

 Ron


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Tuesday, July 24, 2012 15:37:51, Ron wrote:
 On Tue, Jul 24, 2012 at 06:25:04PM +0100, Ian Jackson wrote:
[…]
 My current understanding is that the code given as celt 0.7.0 in the
 current mumble source *is* in fact 0.7.1, though I need to diff that
 against the upstream 0.7.1 to be absolutely certain still.

At least in terms of what's in the 349 -2 in Sid and the celt 0.7.1 library 
in Wheezy, it looks to me like the code is exactly the same.

$ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt
Only in celt-0.7.1/libcelt: Makefile.in

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Tuesday, July 24, 2012 04:59:29, Nicos Gollan wrote:
[…]
On Monday, July 23, 2012 15:25:17, Ron wrote:
  Speex is our most certain baseline, because all clients support it,
  and no server support is required.
 
 Support for speex was a hack around disabilities of CELT at low bandwidths,
 and it could easily be added because the decoder was already in the client,
 so it was a non-breaking change to have clients just send speex encoded
 audio and be universally understood. Still, there is no way for a client
 to make other clients use speex. I will, however, happily declare being
 wrong about that once the magic fix-all speex patch hits and actually
 works.
 
 **Sidenote:** Discussion about the qualities of different codecs, what they
 were made for, or what people want to use Mumble for, is certainly out of
 scope for this issue. With the qualities of Opus, it would certainly make a
 worthwhile topic on the Mumble forum.

The way you've described this, /if/ the trick with Speex does work, and the 
Debian version of Mumble ships without CELT, it would mean that if any Debian 
user shows up on a public server then all users would switch to using Speex.  
If that's the case, then the audio quality of Speex vs Celt and the latency 
each has matters to an extent.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Nicos Gollan]

Hi,

On Monday 23 July 2012 00:31:27 Chris Knadle wrote:
 This means that the Opus-only client ruins the audio connection for
 everybody else that's connected, at least in this case.

That happens because the maintainer patch 20-add-opus-threshold-option sets 
the threshold variable default to 1, which is a pretty nonsensical value in 
most situations. It only really makes sense to set it to 0 or 100, unless you 
want to fabricate some really weird behaviour in codec negotiation…

In that case, any client with Opus support should trigger the issue, no matter 
if it supports CELT.

Just for completeness' sake, this is _not_ an upstream issue, the value is 
initialised to 100 there.

I guess manually setting opusthreshold=100 in your murmur.ini would restore 
sane behaviour on the server side, but I'm not inclined to dig through the 
other maintainer patches to see what else is interfering at this point.

Regards,
Nicos


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ian Jackson]

Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal):
 On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
 1) Fix up 348 from Wheezy so it compiles and uses the CELT
codec library [very undesirable]
 2) Same as 1) but with embedded CELT (would need testing)
 3) drop mumble from Wheezy

Of these 2. would seem to be the best option.  

Mumble is pretty widely used in some communities and I certainly think
we should try to have software in wheezy which can (i) provide a
server for mumble clients (ii) talk to mumble servers (iii) is
generally compatible with the existing deployed base (both inside and
outside Debian).

Personally I don't think there is much to prefer between 1 and 2.  Is
all that's stopping us from fixing this is overcoming our resistance
to an embedded library copy ?  If so I think we should just go ahead.

The difference in security supportability of a single embedded library
copy versus a separately library package with a rdep isn't very
great.  The difference mostly consists of the discoverability of the
embedded copy - and after this conversation I think we can reasonably
hope that everyone will know that mumble needs attention for security
bugs in celt 0.7.1.

We should confirm this with the security team but I don't imagine
they'll have an objection.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ian Jackson]

Ron writes (Bug#682010: [mumble] Communication failures due to CELT codec 
library removal):
 That point is currently still true.  Every existing client has the ability
 to *decode* speex if speex packets arrive.
 
 The only thing removed from recent clients was the ability to encode them.
 This is what we need to restore.

I'm afraid I don't recall, and I don't seem to be able to find in the
email thread, the answers to two questions related to this:

These `recent' clients which can't encode speex are where ?  Have they
been released by upstream ?  Are they in Debian ?

And presumably there is some reason why upstream don't like speex.
What is that reason ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
 Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal):
  On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
  1) Fix up 348 from Wheezy so it compiles and uses the CELT
  
 codec library [very undesirable]
  
  2) Same as 1) but with embedded CELT (would need testing)
  3) drop mumble from Wheezy
 
 Of these 2. would seem to be the best option.

I agree.

Pros:
  - Solution should work for both Wheezy and Sid
(-2 in Sid currently has no celt support, and celt is the most widely
 used codec in mumble on the 'net)
  - Would use celt 0.7 as well as 0.11
  - Celt library can be removed, which a lot of effort has gone into
Cons:
  - Larger diff in mumble
  - Would greatly irritate mumble maintainer

 Mumble is pretty widely used in some communities and I certainly think
 we should try to have software in wheezy which can (i) provide a
 server for mumble clients (ii) talk to mumble servers (iii) is
 generally compatible with the existing deployed base (both inside and
 outside Debian).
 
 Personally I don't think there is much to prefer between 1 and 2.  Is
 all that's stopping us from fixing this is overcoming our resistance
 to an embedded library copy ?  If so I think we should just go ahead.

Pros:
  - Smaller diff in mumble
Cons:
  - Only uses celt 0.7
  - Proliferates library that upstream requested removal of
  - No DD found to maintain celt 0.7 library (yet)
  - Would somewhat irritate mumble maintainer

 The difference in security supportability of a single embedded library
 copy versus a separately library package with a rdep isn't very
 great.  The difference mostly consists of the discoverability of the
 embedded copy - and after this conversation I think we can reasonably
 hope that everyone will know that mumble needs attention for security
 bugs in celt 0.7.1.

Right.

 We should confirm this with the security team but I don't imagine
 they'll have an objection.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

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

[Ian Jackson]

Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal):
 On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
  Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due 
  to 
 CELT codec library removal):
   On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
   1) Fix up 348 from Wheezy so it compiles and uses the CELT
   
  codec library [very undesirable]
   
   2) Same as 1) but with embedded CELT (would need testing)
   3) drop mumble from Wheezy
  
  Of these 2. would seem to be the best option.
 
 I agree.
 
 Pros:
   - Solution should work for both Wheezy and Sid
 (-2 in Sid currently has no celt support, and celt is the most widely
  used codec in mumble on the 'net)
   - Would use celt 0.7 as well as 0.11

I'm not sure I follow this.  Are you saying that enabling the embedded
celt would necessarily involve enabling /two/ versions of celt ?  (And
you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
so I'm confused about that too.)

Surely we want to avoid having multiple different versions if at all
possible.  Is it essential to support anything other than 0.7.1 ?
I thought upstream had declared 0.7.1 to be a baseline so that would
be sufficient.

And if 0.7.1 is sufficient, can it be done using an embedded copy
right now with a build system change, or would we have to dump a
special copy of celt 0.7.1 into the mumble source package ?

 Cons:
   - Larger diff in mumble

Is it in fact a substantial diff ?  I thought it was essentially a
configure option.

   - Would greatly irritate mumble maintainer

Rather than consider someone's emotional state, I'd rather focus on
their views.  That is, if this is a bad idea according to the mumble
maintainers then I'd like to hear why they think so.

  Personally I don't think there is much to prefer between 1 and 2.  Is
  all that's stopping us from fixing this is overcoming our resistance
  to an embedded library copy ?  If so I think we should just go ahead.
 
 Pros:
   - Smaller diff in mumble
 Cons:
   - Only uses celt 0.7

See above.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
 Ron writes (Bug#682010: [mumble] Communication failures due to CELT codec 
 library removal):
  That point is currently still true.  Every existing client has the ability
  to *decode* speex if speex packets arrive.
  
  The only thing removed from recent clients was the ability to encode them.
  This is what we need to restore.
 
 I'm afraid I don't recall, and I don't seem to be able to find in the
 email thread, the answers to two questions related to this:

I don't think we got to these specific points, so I don't think you missed
previous discussion on them (or if you did, then I did too ;)

 These `recent' clients which can't encode speex are where ?  Have they
 been released by upstream ?  Are they in Debian ?

The last formal release of mumble was 1.2.3 in Feb 2011.

The commit to Remove Speex encoding code was done in mid May 2012.
I had thought the -349 snapshot from git uploaded to debian was the only
one that contained this change (that's the one still blocked in unstable),
but from the git history, the -348 release in testing may have this change
too.  348 was uploaded to debian on the 24th May 2012, a couple of days
after the changes which added Opus support and removed speex support
happened upstream.

The 1.2.3-2 that Ubuntu has been shipping definitely doesn't have this
change, so it should only be anything pulled from Debian in the last
month or two that might be affected here.


 And presumably there is some reason why upstream don't like speex.
 What is that reason ?

The reason the upstream people who've been pushing back at this have
been giving me is that they think it sucks for audio quality.

Which to be honest I don't really understand, and I haven't yet been
able to elicit a clear explanation of what they think qualitatively
falls down about it for this particular use.

From the purely technical side of things:

Speex is a speech coder, which means it's very efficient at coding
speech signals, it requires very little bandwidth to transmit them
with much better than toll quality telephone fidelity (I'm talking
good land-lines here, not mobile phone quality) - but it's not so
hot at things like full-band complex music.

Celt on the other hand, was designed for low-latency interactive
music.  So it requires much more bandwidth, but you could wire a
remote orchestra together with a good conductor, and have them all
play together.  [1]


So for simple conversational speech, speex should be more or less
indistinguishable from raw PCM audio for many people.  You can try
this yourself with speexenc/speexdec from the speex package on some
recorded speech to hear what I mean.  The only situation I imagine
where that would degrade notably would be if you have lots of loud
and complex background noise, to the degree where conversational
speech would be challenging in its own right.

Maybe that is true for the gamers, but when I asked I didn't get
any confirmation that this was what the problem they saw was - so
I'm guessing a bit here, based mostly on the knowledge of what the
codecs themselves are capable of.

I am actually likewise curious to understand this better if that's
not the reason.  It's not surprising celt can sound better, but it
is quite surprising if speex actually sounds Bad.  And for people
just talking, and who pay for their traffic by the MB, or who only
have a low bandwidth pipe, celt may not be the best choice for them
at all anyway.


In the discussion I had with Thorvald, he noted that when they first
switched to celt, they'd assumed that nobody using this would mind
spending more than 40kbs to send audio (since most of them were
playing online games using much more bandwidth than that) - but that
apparently wasn't completely true, and many people did still want the
lower bandwidth option of speex.  So I'm not quite sure what triggered
the recent motivation to remove encoding it completely either.


 Ron

[1] - and just to complete the spectrum here, Opus is a hybrid codec
  which implements a speech coder that is more efficient and better
  quality than speex, along with the later evolution of celt for
  full band music, so you'll get both better quality and lower
  bandwidth than either of the other options provide.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Don Armstrong]

On Mon, 23 Jul 2012, Chris Knadle wrote:
 On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
  Of these 2. would seem to be the best option.
 
 I agree.
 

[...]

I believe in order to actually evaluate any of these solutions,
someone is going to have to prepare binaries, and do an table showing
the tested (not theoretical) compatibility of with multiple different
clients (and servers?) to their solution's server and client.

I propose that whoever wants to see a particular solution actually sit
down and do the work for their particular solution, with sources,
binaries, interdiffs, and compatibility table conveniently available in
some public location.

FWICT, Ron and Thorvald feel that speex will be their favored solution
and will have a version of it available no sooner than a week from
now, so there's at least a week for other people to do the work. [And
if no one wants to do the work for a solution, then there's no point
in even considering it.]

Feel free to coordinate using this bug or privately, but I don't
believe that further theoretical discussions of client/server
compatibility are useful. [At least, I'm personally not going to vote
to override a maintainer without an actual tested solution that is
technically superior, and I suspect that other CTTE members share that
opinion.]


Don Armstrong

-- 
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behavior, I have not yet achieved a state of
nirvana.
 -- Manoj Srivastava in 87n04pzhmh@glaurung.internal.golden-gryphon.com

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Monday, July 23, 2012 13:09:05, Ian Jackson wrote:
 Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal):
  On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
   Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures
   due to
  
  CELT codec library removal):
On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
1) Fix up 348 from Wheezy so it compiles and uses the CELT

   codec library [very undesirable]

2) Same as 1) but with embedded CELT (would need testing)
3) drop mumble from Wheezy
   
   Of these 2. would seem to be the best option.
  
  I agree.
  
  Pros:
- Solution should work for both Wheezy and Sid

  (-2 in Sid currently has no celt support, and celt is the most widely
  
   used codec in mumble on the 'net)

- Would use celt 0.7 as well as 0.11
 
 I'm not sure I follow this.  Are you saying that enabling the embedded
 celt would necessarily involve enabling /two/ versions of celt ?

Yes AFAIK.

 (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
 so I'm confused about that too.)

The mumble source package seems to contain celt 0.11.0 and 0.7.0.  The celt 
library contains celt 0.7.1.  

 Surely we want to avoid having multiple different versions if at all
 possible.  Is it essential to support anything other than 0.7.1 ?

AFAIK, no.

 I thought upstream had declared 0.7.1 to be a baseline so that would
 be sufficient.

That was my understanding too, but upstream seem to be using 0.7.0 from what I 
can tell.  [As such I'm likewise asking the same questions you are.]

 And if 0.7.1 is sufficient, can it be done using an embedded copy
 right now with a build system change, or would we have to dump a
 special copy of celt 0.7.1 into the mumble source package ?

I'm working on the assumption that celt 0.7.0 in the source package can be 
embedded using a build system change.

  Cons:
- Larger diff in mumble
 
 Is it in fact a substantial diff ?  I thought it was essentially a
 configure option.

Source-wise it's likewise my assumption also, but I was also considering the 
binary diff, if you will.

- Would greatly irritate mumble maintainer
 
 Rather than consider someone's emotional state, I'd rather focus on
 their views.  That is, if this is a bad idea according to the mumble
 maintainers then I'd like to hear why they think so.

Likewise -- I'm just trying to take the maintainer's wishes into account.

   Personally I don't think there is much to prefer between 1 and 2.  Is
   all that's stopping us from fixing this is overcoming our resistance
   to an embedded library copy ?  If so I think we should just go ahead.
  
  Pros:
- Smaller diff in mumble
  
  Cons:
- Only uses celt 0.7
 
 See above.

Celt 0.7.1 in the celt library.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

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

[Chris Knadle]

On Monday, July 23, 2012 04:52:29, Nicos Gollan wrote:
 Hi,
 
 On Monday 23 July 2012 00:31:27 Chris Knadle wrote:
  This means that the Opus-only client ruins the audio connection for
  everybody else that's connected, at least in this case.
 
 That happens because the maintainer patch 20-add-opus-threshold-option
 sets the threshold variable default to 1, which is a pretty nonsensical
 value in most situations. It only really makes sense to set it to 0 or
 100, unless you want to fabricate some really weird behaviour in codec
 negotiation…

Yes I see that opusthreshold is commented out, and iOpusThreshold = 1.
I've verified that this patch doesn't exist in the 348 version in Wheezy -- 
nor does it contain patches in relation to Opus.

 In that case, any client with Opus support should trigger the issue, no
 matter if it supports CELT.
 
 Just for completeness' sake, this is _not_ an upstream issue, the value is
 initialised to 100 there.
 
 I guess manually setting opusthreshold=100 in your murmur.ini would
 restore sane behaviour on the server side, but I'm not inclined to dig
 through the other maintainer patches to see what else is interfering at
 this point.

When it comes to the -2 version in Sid I hope it will only be necessary to get 
the build fixes required to build 348 -1 in Wheezy.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Monday, July 23, 2012 13:16:55, Ron wrote:
 On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
[…]
 Maybe that is true for the gamers, but when I asked I didn't get
 any confirmation that this was what the problem they saw was - so
 I'm guessing a bit here, based mostly on the knowledge of what the
 codecs themselves are capable of.
 
 I am actually likewise curious to understand this better if that's
 not the reason.  It's not surprising celt can sound better, but it
 is quite surprising if speex actually sounds Bad.  And for people
 just talking, and who pay for their traffic by the MB, or who only
 have a low bandwidth pipe, celt may not be the best choice for them
 at all anyway.

I seem to recall that the early versions of Mumble that I used defaulted to 
using Speex.  I seem to remember it sounding sort of like a so-so cellphone 
connection, sort of like the person(s) on the other side sounded like they 
might be slightly underwater.  i.e. works but not great, whereas CELT sounds 
very clear [as does Opus].  I can't be positive about this though because I 
might be mixing this memory up with my memories of other VoIP packages I've 
used over the years, so I'm likewise curious to hear what Speex sounds like 
again.


  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
 On Mon, 23 Jul 2012, Chris Knadle wrote:
  On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
   Of these 2. would seem to be the best option.
  
  I agree.
 
 [...]
 
 I believe in order to actually evaluate any of these solutions,
 someone is going to have to prepare binaries, and do an table showing
 the tested (not theoretical) compatibility of with multiple different
 clients (and servers?) to their solution's server and client.
 
 I propose that whoever wants to see a particular solution actually sit
 down and do the work for their particular solution, with sources,
 binaries, interdiffs, and compatibility table conveniently available in
 some public location.

That sounds reasonable.  I might need occasional advice but otherwise I think 
I can handle this.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote:
 Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due to 
 CELT codec library removal):
  On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
   Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures due 
   to 
  CELT codec library removal):
On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
1) Fix up 348 from Wheezy so it compiles and uses the CELT

   codec library [very undesirable]

2) Same as 1) but with embedded CELT (would need testing)
3) drop mumble from Wheezy
   
   Of these 2. would seem to be the best option.
  
  I agree.
  
  Pros:
- Solution should work for both Wheezy and Sid
  (-2 in Sid currently has no celt support, and celt is the most widely
   used codec in mumble on the 'net)
- Would use celt 0.7 as well as 0.11
 
 I'm not sure I follow this.  Are you saying that enabling the embedded
 celt would necessarily involve enabling /two/ versions of celt ?  (And
 you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
 so I'm confused about that too.)

This is absolutely not _necessary_, and not at all what I had in mind
in the previous discussions of this option.

It is _possible_ for mumble to embed many versions of celt simultaneously,
and perhaps Nicos and Chris had discussed this privately, but this is not
what we should be doing here.  If we take this option at all, then we
should use precisely the same celt code we have been using before now,
the 0.7.1 release.

 Surely we want to avoid having multiple different versions if at all
 possible.

Absolutely.
Anything else only increases our exposure surface to unmaintained code.

 Is it essential to support anything other than 0.7.1 ?

No.  We have never shipped a version that supported anything else.

 I thought upstream had declared 0.7.1 to be a baseline so that would
 be sufficient.

Correct.  (well, ostensibly correct, that's what upstream declared, but
apparently there are live servers in existence which don't respect this
and want to force other arbitrary versions of celt too).

For decoding speex actually appears to be the only baseline that we
really can trust all clients will have and all servers will support.


 And if 0.7.1 is sufficient, can it be done using an embedded copy
 right now with a build system change, or would we have to dump a
 special copy of celt 0.7.1 into the mumble source package ?

I'll have to look at exactly what has been included in the recent
tarballs, the upstream git repo is a bit of a hodge-podge of git
sub-modules, embedding various versions of various external libs,
all of which we currently do not use at all.  There will be some
diff, but I haven't looked at how big in detail yet.

  Cons:
- Larger diff in mumble
 
 Is it in fact a substantial diff ?  I thought it was essentially a
 configure option.

That will depend on the above, but if it's substantial it should
be fairly much limited to a single subdirectory adding the celt code.

I'm not concerned about our ability to do this correctly should we
choose to, only about the advisability of continuing to use celt
at all.

- Would greatly irritate mumble maintainer
 
 Rather than consider someone's emotional state, I'd rather focus on
 their views.

Amen.

 That is, if this is a bad idea according to the mumble
 maintainers then I'd like to hear why they think so.

My primary concern is with the fact we would be shipping very complicated
code, that only about 3 people in the world really understand, and which
has no committed ongoing maintainer from among them or anyone else.

If there is a consensus among the members of the TC and the security
team that the risk of doing that is justified by other factors, then
I'll consider the peer decision making process to have worked as it
should, and quite the opposite of being 'irritated', I'll be quite
relieved that this decision and its possible consequences do not fall
on my head alone.

I was not comfortable unilaterally making the decision to continue
shipping celt with the knowledge I have of its situation, and I wasn't
going to be browbeaten by users who shared no part in the risk they
wanted to expose others to.  That's very different to the TC putting
its judgement on the line, and the security team committing to do the
work should it come to that.

If they all agree this is our best option, then I have no problem with
deferring to that opinion.  As I said previously, it won't take a formal
vote to convince me if consensus is that this is the best thing to do.


I think I'd still like to see us explore the speex option.  But the
release clock is ticking, and I'd be lying if I said I wasn't anxious
about squandering what time we have left by not having real users
really out testing all this and reporting the bugs they find.

The bottom line on the compatibility matrix is that the *only* way to
ensure

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

[Ron]

On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote:
 On Monday, July 23, 2012 13:16:55, Ron wrote:
  On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
 […]
  Maybe that is true for the gamers, but when I asked I didn't get
  any confirmation that this was what the problem they saw was - so
  I'm guessing a bit here, based mostly on the knowledge of what the
  codecs themselves are capable of.
  
  I am actually likewise curious to understand this better if that's
  not the reason.  It's not surprising celt can sound better, but it
  is quite surprising if speex actually sounds Bad.  And for people
  just talking, and who pay for their traffic by the MB, or who only
  have a low bandwidth pipe, celt may not be the best choice for them
  at all anyway.
 
 I seem to recall that the early versions of Mumble that I used defaulted to 
 using Speex.  I seem to remember it sounding sort of like a so-so cellphone 
 connection, sort of like the person(s) on the other side sounded like they 
 might be slightly underwater.  i.e. works but not great, whereas CELT 
 sounds 
 very clear [as does Opus].  I can't be positive about this though because I 
 might be mixing this memory up with my memories of other VoIP packages I've 
 used over the years, so I'm likewise curious to hear what Speex sounds like 
 again.

That's the classic artifact introduced by an echo canceller hunting for
phase lock, which is exactly what causes it in cell phone connections
too.  It's not an artifact of the codec itself.

And unless you really are completely misremembering, really early versions
of mumble used speex 1.1, which is an inferior codec to what we have today,
but is still not responsible for introducing that effect.

 Ron


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Michael Ziegler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23.07.2012 19:16, Ron wrote:
 Celt on the other hand, was designed for low-latency interactive 
 music.

Fwiw, I've seen numerous people asking in #mumble how to stream music
over Mumble in a way that it sounds reasonable, so it might not be
*just* about speech here.

As you noted earlier, gamers are somewhat special when it comes to
what they do with stuff. :)

Cheers,
Michael


- -- 
Öffentlicher Schlüssel: 48F81543 - Michael Ziegler (Svedrin)
Wo kämen wir denn da hin, wenn jeder nur fragte Wo kämen wir denn
da hin?, aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
gingen?(Autor unbekannt)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQDaw5AAoJEEn0ejpI+BVDumEH/jnHQES0mlhl6xYWCuvUrWVL
qGaqXkE6Ifa08XFornBaPjaw6ny6eT0/ZvRP0jtjOf0kIbCr+sQLhmiTJGj0WwHa
WOGmkvoHhs3zF90Cio+50hEujcH+pMU9dYVkGA+bZEwIbJ8t8uMtpgz9Yd275mk1
6wt84lGhgb3tiG8Fly8N+Q5QmAUoijuQ0LyXqp50+keGN+x6hqh45cluuydI+ryG
gWaixIzm7Hi7DFBEdlD1BZDY9N4fWmgOJpQ7oOxbqGsif+A8CsCwj0zKA81IEXPS
v3jTXQEALKqoeAxc3fAvO86AzfA3s+dIeOg8HKIsuTeCFwxHenYCpX46oTvDJ70=
=LYkU
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Monday, July 23, 2012 15:25:17, Ron wrote:
 On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote:
  Chris Knadle writes (Re: Bug#682010: [mumble] Communication failures due 
to CELT codec library removal):
   On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
Philipp Kern writes (Re: Bug#682010: [mumble] Communication failures
due to
[…]  
 - Would use celt 0.7 as well as 0.11
  
  I'm not sure I follow this.  Are you saying that enabling the embedded
  celt would necessarily involve enabling /two/ versions of celt ?  (And
  you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
  so I'm confused about that too.)
 
 This is absolutely not _necessary_, and not at all what I had in mind
 in the previous discussions of this option.
 
 It is _possible_ for mumble to embed many versions of celt simultaneously,
 and perhaps Nicos and Chris had discussed this privately, but this is not
 what we should be doing here.  If we take this option at all, then we
 should use precisely the same celt code we have been using before now,
 the 0.7.1 release.

I have no objection.
There has been no private discussion with any of the parties in the bug AFAIK.

The main reason I was considering the embedded version was because the celt 
library is removed in Sid.  The only possible benefit of using celt 0.11.0 is 
only if it somehow improves interoperability with other distros, that from 
what you mentioned used embedded celt -- but this is certainly /not/ a 
requirement.

  Surely we want to avoid having multiple different versions if at all
  possible.
 
 Absolutely.
 Anything else only increases our exposure surface to unmaintained code.

I think I agree with that.

[…]
  I thought upstream had declared 0.7.1 to be a baseline so that would
  be sufficient.
 
 Correct.  (well, ostensibly correct, that's what upstream declared, but
 apparently there are live servers in existence which don't respect this
 and want to force other arbitrary versions of celt too).
 
 For decoding speex actually appears to be the only baseline that we
 really can trust all clients will have and all servers will support.

It will be good if a solution with Speex will work out such that celt can go 
away.  On that I think we're all on the same page, but I have my doubts if it 
will work with existing servers.  Hopefully it does.

[…]
  That is, if this is a bad idea according to the mumble
  maintainers then I'd like to hear why they think so.
 
 My primary concern is with the fact we would be shipping very complicated
 code, that only about 3 people in the world really understand, and which
 has no committed ongoing maintainer from among them or anyone else.
 
 If there is a consensus among the members of the TC and the security
 team that the risk of doing that is justified by other factors, then
 I'll consider the peer decision making process to have worked as it
 should, and quite the opposite of being 'irritated', I'll be quite
 relieved that this decision and its possible consequences do not fall
 on my head alone.

 I was not comfortable unilaterally making the decision to continue
 shipping celt with the knowledge I have of its situation, and I wasn't
 going to be browbeaten by users who shared no part in the risk they
 wanted to expose others to.

The term browbeaten is objectionable, as from our point of view mumble 
became completely unusable to talk to the rest of the world, there wasn't 
sufficient information available to understand the issue, and ... so on.  
Please just try to stick to the technical issues so I may do the same, because 
those are things we're much more likely to agree on.

 That's very different to the TC putting
 its judgement on the line, and the security team committing to do the
 work should it come to that.
 
 If they all agree this is our best option, then I have no problem with
 deferring to that opinion.  As I said previously, it won't take a formal
 vote to convince me if consensus is that this is the best thing to do.

Cool.

 I think I'd still like to see us explore the speex option.  But the
 release clock is ticking, and I'd be lying if I said I wasn't anxious
 about squandering what time we have left by not having real users
 really out testing all this and reporting the bugs they find.
 
 The bottom line on the compatibility matrix is that the *only* way to
 ensure we really are compatible with all extant systems is to:
 
  - Ship with speex reenabled.
  - Ship with all seven or so versions of celt enabled.
  - Ship with opus enabled.

Seven versions of celt?  No, I'm not looking to enable THAT.

 I think we can all quickly agree that shipping with more than one
 version of celt is crazy-talk, and the only option we need to consider
 there is 0.7.1.

No objection.

 Speex is our most certain baseline, because all clients support it,
 and no server support is required.
 
 Opus support we need, because we likewise have no guarantee that
 Fedora or other

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

[Chris Knadle]

On Monday, July 23, 2012 15:43:11, Ron wrote:
 On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote:
  On Monday, July 23, 2012 13:16:55, Ron wrote:
   On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
  […]
  
   Maybe that is true for the gamers, but when I asked I didn't get
   any confirmation that this was what the problem they saw was - so
   I'm guessing a bit here, based mostly on the knowledge of what the
   codecs themselves are capable of.
   
   I am actually likewise curious to understand this better if that's
   not the reason.  It's not surprising celt can sound better, but it
   is quite surprising if speex actually sounds Bad.  And for people
   just talking, and who pay for their traffic by the MB, or who only
   have a low bandwidth pipe, celt may not be the best choice for them
   at all anyway.
  
  I seem to recall that the early versions of Mumble that I used defaulted
  to using Speex.  I seem to remember it sounding sort of like a so-so
  cellphone connection, sort of like the person(s) on the other side
  sounded like they might be slightly underwater.  i.e. works but not
  great, whereas CELT sounds very clear [as does Opus].  I can't be
  positive about this though because I might be mixing this memory up with
  my memories of other VoIP packages I've used over the years, so I'm
  likewise curious to hear what Speex sounds like again.
 
 That's the classic artifact introduced by an echo canceller hunting for
 phase lock, which is exactly what causes it in cell phone connections
 too.  It's not an artifact of the codec itself.
 
 And unless you really are completely misremembering, really early versions
 of mumble used speex 1.1, which is an inferior codec to what we have today,
 but is still not responsible for introducing that effect.

That all sounds reasonable.  Back then I think I was using many of the default 
settings and as such could have been using echo cancelation.  These days I've 
turned that off because it can sometimes cause echo rather than canceling it.  
Speex 1.1 sounds familiar.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
 The issue I have now is that The Plan that Ron and Thorvald have come up with 
 Will Not Work, depending what the _goal_ is.  If the goal is to be able to 
 interoperate with the existing *server* base [which was exactly why this came 
 to the TC in the first place], that won't be possible -- because the Speex 
 codec up to this point is not part of the selection process in the existing 
 servers.

I am 110% certain that Thorvald is not going to accept any solution that he
thinks can't be made to work for the vast majority of users.  That was the
crux of our conversation last week, and something which he has always been
unwavering about.  We have had many such conversations in the past, trying to
reconcile the, uh, idiosyncrasies, of gamers with best practice for Debian.

What you seem to have failed to note, or that Nicos has failed to tell you,
is that Speex is not included in the server side negotiation because it is
assumed axiomatically that *every* client has speex decoding ability.  So
it does not need to be negotiated.  You can send it at any time, and it will
work, without needing to be announced in advance, or the server needing to
do anything.

That point is currently still true.  Every existing client has the ability
to *decode* speex if speex packets arrive.

The only thing removed from recent clients was the ability to encode them.
This is what we need to restore.


 [Special thanks goes to Nicos for watching our backs here.]

Just to be clear here, because at some point Ian described Nicos as being
a mumble developer, and you have now declared him a sage ...

$ git log master | wc -l
30363

$ git log master | grep Nicos | wc -l
12

And all of those commits afaics relate to GUI overlay stuff for games,
nothing at all to do with the protocol negotiation we are talking about
here ...   So I think I'd still rather put my trust in the the opinion
of Thorvald about what can be made to work, than in someone who has said
repeatedly, Debian should just remove this, nobody cares because nobody
uses Debian anyhow.  Which is also clearly quite incorrect, or we wouldn't
be having this discussion at all.


The current facts are:

 - The server is currently 100% broken in testing, and will remain so
   for our users for as long as this is blocked here.

 - Thorvald has a plan that nobody here had thought of or considered
   previously.  We can't assess that until he gets back and implements
   it - but second guessing him here in the meantime is only going to
   waste his time with more mail to read before he gets to doing that.
   And his time is already very limited.

 - If that plan doesn't work, we have other plans we can weigh up
   falling back to.

 - If we have to fall back to those plans, and -ctte wants to assert
   that it would rather Debian ship an unmaintained codec, which nobody
   has spent more than a couple of hours quickly auditing for obvious
   problems, but which does have a real suspicion of deep problems ...

   Then provided we have a clear public record of the people wanting
   that putting *their* own heads on the block, and taking the full
   responsibility for any fall out or required remedy -- then I have
   clean hands, and someone to point at who is completely to blame for
   an action I advised against in the event it goes Horribly wrong.

   If the people wanting that can get the consensus of the TC (and
   I would much rather see this as an even informal consensus than
   than as a formal but narrowly won vote), then I'll set my own
   objection aside and we'll let history and fate be the judge.

Worrying about things that we aren't precluding as fallback options
before we've confirmed we do need to fall back to them doesn't seem
particularly productive to me though.  I think Steve pretty accurately
spotted there are _no_ ideal solutions here.  Hopefully mumble will
improve on these things too and this will be less of a problem for
Wheezy+1, but in the meantime I think we need to balance the amount
of inconvenience some users might experience (which seems unavoidable
whatever we do) against the amount of risk we are prepared to expose
them to (which seems quite avoidable).


The weekend here is nearly over, and I can't keep stealing time from
my Work customers to keep discussing this in circles next week (and
I'm sure many others here are in the same position).

The longer we draw this out, the less testing any of it is going to
have, the less time is going to be available to fix any shortcomings
that we haven't so far seen, and the poorer the result that we are
ultimately going to end up with.

 Ron


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Sunday, July 22, 2012 04:35:00, Ron wrote:
 On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
...
  [Special thanks goes to Nicos for watching our backs here.]
 
 Just to be clear here, because at some point Ian described Nicos as being
 a mumble developer, and you have now declared him a sage ...

You've misquoted me.  I said he's consistently given us sage technical 
advice.

 $ git log master | wc -l
 30363
 
 $ git log master | grep Nicos | wc -l
 12
 
 And all of those commits afaics relate to GUI overlay stuff for games,
 nothing at all to do with the protocol negotiation we are talking about
 here ... 

Nicos is the only one that has hinted to how the protocol negotiation works; 
being judgmental about his commits isn't going to help.  If you know more 
about how the selection algorithm works, that would be good, but I haven't yet 
heard you discuss the subject when it has come up.

 So I think I'd still rather put my trust in the the opinion
 of Thorvald about what can be made to work, than in someone who has said
 repeatedly, Debian should just remove this, nobody cares because nobody
 uses Debian anyhow.  Which is also clearly quite incorrect, or we wouldn't
 be having this discussion at all.

I'm quite willing to discuss Thorvald's plan when he comes back.

 The current facts are:
 
  - The server is currently 100% broken in testing, and will remain so
for our users for as long as this is blocked here.

The current -2 is also undistributable, so this doesn't really matter.  You'll 
see why.

I just found something out about the Opus-only client and the codec selection 
by the server.

This test involves four Mumble clients: 
  - 348 client from Wheezy (has Opus and CELT)
  - 1.2.2-6+squeeze1 client from Stable (lacks Opus)
  - 361 Windows developer snapshot (lacks Opus)
  - 349 client from Sid (has Opus only)

And the server version is again -2 from Sid.

Steps:
  1.  361 Windows client connects (Codec CELT)
  2.  I connected the 1.2.2-6_squeeze1 client; doesn't show which
  codec is use, but it's CELT
  3.  I connect my 348 client, connection shows Codec CELT
  4.  Talk a while -- everything works
  5.  I connect the 349 client from Sid, shows Codec OPUS
  6.  All audio connections for everybody DO NOT WORK from here on.
  348 client still shows Codec CELT.
  As long as the 349 client from Sid is connected, disconnecting
  and reconnecting any other client gets a message from the server
  Warning: Your client doesn't support the Opus codec, you won't
   be able to talk or hear anyone.  Please upgrade to a client with
   Opus support.
  7.  Disconnect the 349 client
  Audio connections still do not work.
  8.  In order to get the audio connection to work again between the
  clients that have CELT, one of them must disconnect and then
  reconnect in order to get the server to renegotiate which codec
  is used.

This is 100% repeatable.

This means that the Opus-only client ruins the audio connection for everybody 
else that's connected, at least in this case.

From seeing this I really think releasing a client that only has the Opus 
codec available is a directly detrimental plan.

It also implies that the current version of the server seems to choose using 
Opus over everything else, regardless of whether the other clients have it.

[…]
Then provided we have a clear public record of the people wanting
that putting *their* own heads on the block, and taking the full
responsibility for any fall out or required remedy -- then I have
clean hands, and someone to point at who is completely to blame for
an action I advised against in the event it goes Horribly wrong.

Quit the social engineering.

[…]
 The weekend here is nearly over, and I can't keep stealing time from
 my Work customers to keep discussing this in circles next week (and
 I'm sure many others here are in the same position).
 
 The longer we draw this out, the less testing any of it is going to
 have, the less time is going to be available to fix any shortcomings
 that we haven't so far seen, and the poorer the result that we are
 ultimately going to end up with.

Since you're low on time I'll cut to the chase.
As far as I'm concerned I now think we're down to three distinct options.

   1) Fix up 348 from Wheezy so it compiles and uses the CELT
  codec library [very undesirable]
   2) Same as 1) but with embedded CELT (would need testing)
   3) drop mumble from Wheezy

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

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

[Chris Knadle]

On Sunday, July 22, 2012 18:31:27, Chris Knadle wrote:
 On Sunday, July 22, 2012 04:35:00, Ron wrote:
  On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:

[…]
 Steps:
   1.  361 Windows client connects (Codec CELT)
   2.  I connected the 1.2.2-6_squeeze1 client; doesn't show which
   codec is use, but it's CELT
   3.  I connect my 348 client, connection shows Codec CELT
   4.  Talk a while -- everything works
   5.  I connect the 349 client from Sid, shows Codec OPUS
   6.  All audio connections for everybody DO NOT WORK from here on.
   348 client still shows Codec CELT.
   As long as the 349 client from Sid is connected, disconnecting
   and reconnecting any other client gets a message from the server
   Warning: Your client doesn't support the Opus codec, you won't
be able to talk or hear anyone.  Please upgrade to a client with
Opus support.

I got curious as to which platforms supported Opus.  It just so happens my 
girlfriend is a Mac user, and also has an iPad.  [Not my thing for obvious 
reasons, but... to each their own.]

Opus support

 Windows 1.2.3a   *no*
 Windows 361 dev snapshot   *no*
 iOS 1.1  *no*
 Mac OSX 1.2.3a   *no*
 Mac OSX 409 dev snapshot   *yes*
   (409 is brand new within the last couple of days)

Debian specifically
---
1.2.2-6+squeeze1  *no*
348 in Wheezy   *no*
349 in Sid  *yes, only*


So who /exactly/ can the Debian -2 version of Mumble talk to?

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

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

[Steve Langasek]

On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
 I've updated the summary with the suggested changes (at the end).

From the BTS, it doesn't look to me like this summary has taken?

 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.

If the original petitioner is satisfied with the solution and no longer
feels the need to involve the TC, I don't see any reason for the TC to
remain involved.  Certainly historically, we have considered our job done
once there's no longer a dispute that someone wants escalated to the
committee.  It's not at all our charter to fix all the bad bugs, only to
adjudicate when consensus can't be reached on its own.  If Chris and Ron
*are* working together now towards an agreed solution, I'd much prefer that
we let them get on with it.

It may be that it's Ian's intention to take up this issue in Chris's stead
because he himself thinks there's a problem that he wants to put before the
TC.  That's fine too, but I think in that case, Ian, you should state this
explicitly (and, logically, recuse yourself from voting on it under 6.1.2,
6.1.3, or 6.1.4 since you're then a party to the disagreement).

 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?

From what I've read here, I don't think there are *any* ideal solutions.  We
cannot retroactively cause all deployed clients on other OSes (or on other
versions of our own OS) be willing to negotiate a codec they don't already
negotiate; all clients on a given server must use the same codec to talk to
each other; and the set of codecs supported by all clients appears to be the
empty set, unless we want to all agree to use an obsolete experimental codec
which suffers from serious non-theoretical security issues.

So I'm really not sure why it's useful for the TC to be debating which of
the bad options we consider least bad.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

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

[Chris Knadle]

On Saturday, July 21, 2012 02:42:43, Steve Langasek wrote:
 On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
  I've updated the summary with the suggested changes (at the end).
 
 From the BTS, it doesn't look to me like this summary has taken?
 
  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.
 
 If the original petitioner is satisfied with the solution and no longer
 feels the need to involve the TC, I don't see any reason for the TC to
 remain involved.  Certainly historically, we have considered our job done
 once there's no longer a dispute that someone wants escalated to the
 committee.  It's not at all our charter to fix all the bad bugs, only to
 adjudicate when consensus can't be reached on its own.  If Chris and Ron
 *are* working together now towards an agreed solution, I'd much prefer that
 we let them get on with it.

The issue I have now is that The Plan that Ron and Thorvald have come up with 
Will Not Work, depending what the _goal_ is.  If the goal is to be able to 
interoperate with the existing *server* base [which was exactly why this came 
to the TC in the first place], that won't be possible -- because the Speex 
codec up to this point is not part of the selection process in the existing 
servers.  [1]  [Special thanks goes to Nicos for watching our backs here.]  In 
terms of existing servers, this would in effect be equal to the only use 
Opus option that currently exists in Sid right now, which is unable to 
interoperate _at all_ with every available version of the client on at least 
one platform.  I'm pretty sure it's not a viable option.

So while I was initially enamored with The Plan, I'm now back to being 
concerned after looking at the code Nicos pointed me to. [2]  I think it's 
clear now that we need to explicitly check with him on the proposed solutions, 
because he's consistently given sage technical advice in this matter.

So I wish we were done with the TC, but I don't think we are -- this is a 
really tough problem.  Right now I think if we want to be fully interoperable, 
we're going to require embedded celt -- I don't like this alternative either, 
but AFAIK it's what the other distros are doing, and the alternative of 
continuing to use the celt 0.7.1 library is likely to be deemed just too 
heinous and evil because we really need to stop proliferating it if at all 
possible.

Nicos -- let me know what you think.

 It may be that it's Ian's intention to take up this issue in Chris's stead
 because he himself thinks there's a problem that he wants to put before the
 TC.  That's fine too, but I think in that case, Ian, you should state this
 explicitly (and, logically, recuse yourself from voting on it under 6.1.2,
 6.1.3, or 6.1.4 since you're then a party to the disagreement).

I think Ian saw that I was too enthralled and that I jumped to conclusions, 
and put things on hold to give time for a sanity check.  I commend him for 
doing that as I think that's generally wise, especially where the author for 
the solution was going to be away for a week.  Additionally as Ian took the 
lead on this problem, I really don't want to commit to go off and take action 
without his input -- that definitely wouldn't seem right to me.

  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?
 
 From what I've read here, I don't think there are *any* ideal solutions. 
 We cannot retroactively cause all deployed clients on other OSes (or on
 other versions of our own OS) be willing to negotiate a codec they don't
 already negotiate; all clients on a given server must use the same codec
 to talk to each other; and the set of codecs supported by all clients
 appears to be the empty set, unless we want to all agree to use an
 obsolete experimental codec which suffers from serious non-theoretical
 security issues.
 
 So I'm really not sure why it's useful for the TC to be debating which of
 the bad options we consider least bad.

There isn't much choice, as lack of interoperability was why the matter was 
brought to the TC, and the action chosen directly affects interoperability.

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

[Don Armstrong]

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 (?)
* Possible solutions
** Include celt 0.7.1 as a convenience copy
   + Security Issues with embedded copies
   + Unspecified possible security issues
** Upload a celt 0.7.1 package
   + No maintainer desires to deal with this (apparently?)
   + Unspecified possible security issues
** Use speex instead
   + Server (and clients?) do not select speex as an option unless bandwidth is 
low
** Use only opus
   + Not yet (?) released upstream
   + May not communicate with non-opus clients
* 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.kna...@coredump.us, Ron r...@debian.org, 682...@bugs.debian.org, 
Nicos Gollan gt...@spearhead.de, Thorvald Natvig thorv...@natvig.com

The above is my current understanding of this bug. Please correct
anything that I've gotten wrong or misunderstood or missed.


Don Armstrong

-- 
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

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.kna...@coredump.us, Ron r...@debian.org, 682...@bugs.debian.org, 
 Nicos Gollan gt...@spearhead.de, Thorvald Natvig thorv...@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 

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

[Chris Knadle]

Diff for summary attached.

Thanks to Don Armstrong

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
diff --git a/682010_celt_and_mumble.org b/682010_celt_and_mumble.org
index ae6112a..849c105 100644
--- a/682010_celt_and_mumble.org
+++ b/682010_celt_and_mumble.org
@@ -1,18 +1,25 @@
 * Issue #682010
-** Mumble in unstable/testing currently cannot interact with other clients and servers
-   + Due to the removal of celt 0.7.1 (?)
+** Mumble in unstable/testing currently cannot interact with other clients and servers due to:
+   + removal of celt 0.7.1 library and disabling of use in mumble
+   + mumble upstream dropping speex
 * Possible solutions
 ** Include celt 0.7.1 as a convenience copy
-   + Security Issues with embedded copies
+   + Security Issues with embedded copies (?) (Thorvald)
+ Unspecified possible security issues
+   + Deprecated upstream in favor of opus
+   + Proliferates ancient celt library downstream
 ** Upload a celt 0.7.1 package
+ No maintainer desires to deal with this (apparently?)
+   + Request from celt authors to stop distributing ancient version
+ Unspecified possible security issues
 ** Use speex instead
-   + Server (and clients?) do not select speex as an option unless bandwidth is low
+   + Clients do not use speex unless bandwidth is = 32kb/s
+   + Clients cannot currently report speex version during codec selection process
+   + Requires code modification for selection process and re-enabling speex
+   + After mods should be backward compatible with existing clients
 ** Use only opus
-   + Not yet (?) released upstream
-   + May not communicate with non-opus clients
+   + Will not communicate with non-opus clients
+   + Will not communicate with non-opus servers
 * Open questions
 ** Can speex be made to be an option?
 ** Is a convenience copy acceptable, assuming mumble is the only thing with it?

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

[Don Armstrong]

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.kna...@coredump.us, Ron r...@debian.org, 682...@bugs.debian.org, 
675...@bugs.debian.org, Nicos Gollan gt...@spearhead.de, Thorvald Natvig 
thorv...@natvig.com


Don Armstrong

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

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


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Friday, July 20, 2012 17:48:07, Don Armstrong wrote:
 I've updated the summary with the suggested changes (at the end).

Please note that the table I had previously published to the original bug is 
informative for when server loopback works when there is only a *single* 
client connected.  It doesn't take into account situations when an opus-only 
client and an non-opus client are both connected, in which case [audio] 
communication always fails for one or more parties, depending on which codec 
the server decides all clients must use.  [It would be helpful to make a note 
of this above or below the table in the summary.  Thanks.]

 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.

Additionally I think it's best to show respect and use patience.  It's a 
difficult and complicated problem that we're all trying to help each other 
with.

 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?

I believe this is correct.  Thats 4 options, each of which have their own set 
of issues.


Re: summary:

Two lines are duplicated:

[…]
11  + Clients cannot currently report speex version during codec selection 
process
[…]
14 + Clients cannot currently report speex version during codec selection 
process



Additional items:
  348 package in Wheezy will not build on amd64; zero-ice + gcc 4.7
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54
  348 mumble-server will not start due to zero-ice ABI breakage



Otherwise it looks good to me.
Thanks a lot, Don.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
 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.

That part I understand.  It was the what still needs to be resolved if
all the parties agreed on a solution part that I was still in the dark
about mostly ...

 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.

Yes, that's correct.  Whatever Thorvald comes up with will require
another upload.

 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?

Yes, that's pretty much how I see what our choices are, unless Thorvald
thinks of something entirely different again when he looks into the
first option.  We only got to talk through this very briefly before he
had to leave, but he was fairly confident, and he's on the short list
of people whose ability and confidence I've found tend to be fairly
reliably well correlated, so we'll see ...


Which really only leaves me with the question of what do we do today.

Right now the server in testing is completely broken if we don't let
the unstable version which fixes that migrate.  If that stays blocked
until we have Thorvald's fix, we're looking at it being broken for
a week until he gets back, a few days to a week until he has a patch
he's happy with, 10 days before it's eligible to transition, and a
bigger patch for -release to review before they consider unblocking it.

So it will be broken for somewhere from a couple of weeks to a month,
depending on who works how fast and whether -release would be willing
to age it in faster.

If we let the current unstable version transition today, we mitigate
those two things, and it doesn't change anything about our ability
to fall back to the plan B set, if that turns out to be needed.


I'm not too fussed either way to be honest.  It's extra work and
inconvenience for people _other_ than me if it isn't allowed to
migrate now.  But whether it can is out of my hands at present,
since TC put a block on the RMs unblocking it, and I haven't asked
the RMs for their preference yet because of the TC stop work order.

I'm fine with this issue being left open with the TC until its
final resolution independently of that though.  I don't see these
things as being tightly order dependent.  Either way there is work
and uploads to be done before we have our final answers for Wheezy.


One very last thing then, before I hopefully stop bothering you
for a while (:

 ** Use speex instead
+ Clients cannot currently report speex version during codec selection 
 process

I don't understand where that issue came from?
Speex has been API and bitstream compatible since, like 2006, or maybe before.

Maybe I totally misunderstand what that's saying, but anything relying on
a speex version is almost surely Doing It Wrong.

It's probably not important, I'm just not sure who is actually confused there.


  Thanks Much!
  Ron


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Don Armstrong]

On Sat, 21 Jul 2012, Ron wrote:
 One very last thing then, before I hopefully stop bothering you for
 a while (:
 
  ** Use speex instead
 + Clients cannot currently report speex version during codec selection 
  process
 
 I don't understand where that issue came from?
 Speex has been API and bitstream compatible since, like 2006, or maybe before.
 
 Maybe I totally misunderstand what that's saying, but anything relying on
 a speex version is almost surely Doing It Wrong.

Chris asked for this to be added IIRC; I believe[1] that this should
really be currently report speex support rather than speex
version.
 

Don Armstrong

1: Hopefully I'll be corrected if I'm wrong; it's likely that I
introduced the incorrect wording too.
-- 
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Ron]

On Fri, Jul 20, 2012 at 06:12:43PM -0400, Chris Knadle wrote:
 On Friday, July 20, 2012 17:48:07, Don Armstrong wrote:
  I've updated the summary with the suggested changes (at the end).
 
 Please note that the table I had previously published to the original bug is 
 informative for when server loopback works when there is only a *single* 
 client connected.  It doesn't take into account situations when an opus-only 
 client and an non-opus client are both connected, in which case [audio] 
 communication always fails for one or more parties, depending on which codec 
 the server decides all clients must use.  [It would be helpful to make a note 
 of this above or below the table in the summary.  Thanks.]

Sorry to keep this going with one more message, but since it seems apropos
to the question of building an accurate table of where we might expect
compatibility, and the earlier question of what people use on Ubuntu and
other derivatives:


06:44  HTT-Bird I have Mint 9 LTS (based on Ubuntu 10.04 LTS) on this computer
  and Mumble 1.2.3 (from a PPA), but Ubuntu doesn't provide a 
CELT
  version newer than 0.7.1 and I am trying to connect to a 
Mumble
  server that requires 0.11.0
06:44  HTT-Bird what am I to do?
06:46 @pcgod rebuild the client with bundled-celt enabled...
06:48  HTT-Bird pcgod: *sigh* : (I have built things from source, but 
cluttering up
  what isn't supposed to be a devbox with -dev packages isn't 
so hot)


So it would appear that shipping with celt 0.7.1 support is actually
not sufficient on its own for people to communicate with the existing
deployed base, and this is the advice people are given in those cases,
by the developer who disabled the speex support ...

That was an exchange from today, which I only saw just now.


 Like this wasn't complicated enough already,
 Ron  :/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

On Friday, July 20, 2012 19:24:17, Don Armstrong wrote:
 On Sat, 21 Jul 2012, Ron wrote:
  One very last thing then, before I hopefully stop bothering you for
  
  a while (:
   ** Use speex instead
   
  + Clients cannot currently report speex version during codec
  selection process
  
  I don't understand where that issue came from?
  Speex has been API and bitstream compatible since, like 2006, or maybe
  before.
  
  Maybe I totally misunderstand what that's saying, but anything relying on
  a speex version is almost surely Doing It Wrong.
 
 Chris asked for this to be added IIRC; I believe[1] that this should
 really be currently report speex support rather than speex
 version.

Yes I think the above wording is better.  I was reading code where several 
versions of CELT are reported and versions compared -- and since there isn't 
any code for reporting speex availability, I made an assumption as to how that 
would theoretically be handled.

 Don Armstrong
 
 1: Hopefully I'll be corrected if I'm wrong; it's likely that I
 introduced the incorrect wording too.

With a list of complications this long, something will end up being worded 
wrong.  ;-)

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Chris Knadle]

Package: tech-ctte
Severity: normal


Greetings to the technical committee.

This refers to Bug #675971 (which is severity grave, and currently closed)
against the Mumble VoIP package, which is also affected by Bug #674650
concerning the removal of the CELT library.  This evening we also just
discovered the existence of Bug #674634 which concerns the CELT library
removal as well, and which may have more of the technical story.


Summary of the technical dispute


Point of view of bug reporters (text via collaboration of two reporters):

  Background:
  --

- Mumble upstream uses and requires a particular baseline audio codec
  (CELT 0.7.1, a fairly old version), the availability of which is a
  base assumption used by most Mumble servers.

- CELT's upstream has a planned transition to the standardized Opus
  codec, and Mumble plans to follow suit, but that transition won't
  complete until all clients and servers support Opus, and that will take
  a while.  (Also, current upstream support for Opus remains a work in
  progress, and they don't have a released version with non-buggy
  support for Opus yet; the current version in Debian has some
  cherry-picked patches from upstream's VCS, but that doesn't help
  non-Debian users.)

- CELT audio Codec library has been removed from Debian by the maintainer,
  which with Mumble today is causing audio to fail outright for many public
  servers as well as several prior versions of mumble-server from Debian.
  [This has also been a problem for several other audio packages and
   maintainers.]

- On newer Mumble server versions, the audio connection fails if another
  client connects that requires using CELT, because all connected clients
  require using a common Codec.

- The newest -2 upload contains this issue.  [Mentioned because the
  maintainer reported that the -2 upload fixes the bug.]

- There is no warning in the NEWS.Debian file to warn users of the
  package that only the Opus Codec is usable and how that impacts the
  usability of the package

- The bug is repeatedly being closed by the maintainer if it was fixed,
  without discussion.  [Josh Triplett has since tagged the bug wontfix,
  which is at least an improvement, but this RC-level bug remains closed
  as is being forced by the maintainer, which will presumably allow the -2
  package with this issue to migrate to Wheezy and release with Stable.]

  Desired:
  ---

- From the point of view of the bug reporters, what we want is a
  package that inter-operates with other Mumble clients and servers,
  if possible.  To do this today would require reintroducing the celt
  source package again, which is rumored to have potential security issues.
  [We have not seen any details on this yet.]

  Note: this evening we think we have found a security expert who is
  willing to audit the CELT 0.7.1 codec for issues and possibly provide
  patches, assuming this is reasonably feasible.

- Assuming an inter-operable package is not possible, as a backup what
  we want is for the bug to be handled correctly in some way, and that
  users of the package have an opportunity to be notified of what
  limitations the package has.

  Possible options:
  

- Leave mumble out of testing and wheezy, keep it in either unstable
  or experimental (as we would for any client-server software with an
  unstable protocol that we can't support for the lifetime of a stable
  release), reintroduce CELT library for use with Mumble with security
  warnings in the description and NEWS.Debian concerning potential issues.

- Let mumble 1.2.3-349-g315b5f5-2 migrate to testing and release with
  wheezy without the CELT library, with compatibility warnings in
  NEWS.Debian. Possibly reintroduce (or at least allow the use of) a CELT
  codec library for Mumble in Unstable or Experimental which could allow
  users to use the CELT codec library with Mumble, with a warning in
  NEWS.Debian for the celt package to warn of potential issues.

- Similar to the item above, but with the CELT library in an external
  repository.

- Some other alternative we haven't thought of.



Point of view of the maintainer (as understood by reporters thus far, as
  no reply was given in several days in query for this summary):

- Someone the maintainer trusts said the CELT library contains code that
  could potentially be a crash vulnerability, among other unfixed issues

- Nobody is committing to maintaining and taking responsibility for celt
  0.7.1, or has sufficient spare time and/or the requisite knowledge to
  fully investigate this further.

- It was decided to remove the CELT library as to not burden the security
  team, and it has been an effort to get the library removed

- The mumble client that we currently have will only inter-operate with
  clients that have Opus support

- Upstream is eventually planning on dropping CELT anyway

- This isn't a bug, so it should be closed, and there is no 

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

[Ian Jackson]

Chris Knadle writes (Bug#682010: [mumble] Communication failures due to CELT 
codec library removal):
 Package: tech-ctte
 Severity: normal
...
 This refers to Bug #675971 (which is severity grave, and currently closed)
 against the Mumble VoIP package, which is also affected by Bug #674650
 concerning the removal of the CELT library.  This evening we also just
 discovered the existence of Bug #674634 which concerns the CELT library
 removal as well, and which may have more of the technical story.

Thanks for this, including the clear summary.

 - From the point of view of the bug reporters, what we want is a
   package that inter-operates with other Mumble clients and servers,
   if possible.  To do this today would require reintroducing the celt
   source package again, which is rumored to have potential security issues.
   [We have not seen any details on this yet.]
 
   Note: this evening we think we have found a security expert who is
   willing to audit the CELT 0.7.1 codec for issues and possibly provide
   patches, assuming this is reasonably feasible.

This sounds like a good option to me.  I will write to the security
team and ask them for their opinion about CELT.

From what you say I think:

 - We should try to address the security problems, if any, in the celt
   0.7.1 codec.  An audit would be very good.

 - This is a serious problem for mumble at least and is arguably RC.

Do you have people who are willing to be the maintainer(s) and (if
necessary) sponsor(s) for the celt package ?

I assume it would be possible to reintroduce a celt package which was
very similar to the one recently removed, so as to avoid risking
unnecessary bugs.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org