Summary:	ASTERISK-28199: sdp: iLBC codec does not contain "mode=" attribute
Reporter:	Ariel Grin (arielgrin)	Labels:	pjsip
Date Opened:	2018-12-06 20:31:26.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_sip/CodecHandling Codecs/codec_ilbc
Versions:	13.23.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Centos 6 32bit Kernel 2.6.32-642.6.2.el6.i686	Attachments:	( 0) sip_debug_peer_106.txt
Description:	Hi all: I’m trying to use iLBC codec but I found that iLBC has a no audio issue. If both endpoints are using iLBC neither endpoint can hear the other, even though RTP packets are flowing correctly, as checked with rtp debug. Also if an echo test is performed on an endpoint with iLBC, neither the initial explanatory message nor the echo itself can be heard. If one endpoint is using iLBC and the other is using another codec, I tried with ulaw, g729 and g722, iLBC endpoint can’t hear the other non-iLBC endpoint, but non-iLBC endpoint can hear iLBC endpoint. This has been tested between internal extensions on a local LAN, no NAT involved. This issue only happens when one or both endpoints are using iLBC. There are no audio issues when using any other codec except iLBC.
Comments:	By: Asterisk Team (asteriskteam) 2018-12-06 20:31:27.955-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]. By: Joshua C. Colp (jcolp) 2018-12-07 04:41:33.484-0600 When transcoding is not being done Asterisk is acting as a packet forwarder, not touching the audio contents at all. The problem may be on the client itself. What one is in use? Have you tried others? By: Ariel Grin (arielgrin) 2018-12-07 07:41:58.335-0600 This happens with all endpoints, yealink, grandstream, siemens and softphone from grandstream. This happens when any of the endpoints use iLBC, so it includes both transcoding and non-transcoding scenarios. By: Joshua C. Colp (jcolp) 2018-12-07 07:45:33.902-0600 You'll need to provide configuration, console output, and the SIP trace (sip set debug on or pjsip set logger on depending on one in use). Generally though iLBC is infrequently used, so there is no time frame on when such a problem would get looked into. By: Ariel Grin (arielgrin) 2018-12-07 07:48:22.487-0600 I will provide the debug as soon as possible. When you say configuration, is there any specific configuration you would lile me to provide? Console output I guess refers to the call log, right? By: Joshua C. Colp (jcolp) 2018-12-07 07:59:56.645-0600 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Joshua C. Colp (jcolp) 2018-12-07 08:00:42.084-0600 The comment just added links to wiki pages to provide the information. And the configuration is what is needed to reproduce the issue - it ensures that when someone else works on this issue they have everything necessary to investigate and don't have to potentially guess. By: Joshua C. Colp (jcolp) 2018-12-07 12:24:13.438-0600 Please do not copy/paste a log file into a JIRA comment as it can break JIRA and result in the issue taking a long time to load. To that end I have deleted the comment. Please attach it as a file as documented on the wiki page. By: Ariel Grin (arielgrin) 2018-12-07 12:35:05.256-0600 Sorry for the mistake, I'm attaching the debug log as a text file. Please let me know if you need any additional info. By: Ariel Grin (arielgrin) 2018-12-07 12:35:43.007-0600 SIP debug log for extension 106 By: Ariel Grin (arielgrin) 2018-12-10 08:31:26.795-0600 I'm not sure if this is relevant, but what I also noticed, if I'm not confused, is that no matter if the mode is 30 or 20, ptime is always = 20 By: Sean Bright (seanbright) 2018-12-11 08:04:58.253-0600 [~arielgrin], could you try [the patch here|https://gerrit.asterisk.org/#/c/asterisk/+/10781/] and see if it helps? By: Ariel Grin (arielgrin) 2018-12-11 10:00:16.050-0600 Thanks Sean. I will sure try the patch, but it might take a couple of days because downtime is not allowed during the week. By: Joshua C. Colp (jcolp) 2018-12-19 06:02:07.792-0600 Were you able to try Sean's change yet? By: Ariel Grin (arielgrin) 2018-12-19 06:13:15.277-0600 Sorry, I was not able to try it on productive server yet. By: Alexander Traud (traud) 2020-12-01 08:45:48.427-0600 Are you still able to reproduce this with Asterisk 16 because Asterisk 13 receives [security fixes only|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions]? Anyway, it should have worked in Asterisk 13 because {{mode=30}} is the default. If that format parameter is absent, {{mode=30}} has to be assumed. Consequently, this is an issue in your SIP User Agents. Did you report to them? Nevertheless for Asterisk 13, the iLBC 20 support (which was added with Asterisk 14), can be [downloaded here…|https://github.com/traud/asterisk-ilbc] with that, {{mode=30}} is sent ‘always’. Does that help? If not, you can revert the fix/patch for ASTERISK-25309 and change {{mode=%u}} to {{mode=30}}.