Summary:	ASTERISK-18094: iLBC (30ms packet) to G711 (20ms) ULAW transcoding sounds "robotic"
Reporter:	Kristopher Lalletti (kris2k)	Labels:
Date Opened:	2011-07-06 19:45:41	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_sip/CodecHandling
Versions:	1.8.4 13.18.4	Frequency of Occurrence	Constant
Related Issues:
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.	Attachments:	( 0) asterisk10.12.1-ilbc-20ms.patch
Description:	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).
Comments:	By: Kristopher Lalletti (kris2k) 2011-07-06 20:02:29.624-0500 Note: when the ILBC stream terminates to Asterisk (ie: voicemail, echo test), there is no voice degradation, everything sounds crisp. By: Kenneth Van Velthoven (kvveltho) 2012-04-02 05:17:55.503-0500 Hi, Is there allready a solution found for forcing ilbc to 20ms in order to solve the robotic voice? Thanks. By: chris nicholson (chrissypedia) 2012-06-14 16:28:56.261-0500 I am also encountering this issue, when transcoding iLBC from our SIP client using both 20 and 30ms settings to G711u. The voice is consistently good in one direction (iLBC toward G711) and horrible/robotic in the other direction (G711 toward iLBC). (Using a third party hardware transcoder is working fine, so I believe our iLBC client is working well.) Is there any progress on this issue? Suggestions welcome, configuration or source code. Thanks. By: Shaun Clark (shaunc869) 2012-06-29 11:23:22.406-0500 We have this same issue in 10.6-rc1. Out of 10 calls, 7 will be perfect and 3 will start choppy and stay that way. When switching to g729 it seems to be better. So I think there is a transcoding bug of some kind here. What can we collect to help with this? Thanks! By: Kenneth Van Velthoven (kvveltho) 2012-06-29 11:31:21.655-0500 Do the following in sip.conf: allow=g729:30 allow=alaw:30 allow=gsm:30 allow=g726:30 allow=g722:30 allow=ilbc:30 That fixed our robot problem.   By: Shaun Clark (shaunc869) 2012-06-29 11:54:56.014-0500 Did that also fix g711? Or do I need to go allow=ulaw:30? By: Jim Van Meggelen (jimvanm) 2012-06-29 15:35:02.932-0500 I have tried allow=ilbc:20 and allow=ilbc:30 (also changing the setting on the SIP endpoint to match), and it makes no difference. Robot sound from G711 endpoint; normal sound to G711 endpoint; normal sound to voicemail and other internal features. By: Kenneth Van Velthoven (kvveltho) 2012-06-29 15:57:37.520-0500 @Shaun:  indeedn,  add allow=ulaw:30 @Jim:  do you terminate on a SIP provider?   If yes you must contact them to set packetsize to 30. By: Leif Madsen (lmadsen) 2012-07-17 07:27:02.797-0500 Just to clarify, setting the entire network to 30ms packet chunks is a work around and not a solution. Asterisk should be able to convert between 20ms and 30ms on different channels. By: Birger "WIMPy" Harzenetter (wimpy) 2012-07-17 21:30:42.781-0500 Looks like I ran into the same issue, but with IAX2 and without ilbc. I blamed zoiper for not coping with 10ms frames, but just found out that it depends on what the other end of the call is. Both sip and IAX configured for alaw:10. sip>iax2:   ok lcr>iax2:   robotic lcr>sip:    ok dahdi>iax2: robotic dahdi>sip:  ok file>iax2:  ok By: Kristopher Lalletti (kris2k) 2013-01-15 07:33:55.713-0600 Out of curiosity, I just tried latest Polycom Firmwrae (4.0.3.7562) with ilbc 13.33kb being the only codec available, and still no luck on Asterisk 1.8.19.1 It seems like Asterisk really doesn't want to get involved in buffering different calls legs of different frame rates (which would probably mean having to carry a buffer of 60ms/120ms in memory to transcode 30ms frames into 20ms frames since I would assume that smallest frame size has to be a multiple of the larger one) By: Rob Gagnon (rgagnon) 2013-02-08 10:53:53.027-0600 We have seen this same problem under 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. By: Kristopher Lalletti (kris2k) 2013-02-10 08:45:26.074-0600 Yep, works nicely when I changed my Polycom ILBC from 13.3k ILBC (30ms) to 15.2k ILBC (20ms).  Without this change, I was suddenly just getting a no audio on my phone. Now the next step would need to buffer & convert 30ms streams into 20ms streams and vice-versa. By: JoshE (n8ideas) 2013-02-14 13:17:43.929-0600 Any chance we might see a resolution on this for Asterisk 11 as well?  Running into this same exact issue on 11. By: Rob Gagnon (rgagnon) 2013-02-14 23:26:41.286-0600 JoshE:  I haven't used Asterisk 11 myself, but I did just test that the patch I attached above for 10.12.1 does apply clean to 11.2.1, and Asterisk was able to be compiled without errors.  Note though that I have not run Asterisk 11 at all.  Someone else will have to test if this is a solution for 11 as well.  I just don't have the time right now to do quality assurance testing on two versions :-) As I have not worked with Asterisk 11, it just means I am not familiar with any of the major architectural differences between 10 and 11 just yet.  There could be another file that the patch above does not modify under version 11 that it might neeed to.  Since the patch applies without conflict, and the code compiles clean, it does mean you could try it out on a non-production server and leave some feedback. By: Caesar (caesar305) 2014-05-24 23:27:29.674-0500 Hello, any updates to this issue besides the patch? By: Matt Jordan (mjordan) 2014-06-03 09:57:47.699-0500 If there were updates to this issue besides the patch, they would be on this issue. By: Rob Gagnon (rgagnon) 2014-06-03 11:17:32.141-0500 Our company's need for this to work went away, so I have not had the time to work on it more.  The reason is that iLBC 20ms is just not that popular.  We only had one client wanting to use it, and they just changed all of their stuff to 30ms due to interoperability issues they were having with almost any carrier they connected with.  For asterisk, the buffer matching overhead would almost be a waste of time because all the other codecs are 30ms.  The effort needed to have buffering work right to convert 30ms to 20ms and vice-versa just seems to outweigh the benefits. The pjSIP library seems to support both frame sizes, so maybe newer asterisk that uses that would work for you? By: Caesar (caesar305) 2014-06-03 11:27:21.497-0500 I actually updated to Asterisk 11.9.0 and it is working correctly now. By: Rob Gagnon (rgagnon) 2014-06-03 11:30:27.152-0500 Glad to hear it.  Maybe this should be closed then, if no one objects? By: sstream (sstream) 2015-05-27 07:10:03.174-0500 This problem seems to happen again in Asterisk13. Absolutely no sound with chan_sip. With pjsip, G711->iLBC is OK, but iLBC->g711 gets noisy sound. Any thoughts? By: Aaron Meriwether (ameriwether) 2016-07-20 00:28:39.450-0500 @sstream, the latest Asterisk 13 version seems to have most of the iLBC<->G711 issues resolved now.  The one remaining issue I've seen is resolved by the patch attached to ASTERISK-26221. By: sstream (sstream) 2016-07-23 17:58:20.478-0500 Mr. Meriwether, I tested Asterisk 13.10 with asterisk-13-ilbc-sdp.patch (also [iLBC 20 patch|https://issues.asterisk.org/jira/browse/ASTERISK-26218]), but it still has a problem. In the following situation, "Zoiper(Android) ==IAX2(iLBC)=> Asterisk (Debian jessie) ==SIP(uLaw)=> SIP provider" the voice sounds robotic or noisy. The opposite direction (SIP provider=>Asterisk=>Zoiper, like someone call me) sounds OK. Please note that Asterisk 11 does NOT have this issue. For Asterisk 11, the issue seems to be fixed as discussed above. By: Aaron Meriwether (ameriwether) 2016-07-25 13:22:16.162-0500 If you set Zoiper to use SIP rather than IAX2 to connect to Asterisk (while leaving the media codecs otherwise the same), does the issue still occur?  If not, then it might simply be a matter of porting some of the chan_sip fixes over to chan_iax2 as well. By: sstream (sstream) 2016-09-23 17:01:42.025-0500 I tested, and the issue still occurred. It seems that there is another type of bug for iLBC in IAX2.