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

[Tzafrir Cohen]

On Sun, Dec 06, 2015 at 08:42:42PM -0600, Matthew Jordan wrote:

> > 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 
> >
> 
> This looks to be fine.

I haven't been following codec2 closely, but anyway.

What exactly does "codec2" mean? Is there a well-defined bit-rate and
such? This page mentions codec2 at 2400bps and at 3200bps. I read it is
used at even lower rates. If I get a "codec2" stream, which rate (and/or
other parameters) are used?

-- 
   Tzafrir Cohen
icq#16849755  jabber:tzafrir.co...@xorcom.com
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

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

[Alexander Traud]

> If I get a "codec2" stream, which rate (and/or other parameters) are used?

Faced the same question, when I started with Codec 2. I am glad, somebody is
interested. I am going to add this to the Read Me in my GitHub repository:

Currently, FreeSWITCH and CSipSimple support only the first Codec 2 release,
which was 2400 only. Wrappers for Asterisk 1.8 and Asterisk 11 exist, which
do the same. Those wrapper are included (but unmaintained) in the Codec 2
sources. I used those wrappers as starting point and ported it over to
Asterisk 13. Consequently, still with mode 2400.

Because there is neither an IANA MIME media-type registration nor a IETF RFC
for the negotiation within the Session Description Protocol (SDP) yet,
because of this, I would have to come up with my own SDP negotiation to
support those other Codec 2 modes/rates. Any suggestions are warmly welcome.

I am curious to try mode 3200 and especially mode 1600, because the latter
uses a 40 msec packetization time as default. And how that compares with AMR
(Mode 0 = MR475 = 4750 bit/s) in sRTP.



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

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

[Matthew Jordan]

On Tue, Dec 8, 2015 at 4:17 AM, Alexander Traud 
wrote:

> >> Question #1: Level of Integration?
> >> [x] [x] [ ] GSM-EFR; GSM-FR is available already
> > More analysis would have to be done for a codec module.
>
> GSM-EFR uses the same library as AMR. Therefore, it is the same situation.
>
> >> Question #2: Format-attribute Keys as Header Files?
> > format_attribute_set was implemented as a way to set arbitrary attributes
> > in a format module. I wouldn't remove that API call,
>
> I am not about removing that API, I am more about: Do I have to and for
> whom
> should I implement that API? Currently, that API is not implemented in my
> modules. I am just asking before it gets rejected in code-review just
> because of that.
>
>
You do not need to implement that callback if you module does not use it.


> >> 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.
>
> Channels do create copies of formats. When a format-attribute module is not
> loaded, then copies of the format do not have an attribute attached. This
> is
> fixed later on in the channels, by searching each time. However, I wonder
> why some format-attribute modules are loaded (too) late and some not. Or
> should I just change all the existing module to AST_MODPRI_CHANNEL_DEPEND,
> create a review and wait what happens (abandoned, rejected, or committed)?
> I
> am still not sure what is easier for the team: Pre-ask on the mailing list
> or going through issue-report/code-review.
>
>
Given that explanation, I would probably lean towards having the format
attribute modules use a module priority of AST_MODPRI_CHANNEL_DEPEND. You
would avoid having a very small window of time in which a channel could be
created without using the format attribute module to aid in negotiation.

As far as mailing list versus code review:
(1) Mailing list is used to discuss anything related to the development of
the project.
(2) Code review is more formal - you've submitted a patch, subject to the
CLA, for inclusion into the project. As a formal peer review, acceptance of
the patch would immediately move towards inclusion in the project.

So I think you've got it right. Using the mailing list to discuss potential
approaches to a patch is perfectly legitimate, and can save a lot of time
and energy if a patch is written and rejected due to a fundamental design
issue. On the other hand, using a code review tool is quite obviously handy
for in depth discussion and analysis of a proposed patch.



> >> Question #4: Orphan Format-attribute module CELT
> > 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.
>
> Yes, format-attribute modules are required only for supporting the line
> 'fmtp' in SDP negotiation. However since Asterisk 13, both SILK and CELT
> are
> not available, even not as pass-through. Therefore currently, these
> format-attribute modules are orphan modules.
>
>
Whoops. That does look to be an overight from the format overhaul done in
13 - they should at least be supported as pass through. We should probably
make an issue for that :-)


> > 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.
>
> Thanks for the stars given on GitHub. It is most appreciated.
> You have not given a star for my SILK modules:
> . Perhaps it got overlooked.
> Because
> you mention time constraints, SILK was not dropped on purpose, I guess.
> Therefore, is the Asterisk Team interested in pass-through support for SILK
> as well? By the way, are all these new modules just for master, or is there
> any chance to submit them for branch 13, too?
>
>
New modules for 13 must have accompanying tests. For the purposes of new
codec modules, I would suspect we would want to test at a minimum:
 * Basic pass through negotiation
 * Format attribute negotiation, if appropriate

There's some good examples of these tests currently in the Asterisk Test
Suite. Most of these tests simply use SIPp to send/receive an offer from
Asterisk and receive/send a corresponding answer:
 * tests/channels/SIP/SDP_offer_answer
 * tests/channels/SIP/SDP_attribute_passthrough
 *

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

[Matthew Jordan]

On Tue, Nov 24, 2015 at 9:08 AM, Alexander Traud 
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: .
>
>
> 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 
>

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 

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

[Alexander Traud]

> If you need testing, I can support you.

Thanks for the offer! Just give them a try and report all issues via their
GitHub repository or privately, as you like. By the way just to avoid a
misunderstanding: All five modules are finished and passed several tests of
my own. They all support pass-through and transcoding already. The question
is, whether the whole source code goes into the core of Asterisk - or
whether parts stay an external project.



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

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

[André Valentin]

Hello Alexander,

great work!! If you ask, it would be  nice if transcoding support is there for 
GSM-EFR and both AMR Codes.
If you need testing, I can support you.

Kind regards,

André


Am 24.11.2015 um 16:08 schrieb Alexander Traud:
> 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: .
>
>
> 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)?
>
> 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 
> [x] [x] [x] iLBC 20; the other mode iLBC 30 is available already
> [ ] [ ] [ ] SILK; deprecated since September 2012 in favor of Opus
> [x] [x] [ ] GSM-EFR; GSM-FR is available already
> [x] [x] [ ] AMR and AMR-WB
>
> 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"?
>
>
> 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?
>
>
> 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.
>
>
> 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?
>
>
>


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev