[asterisk-bugs] [JIRA] (ASTERISK-18094) iLBC (30ms packet) to G711 (20ms) ULAW transcoding sounds "robotic"

[Rob Gagnon (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-18094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202747#comment-202747 ] 

Rob Gagnon edited comment on ASTERISK-18094 at 2/8/13 11:01 AM:
----------------------------------------------------------------

We have seen this same problem unser Asterisk 10.12.1 for iLBC

Asterisk is only able at this time to use the 30ms / 13.33Kbps version of the iLBC codec.  Adding ":20" to the codec in your config file won't do anything since there is no code behind it to support it.

I'm working on a complete patch that will allow both 20ms and 30ms modes of iLBC in one codec file.  For now, I've uploaded a proof-of-concept patch that simply changes the iLBC codec to 20ms only (no 30ms mode).  See attachment "asterisk-10.12.1-ilbc-20ms.patch"

Feel free to try it out.  In our tests, we were able to hear clearly and did see the proper "mode=20" in the SIP SDP.  Our current testing still has no audio in one direction due to a faulty softphone sending 50-byte frames even though it negotiates mode=20 properly.   In case you were interested, mode 20 is supposed to be 38-byte frames, so with this patch, 50-byte iLBC frames are dropped and hence: no audio.

We've been working on this actively for only about a day, so any feedback as far as any other softphones working better would be helpful.
                
      was (Author: rgagnon):
    We have seen this same problem unser Asterisk 10.12.1 for iLBC

Asterisk is only able at this time to use the 30ms / 13.33Kbps version of the iLBC codec.  Adding ":20" to the codec in your config file won't do anything since there is no code behind it to support it.

I'm working on a complete patch that will allow both 20ms and 30ms modes of iLBC in one codec file.  For now, I've uploaded a proof-of-concept patch that simply changes the iLBC codec to 20ms only (no 30ms mode).

Feel free to try it out.  In our tests, we were able to hear clearly and did see the proper "mode=20" in the SIP SDP.  Our current testing still has no audio in one direction due to a faulty softphone sending 50-byte frames even though it negotiates mode=20 properly.   In case you were interested, mode 20 is supposed to be 38-byte frames, so with this patch, 50-byte iLBC frames are dropped and hence: no audio.

We've been working on this actively for only about a day, so any feedback as far as any other softphones working better would be helpful.
                  
> iLBC (30ms packet) to G711 (20ms) ULAW transcoding sounds "robotic"
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-18094
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18094
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: 1.8.4
>         Environment: 2.6.34.8-68.fc13.i686.PAE #1 SMP Thu Feb 17 14:54:10 UTC 2011 i686 i686 i386 GNU/Linux
> Running on VMware ESX 4.0 with asterisk compiled for timerfd and dedicated CPU shares from the hypervisor.
>            Reporter: Kristopher Lalletti
>            Severity: Minor
>         Attachments: asterisk10.12.1-ilbc-20ms.patch
>
>
> Here's the transcoding flow:
> (Polycom560 v3.3.1)==SIP/iLBC(30ms)===>(Asterisk 1.8.4.2)===SIP/G711(20ms)===>(Class-5 telco switch)==>MyLandLine
> This problem seems to be consistent since the fork-out of the iLBC source-code from the Asterisk SRC tree. The result is a "robotic" symptom, with consistently lost fragments of sound.
> When I change the flow to the following:
> (Polycom560 v3.3.1)==SIP/iLBC(30ms)===>(Asterisk 1.8.4.2)===>MeetMeBridge(provided by DAHDI/pseudo)
> (MyLandLine)===>(Class-5 telco switch)===>SIP/G711(20ms)===>(Asterisk 1.8.4.2)==>MeetMeBridge(provided by DAHDI/pseudo)
> End-to-end, the sound is fine in both directions (note: meetme.conf has audiobuffers=0 defined to ensure minimal buffering).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira