<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 9:08 AM, Alexander Traud <span dir="ltr"><<a href="mailto:pabstraud@compuserve.com" target="_blank">pabstraud@compuserve.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks to the codec/format changes which were introduced with Asterisk 13,<br>
adding new trancoding modules is possible within one working day. Thanks to<br>
format-attribute modules, the debugging of the SDP/fmtp-negotiation resides<br>
in one source file. Therefore, I was able to port five formats to<br>
Asterisk 13: <<a href="http://github.com/traud" rel="noreferrer" target="_blank">http://github.com/traud</a>>.<br>
<br>
<br>
Question #1: Level of Integration?<br>
<br>
Now, I plan to submit those modules into Asterisk. However, which level of<br>
integration is desired for which format: pass-through only (like G.729),<br>
pass-through plus library detection (like Opus), everything (like Speex)?<br>
<br></blockquote><div><br></div><div>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:<br></div><div> * Library detection and pass-through, which are always fine<br></div><div> * Codecs are fine so long as there are no patent or licensing encumberments.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
pass-through including fmtp negotiation (level 1)<br>
 |  pass-through plus library detection in ./configure (level 2)<br>
 |   |  transcoding module in codecs/codec_* (level 3)<br>
 |   |   |<br>
[x] [x] [x] Codec 2 <<a href="http://www.rowetel.com/codec2.html" rel="noreferrer" target="_blank">http://www.rowetel.com/codec2.html</a>><br></blockquote><div><br></div><div>This looks to be fine.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[x] [x] [x] iLBC 20; the other mode iLBC 30 is available already<br></blockquote><div><br></div><div>This also should be fine.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[ ] [ ] [ ] SILK; deprecated since September 2012 in favor of Opus<br>
[x] [x] [ ] GSM-EFR; GSM-FR is available already<br></blockquote><div><br></div><div>Pass through should be fine. More analysis would have to be done for a codec module.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[x] [x] [ ] AMR and AMR-WB<br>
<br></blockquote><div><br></div><div>Pass through should be fine. A codec module would not be acceptable, based on potential licensing/patent issues.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Your opinion? Please, set/change your checkmarks as desired! Of course, I am<br>
able to find a contra position for each codec. Of course, I would like to<br>
see complete support for all codecs (level 3). Anyway, some arguments why I<br>
implemented those codecs:<br>
* SILK/24 is the only default HD codec in the famous CSipSimple for Android.<br>
  All other HD codecs must be enabled in CSipSimple manually.<br>
* GSM-EFR is default in Stock-Android, optional in Voice-over-LTE (VoLTE)<br>
  Beside AMR and GSM-FR the only codec with compression (the rest is G.711).<br>
* AMR(-WB) are mandatory when linked to VoLTE (3GPP TS 26.103 chapter 7)<br>
* Codec 2 does not have a MIME media-type specification, yet.<br>
  However, Codec 2 is supported in FreeSWITCH and CSipSimple.<br>
* iLBC 20 was an apprentice piece thanks to the patch in ASTERISK-18094.<br>
<br>
<br>
Question #2: Format-attribute Keys as Header Files?<br>
<br>
In Asterisk 13, some formats do have a header file in include/asterisk/,<br>
like CELT and Opus (*_attr_keys). However internally, nobody consumes those<br>
headers anymore. Some format-attribute modules offer "format_attribute_set"<br>
but nobody uses that either. Is it OK, to create new header files? For which<br>
use-case should I implement "format_attribute_set"?<br>
<br></blockquote><div><br></div><div>That's an interesting point.<br><br></div><div>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).<br><br></div><div>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.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Question #3: Module Loading Priority<br>
<br>
H.26x modules load very late (AST_MODPRI_DEFAULT). The Opus Codec module<br>
loads very early (AST_MODPRI_CHANNEL_DEPEND). Which one is correct? Or are<br>
both and there is a reason why video modules load later than audio modules?<br>
<br>
<br></blockquote><div><br></div><div>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.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Question #4: Orphan Format-attribute module CELT<br>
<br>
Currently, Asterisk 13 does not offer even pass-through of SILK or CELT.<br>
Still their header files and their format-attribute modules are present. Is<br>
there a reason for this?<br>
For example, the SILK module contains several bugs, like creating several<br>
fmtp lines instead of one, is able to parse only a single parameter, and<br>
does not return a default when used with an internal transcoding module.<br>
<br>
<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Final Sentence<br>
<br>
Although it would be nice to see at least some of this work in Asterisk, I<br>
am mainly interested in a code-review. Is it possible to submit everything<br>
for code-review even if there is no chance to pass?<br>
<span class=""></span></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Thanks for the contributions - and please keep them coming!<br><br></div><div>Matt<br></div></div><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</div></div>