Questions Regarding Asterisk-opus Package In Debian Stretch Repo And Opus In General

Home » Asterisk Users » Questions Regarding Asterisk-opus Package In Debian Stretch Repo And Opus In General
Asterisk Users 4 Comments

Hello,

After reading [1] (in french), I would be very happy if I could get answers to:

1. Does this 13.7+20161113-3 package version has any relation with asterisk’s version it complements ? Current asterisk version in repo is
13.14.0. Does this 13.7 complies with it ?

2. From package description, is this package enough or not to allow transcoding with G711 ?
For instance, in the following situation:
SIP Phone <---- Opus ----> Asterisk <---- G111 ---> ITSP

3. Can you share here any personal field experience with this codec, for home worker use case ?
Is there a better user experience with Opus than with G729 or G711 ?

4. Does it work on ARM boxes (Raspberry, …) ?

[1] https://packages.debian.org/stretch/asterisk-opus

Regards

4 thoughts on - Questions Regarding Asterisk-opus Package In Debian Stretch Repo And Opus In General

  • The opus codec was used as an external patch. It looked ugly and thus a separate package was preffered.

    Its version number is not directly related to Asterisk. It has originally been split from the Debian packaging of Asterisk, and starting from the same version number allowed easier upgrading. There is no version number for the upstream code (the patch).

    Technically Asterisk codecs translate to/from (typically) linear and Asterisk combines codecs to do whatever transcoding needed. So the codec does not transcode directly to G.711. But Asterisk can transcode between opus and G.711.

    Should work just the same.

  • No, it is not. This package is in Debian’s main archive, which tells you it is not based on any binary blob.

    Opus is widely implemented in software, including free software
    (Firefox, Chromium, Linphone, Jitsi and a host of others). See also https://en.wikipedia.org/wiki/Opus_(audio_format)#Software

    My understanding is that to Digium’s best legal advice, there are still patent issues with the Opus codec. Even though many others disagree (as evident from above) and I also happen to disagree. But I certainly am not the one who runs Digium. And the powers that be there probably decided that whatever patent issues there are, have merit and need to be mitigated.

  • Debian’s versioning scheme is all their own. And I would not expect it to work with anything but a Debian-packaged Asterisk.

    Stretch is currently the “testing” distribution. This means that new versions of packages could appear at any time; but if a newly-introduced package breaks any other packages, they will be removed from “testing”
    (and replaced as soon as possible with newer, compatible versions)
    rather than allow packages to exist in the repository that cannot be co-installed.

    If you really want to use a newer Asterisk version, the Debian source will contain a file called “rules”, which is really a Makefile “in disguise”. This should give you a good clue as to how to hand-build an equivalent based on more up-to-date Source Code (if the compile-time options have not changed too much, then you might even get away with using it directly, but consider this a bodge). All codecs can input and output raw, uncompressed PCM; so as long as you build all the relevant modules, your Asterisk will be able to transcode between any two codecs it supports.

    (Is “G111” a typo for “G711” ?)
    Opus is, to the best of my knowledge, fully Open Source. G729 was encumbered by patents in some jurisdictions, though it’s now patent-free.

    G.711 A-Law is what the PSTN uses natively, and that is unlikely to change anytime soon; though some VoIP providers are bringing Opus online already. If you have many phones connected to your Asterisk, then you may run into CPU limitations transcoding incoming and outgoing calls between G711 and Opus. But that depends on your Asterisk server. If you are recording calls, Asterisk will already have to convert both the incoming and outgoing legs to raw PCM anyway. In any case, if your provider supports Opus, you can offload the donkey work to them ….. The only thing that would prevent any software from working on ARM /
    Raspberry Pi would be if it contained any architecture-specific binary code without Source Code
    (which you could just about get away with, if you released it under LGPL
    plus exceptions or an Apache licence). And I suspect if any such code existed, it would be rewritten in fairly short order anyway.

    Also, it’s Debian; and they really, really don’t like binary blobs, only grudgingly banishing them to a special “non-free” section which is not even enabled by default. And that package was in the main repository, suggesting full Source Code availability. In any case, I see builds for armhf (R.Pi 1 and 2) and arm64 (R.Pi 3); so even if there is some sneaky binary-only component, you will be able to get it to work.