[asterisk-dev] Transcoding: Codec 2, iLBC 20, SILK, GSM-EFR, AMR(-WB)

Sun Dec 6 20:42:42 CST 2015

On Tue, Nov 24, 2015 at 9:08 AM, Alexander Traud <pabstraud at compuserve.com>
wrote:

> Thanks to the codec/format changes which were introduced with Asterisk 13,
> adding new trancoding modules is possible within one working day. Thanks to
> format-attribute modules, the debugging of the SDP/fmtp-negotiation resides
> in one source file. Therefore, I was able to port five formats to
> Asterisk 13: <http://github.com/traud>.
>
>
> Question #1: Level of Integration?
>
> Now, I plan to submit those modules into Asterisk. However, which level of
> integration is desired for which format: pass-through only (like G.729),
> pass-through plus library detection (like Opus), everything (like Speex)?
>
>
The goal for any media format included in the canonical Asterisk
repositories should be to have the highest level of support possible,
subject to third party patent and licensing issues. Generally, that means:
 * Library detection and pass-through, which are always fine
 * Codecs are fine so long as there are no patent or licensing
encumberments.

> pass-through including fmtp negotiation (level 1)
>  |  pass-through plus library detection in ./configure (level 2)
>  |   |  transcoding module in codecs/codec_* (level 3)
>  |   |   |
> [x] [x] [x] Codec 2 <http://www.rowetel.com/codec2.html>
>

This looks to be fine.

> [x] [x] [x] iLBC 20; the other mode iLBC 30 is available already
>

This also should be fine.

> [ ] [ ] [ ] SILK; deprecated since September 2012 in favor of Opus
> [x] [x] [ ] GSM-EFR; GSM-FR is available already
>

Pass through should be fine. More analysis would have to be done for a
codec module.

> [x] [x] [ ] AMR and AMR-WB
>
>
Pass through should be fine. A codec module would not be acceptable, based
on potential licensing/patent issues.

> Your opinion? Please, set/change your checkmarks as desired! Of course, I
> am
> able to find a contra position for each codec. Of course, I would like to
> see complete support for all codecs (level 3). Anyway, some arguments why I
> implemented those codecs:
> * SILK/24 is the only default HD codec in the famous CSipSimple for
> Android.
>   All other HD codecs must be enabled in CSipSimple manually.
> * GSM-EFR is default in Stock-Android, optional in Voice-over-LTE (VoLTE)
>   Beside AMR and GSM-FR the only codec with compression (the rest is
> G.711).
> * AMR(-WB) are mandatory when linked to VoLTE (3GPP TS 26.103 chapter 7)
> * Codec 2 does not have a MIME media-type specification, yet.
>   However, Codec 2 is supported in FreeSWITCH and CSipSimple.
> * iLBC 20 was an apprentice piece thanks to the patch in ASTERISK-18094.
>
>
> Question #2: Format-attribute Keys as Header Files?
>
> In Asterisk 13, some formats do have a header file in include/asterisk/,
> like CELT and Opus (*_attr_keys). However internally, nobody consumes those
> headers anymore. Some format-attribute modules offer "format_attribute_set"
> but nobody uses that either. Is it OK, to create new header files? For
> which
> use-case should I implement "format_attribute_set"?
>
>
That's an interesting point.

If a header file is not consumed, it should be removed. External modules
that require a header module should provide it themselves, and the core
should not require a header module provided by a third party module (for
obvious reasons).

format_attribute_set was implemented as a way to set arbitrary attributes
in a format module. I wouldn't remove that API call, as third party modules
may be relying on its callback to interface between a third party codec
module and a third party attribute module (although I admit the probability
is probably low.)

>
> Question #3: Module Loading Priority
>
> H.26x modules load very late (AST_MODPRI_DEFAULT). The Opus Codec module
> loads very early (AST_MODPRI_CHANNEL_DEPEND). Which one is correct? Or are
> both and there is a reason why video modules load later than audio modules?
>
>
>
So long as the core 'understand' that the format may exist,
AST_MODPRI_DEFAULT is fine. I would imagine that AST_MODPRI_CHANNEL_DEPEND
would only be necessary if it needed to register itself with the codec core.

> Question #4: Orphan Format-attribute module CELT
>
> Currently, Asterisk 13 does not offer even pass-through of SILK or CELT.
> Still their header files and their format-attribute modules are present. Is
> there a reason for this?
> For example, the SILK module contains several bugs, like creating several
> fmtp lines instead of one, is able to parse only a single parameter, and
> does not return a default when used with an internal transcoding module.
>
>
>
The headers (and other parts of those media formats) were originally
implemented back in Asterisk 10. At the time, the core managed some
configuration mechanisms for those media formats. I'd have to look more
closely to determine if they are still needed. Keep in mind you can have
pass through support with the format modules - you don't need necessarily
need a format module to pass media from one channel through a bridge to
another, the core merely has to know that the format exists. That also
explains why the media format attribute modules exist - they provide
assistance during negotiation.

SILK and CELT have commercial but free modules offered by Digium - although
due to time constraints, versions of those modules have not been released
for Asterisk 13.

> Final Sentence
>
> Although it would be nice to see at least some of this work in Asterisk, I
> am mainly interested in a code-review. Is it possible to submit everything
> for code-review even if there is no chance to pass?
>

Code posted to Gerrit really does need to be licensed back to the project -
in fact, that's why we require a CLA to be assigned to log into Gerrit. It
makes it a lot simpler for everyone participating in the project to know
what rules they are playing by.

That being said, everything you've proposed sounds like it would be
admissible. Codec modules are the only thing to be careful with, and both
codec2 and ilbc are fine.

Thanks for the contributions - and please keep them coming!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151206/31e51293/attachment-0001.html>