Summary:	ASTERISK-27351: iLBC Codec Mismatch
Reporter:	Luke Escude (lukeescude)	Labels:	pjsip
Date Opened:	2017-10-16 11:29:42	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Codecs/codec_ilbc Formats/format_ilbc
Versions:	15.0.0 16.0.0	Frequency of Occurrence
Related Issues:
Environment:	x64 CentOS	Attachments:	( 0) one-way-20-20-ast20.pcap ( 1) one-way-matched-30-30-ast20.pcap ( 2) pjsip.conf.txt ( 3) two-way-30-30-ast20.pcap ( 4) two-way-mismatched-20-30-ast20.pcap
Description:	Asterisk, when set to use iLBC, has 2 issues: 1. The INVITE SDP from Asterisk always contains 20ms frame size, regardless if ilbc is set in asterisk as ilbc:30 or ilbc:20 2. Asterisk always sends 30ms frames regardless of what was negotiated/set in pjsip.conf Attached are 4 packet captures: [^one-way-matched-30-30-ast20.pcap] is a one-way audio example where Asterisk is configured to use ilbc:30, but offers 20 in the SDP, and the phone uses 20. [^two-way-mismatched-20-30-ast20.pcap] is a two-way audio example where Asterisk is configured to use ilbc:30, but offers 20 in the SDP, and the phone uses 30 (therefore, 2-way audio). [^two-way-30-30-ast20.pcap] is a two-way audio example where Asterisk is configured to use ilbc:30, but offers 20 in the SDP, and the phone uses 30, (therefore, 2-way audio) [^one-way-20-20-ast20.pcap] is a one-way audio example where Asterisk is configured to use ilbc:20, offers 20 in the SDP, and phone is configured to use 20 (but it's still one-way audio because Asterisk is actually sending 30). Let me know if you need me to do more testing, it's 100% repeatable.
Comments:	By: Asterisk Team (asteriskteam) 2017-10-16 11:29:43.419-0500 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: Luke Escude (lukeescude) 2017-10-16 11:30:22.334-0500 Added pcaps By: Rusty Newton (rnewton) 2017-10-16 15:56:35.404-0500 You've provided pretty much everything we need, one other thing would be the basic configurations used to reproduce so we can be sure that we configure things exactly. Often we are told that an issue is easy to reproduce, then we can't reproduce and after the fact we have to ask for configurations, so we try to get them ahead of time. By: Luke Escude (lukeescude) 2017-10-16 16:03:16.118-0500 Sure thing - Attached is pjsip.conf By: Joshua C. Colp (jcolp) 2017-10-22 17:37:07.208-0500 Did you also try this scenario under 15.1.0-rc1 to make sure it wasn't a manifestation of the other codec issue? By: Jared Hull (fortytwo) 2017-10-23 09:57:39.999-0500 Responding for my colleague, Luke. Yes, all these issues are still present in 15.1.0-rc1. By: Kevin Harwell (kharwell) 2017-10-27 14:33:56.508-0500 I verified point 1 happens. As far as point 2, in my testing I wasn't able to get one way audio to happen. [~lukeescude] is Asterisk doing translation in your scenarios? By: Kevin Harwell (kharwell) 2017-10-27 14:35:28.594-0500 A note to whomever looks more into/works this issue: If it does turn out that the framing for ilbc can be configured and modified then please update the following wiki page to reflect that: https://wiki.asterisk.org/wiki/display/AST/RTP+Packetization By: Luke Escude (lukeescude) 2017-10-27 14:46:18.847-0500 Kevin, I would imagine translation is required when going between 20 and 30 ms frames, but I don't remember. Actually it is possible that it SHOULD be translating, but it doesn't try to because the codec is the same (even if the frame size is different) so this might be a single issue with two symptoms. By: Kevin Harwell (kharwell) 2017-10-27 15:09:15.160-0500 Yes, unfortunately Asterisk does not take into account format parameters with regards to whether or not things should be translated. So if two codecs are the same, but with different format parameters translation will not occur. By: Luke Escude (lukeescude) 2019-02-09 08:11:48.521-0600 This issue still exists for the 16.x versions of Asterisk. Translation between Opus and iLBC also yields crazy results, I’ll provide more detail next week. By: Jared Hull (fortytwo) 2019-02-11 15:43:34.149-0600 Since Opus is fixed at 20ms frame sizes, when we use 30ms iLBC there is audio in both directions but it is very distorted. When we use 20ms frame sizes, Asterisk doesn't comply and calls from Opus have no audio. The RTP packetisation link that Kevin posted suggests that Asterisk's min and max iLBC frame sizes are 30ms. So it seems that it is not possible to transcode between iLBC and Opus until iLBC can have a frame size of 20ms. This issue report is the result of our bad configuration and broken dreams; I think we are going to stop using iLBC so this issue ma be closed as far as I am concerned. By: Alexander Traud (traud) 2020-12-01 09:03:40.037-0600 Mhm. Works here guys. Please, do not play around with the packetization because that is independent to the mode in iLBC. Could you please test ‘my’ [open-source Opus Codec module|https://github.com/traud/asterisk-opus]? It [contains a fix|https://github.com/traud/asterisk-opus/commit/2c091bae6b7c12628a01b641672d452755fcda38] for iLBC 30. I doubt that fix is included in the closed-source module from Digium -- although I mentioned what to do in ASTERISK-25353. If that open-source module works, does iLBC work if you transcode to G.711, too? bq. Asterisk does not take into account format parameters with regards to whether or not things should be translated. So if two codecs are the same, but with different format parameters translation will not occur. Well, that is not correct. A codec module can honor both the (incoming†) packetization and format parameters. Furthermore, if the formats are incompatible and the codec module cannot transcode, it could reject the format. However, I am not aware of a codec module with that requirement. † There is a specific issue, but not a general issue with outgoing packetization, see ASTERISK-25579.