Summary:	ASTERISK-28671: Outbound Channel to endpoint that negotiates iLBC mode = 20 produces Warning in CLI and one way audio
Reporter:	Tom Cotton (TomC59)	Labels:
Date Opened:	2019-12-27 12:21:21.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Codecs/codec_ilbc
Versions:	16.7.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Centos 7.6 on VM in datacenter	Attachments:	( 0) SIP-126235.txt
Description:	When I dial a channel with an endpoint that prefers iLBC mode 20 the SDP from asterisk offers mode 20. If the endpoint replies with ans SDP that iLBC mode 20 is accepted and sends RTP packets according to spec, then the CLI reports a warning stating "[2019-12-20 17:59:59] WARNING[2512]: codec_ilbc.c:125 ilbctolin_framein: Huh?  An ilbc frame that isn't a multiple of 50 bytes long from RTP (38)?". iLBC mode 20 packets are not in multiples of 50 rather they are 38 bytes long. So the correct packets are being sent and rejected in error by asterisk. This behavior is only present in outbound channels dialed to the the endpoint. If the called endpoint replies in their SDP that they want iLBC mode 30 everything works just fine.
Comments:	By: Asterisk Team (asteriskteam) 2019-12-27 12:21:22.157-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Sean Bright (seanbright) 2019-12-30 08:34:15.570-0600 [~TomC59], can you attach the SIP signalling (as a text file) for a call that experiences this problem? By: Tom Cotton (TomC59) 2019-12-30 10:27:08.373-0600 Sip conversation that causes warning messages/ By: Sean Bright (seanbright) 2019-12-30 10:31:28.905-0600 [~TomC59], and can you confirm that you have {{res_format_attr_ilbc}} loaded? By: Sean Bright (seanbright) 2019-12-30 11:35:20.775-0600 Confirmed with Asterisk 16 from Git with {{res_format_attr_ilbc}} loaded. By: Tom Cotton (TomC59) 2019-12-30 11:41:39.112-0600 Running as user 'asterisk' Running under group 'asterisk' Connected to Asterisk 16.7.0 currently running on li980-228 (pid = 6915) Core debug is still 3. li980-228*CLI> module load res_format_attr_ilbc Unable to load module res_format_attr_ilbc Command 'module load res_format_attr_ilbc' failed. [2019-12-30 13:07:57] WARNING[30585]: loader.c:1769 load_resource: Module 'res_format_attr_ilbc' already loaded and running. By: Sean Bright (seanbright) 2019-12-30 14:42:07.132-0600 [~traud], I don't suppose this is something you would be willing to take a look at? By: Sean Bright (seanbright) 2019-12-30 15:10:39.533-0600 [~TomC59], how are you generating these outbound calls? A {{.call}} file or one of the originate commands? By: Tom Cotton (TomC59) 2020-01-03 10:46:03.560-0600 There are two different ways that I have used. First, my company's ARI application will originate the call with a create channel and the /channel/create then /channel/dial. The second way I tested this was with the standard Dial plan routine that looks like this: {noformat} same => n,Dial(${ARG1},${RINGDURATION},${DIALINOPTIONS}) {noformat} where ARG1 is my extension. By: Alexander Traud (traud) 2020-03-24 09:41:20.916-0500 [~TomC59], I was the one who added iLBC 20 to the existing iLBC 30 support. In my GitHub, which has still the patches for Asterisk 13, you see [what was changed|https://github.com/traud/asterisk-ilbc] for Asterisk 16. I am aware of some scenarios in which the call legs do not bridge the SDP attributes. In such a case, attribute data like the iLBC mode get lost. And then you face that warning message. Let us investigate together whether that is the cause. Are you able to debug (or add {{ast_log}} messages) your Asterisk? In that case, please, go for the file {{main/codec_builtin.c}}. There, in {{ilbc_samples}}, in the line before the return statement, print the pointer address ({{%p}}) of the variable attr: {code} ast_log(LOG_NOTICE, "%d: %p", mode, attr); {code}Do you get a Null Pointer and iLBC 30? By the way, when the call is up, you can investigate its audio codec path via the command line interface (CLI) of Asterisk: Which conversation does your Asterisk do? By: Tom Cotton (TomC59) 2020-03-30 10:57:38.645-0500 Alexander Traud, I would be happy to help you out however I need help my self for this technical stuff. My technical consultant is Michel Vaillancourt. I need him to help me get the information you need. Can you add him to this ticket? By: Alexander Traud (traud) 2020-03-30 13:06:54.021-0500 I am a user like you, I just contribute to Asterisk, occasionally. Therefore, I do not have any additional access rights here in Jira. If you know his username, you can mention him (see that question mark button at the bottom to get markup help). Otherwise, he has to add himself. By: Joshua C. Colp (jcolp) 2020-03-30 13:09:57.019-0500 Bug marshals and admins have no ability to "add" a user to an issue either. Mentioning them is the extent of what can be done. By: Alexander Traud (traud) 2020-12-01 09:09:30.785-0600 Tom, do you know the user name of Michel? Then, you can mention him via \[~username\]. I do not find him. I am about to leave the Asterisk platform. So, if you like to get this sorted, I need a bit more details. If you cannot provide those, I recommend to ‘watch’ ASTERISK-29183.