Summary:	ASTERISK-29320: res_pjsip_sdp_rtp: Codec preference order of remote is not correct on unhold
Reporter:	Ross Beer (rossbeer)	Labels:
Date Opened:	2021-03-01 09:27:42.000-0600	Date Closed:	2022-01-05 07:14:17.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_pjsip_sdp_rtp
Versions:	GIT 18.0.0 18.2.1	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-28756 Codec Negotiation: add incoming_call_offer_pref option
Environment:	CentOS 7	Attachments:	( 0) debug.txt ( 1) Flow.jpg
Description:	When having two endpoints configured with the allow set to 'alaw,gsm' and then calling from one endpoint to another the call is set up with 'alaw' and there is two-way audio. If a call is then put on hold and then re-connected there is either one way or no audio. This looks to be caused by the incorrect codec order in the 200 response from Asterisk: {noformat} Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute (a): ptime:20 Media Attribute (a): maxptime:150 Media Attribute (a): recvonly {noformat} If you set the endpoint to a single codec the issue is resolved.
Comments:	By: Asterisk Team (asteriskteam) 2021-03-01 09:27:43.977-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Joshua C. Colp (jcolp) 2021-03-01 09:30:22.504-0600 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Ross Beer (rossbeer) 2021-03-01 09:56:45.915-0600 Sip Flow By: Joshua C. Colp (jcolp) 2021-03-01 10:10:41.277-0600 Please also include the specific configuration, and the Asterisk debug for it. By: Ross Beer (rossbeer) 2021-03-01 10:58:50.135-0600 Config is in realtime so not that easy to provide. Basics are: UDP Transport No Encryption for RTP allow=alaw,gsm The same config works perfectly using Asterisk 16. I have sent the PCAP and debug log via email. By: Joshua C. Colp (jcolp) 2021-03-01 11:17:22.646-0600 I've attached a debug log of this with embedded SIP packet logging, configured using "allow=g722,gsm". By: Alexander Traud (traud) 2021-08-16 07:07:06.219-0500 Adding a bit of analysis: In the debug log, the offending line is:{code}remote: (ulaw|g726|gsm|alaw|g722|ilbc) local: (g722|gsm) joint: (gsm|g722){code}Asterisk does not use its local preference but the remote preference order, this is the idea behind the new default ‘remote_merge’ strategy. However, Asterisk ‘thinks’ the remote preference order is not the presented SDP m(edia)=audio: 0 8 9 97 3 2 … but 0 2 3 8 9 97 instead. In other words: The [RTP Payload Type|https://www.iana.org/assignments/rtp-parameters] itself is used. Because gsm is 3 and therefore lower than g722 which is 9, the order swaps in this case here. This is caused by the [source code|https://github.com/asterisk/asterisk/blame/18/res/res_pjsip_sdp_rtp.c#L458]:{code}ast_rtp_codecs_payload_formats(&codecs, remote, &fmts);{code}This returns a variable called {{remote}} of type {{ast_format_cap}}. However, that format cap(ability) is not a ‘list’ but a ‘bag’, a ‘set’ with an unknown order. In other words: The remote order of media formats got lost. Until this is fixed: Therefore, Asterisk 16 LTS is a working workaround because that source code did not exist before. Therefore, using just a single media format is a working workaround because then the lost order does not matter. By: Florian Floimair (f.floimair) 2021-08-18 02:41:54.326-0500 Thanks for the analysis Alexander Traud. In fact this means that all Asterisk 18 versions (starting with 18.0) are affected. The affected versions field should be updated accordingly. By: Alexander Traud (traud) 2021-08-18 03:18:02.818-0500 Yes and no. The Asterisk Team interprets the Jira field ‘affected version’ as ‘reported with version’. Consequently, the latest current version *when* the report has been created is expected there. This is terrible confusing for external parties, I know, because other bug trackers track the version which introduced the issue. So, yes, normally it would be my job to update that field to Asterisk 18.0. However, no, in the world of Asterisk it stays at the version reported. Beside that I do not have the rights to edit that field. Nevertheless, there is an extension to that unwritten rule: If a new LTS branch was released and the bug still applies, its version is added. This makes sure, the bug is not deleted when the originally reported LTS branch gets end-of-life. However, however, the causing issue ASTERISK-28756 could be linked. This would invite the contributor [~kHarwell]. I could patch it but I am totally unsure if the current code does some sort of filtering. If it does not, the easiest way might be to update the private {{get_codecs(.)}} and return an {{ast_format_cap}} structure directly, because within {{get_codecs(.)}} the order is iterated already. By: Joshua C. Colp (jcolp) 2021-08-18 04:00:12.212-0500 The affected has been updated with 18.0.0. I've also linked the mentioned issue to this. By: Florian Floimair (f.floimair) 2021-08-18 08:32:59.989-0500 FYI another workaround (at least for me) was to set outgoing_call_offer_pref = local (instead of remote_merge which is the default) for the pjsip endpoints. Also I could further narrow down that this only ever happens when the caller sets the callee on hold. The other way round it seems to be correct. By: Florian Floimair (f.floimair) 2021-11-03 10:51:11.018-0500 since this only applies to outgoing_call_offer_pref I think this issue should actually be linked to this issue ASTERISK-28777 By: Alexander Traud (traud) 2021-11-03 11:21:21.901-0500 Puh. Good point because two different authors. Until resolved, the Asterisk team could link both as ‘caused by’ because ASTERISK-28756 introduced the code to blame. At that time, it might have been correct (simply a bag). However, that should be double-checked. Only till ASTERISK-28777 which made it more complex (expecting a list). In other words: ASTERISK-28756 produces a bag and ASTERISK-28777 expects a list. Anyway, [~f.floimair], if you use Asterisk commercially, you might opt for a [Bug Bounty…|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties] By: Friendly Automation (friendly-automation) 2022-01-05 07:14:18.230-0600 Change 17730 merged by Friendly Automation: res_pjsip_sdp_rtp: Preserve order of RTP codecs [https://gerrit.asterisk.org/c/asterisk/+/17730|https://gerrit.asterisk.org/c/asterisk/+/17730] By: Friendly Automation (friendly-automation) 2022-01-05 07:14:55.948-0600 Change 17519 merged by Joshua Colp: res_pjsip_sdp_rtp: Preserve order of RTP codecs [https://gerrit.asterisk.org/c/asterisk/+/17519|https://gerrit.asterisk.org/c/asterisk/+/17519] By: Friendly Automation (friendly-automation) 2022-01-05 07:18:35.603-0600 Change 17731 merged by Joshua Colp: res_pjsip_sdp_rtp: Preserve order of RTP codecs [https://gerrit.asterisk.org/c/asterisk/+/17731|https://gerrit.asterisk.org/c/asterisk/+/17731]