Summary:	ASTERISK-27250: chan_pjsip: asymmetric_rtp_codec=no does not seem to be working anymore with Asterisk 13.17.1
Reporter:	nappsoft (nappsoft)	Labels:
Date Opened:	2017-09-05 07:51:17	Date Closed:	2017-11-15 08:01:22.000-0600
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	13.17.0 13.17.1	Frequency of Occurrence
Related Issues:	is related to ASTERISK-27223 chan_pjsip: unable to agree on audio codec with AVM Fritz!Box trunk (async rtp issue) is related to ASTERISK-27239 PJSIP losing RTP connection (no more audio)
Environment:		Attachments:
Description:	Description: We had one-way audio on some systems after upgrading to Asterisk 13.17.1 from Asterisk 13.15 or Asterisk 13.16. The traces showed that the Snom700 device was sending G711u while Asterisk was sending G711a (both codecs were offered in the SDP of both sides). Asterisk didn't switch to G711u during the whole conversation. Expectation: we'd expect Asterisk to switch to G711u after receiving G711u packets from the other end. Conclusion: It seems like Asterisk 13.17.1 would not switch the codec anymore to make the rtp codec symmetric when rtp is running through Asterisk. (Maybe this could be related to change made in ASTERISK-27013? didn't have time to look into the code, but received a SIP trace by mail that is showing the described behavior that was reported to be reproducible)
Comments:	By: Asterisk Team (asteriskteam) 2017-09-05 07:51:18.874-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: Joshua C. Colp (jcolp) 2017-09-05 08:17:51.655-0500 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: Rusty Newton (rnewton) 2017-09-05 09:44:41.041-0500 Linking this to ASTERISK-27223 as it may be related or a duplicate. By: nappsoft (nappsoft) 2017-09-05 09:48:41.949-0500 Just had time to check: it's not a regression caused by ASTERISK-27013, but it happened somewhere between 13.16 and 13.17 just tested the same scenario with the same devices with: Asterisk 13.16: OK Asterisk 13.17: not ok Asterisk 13.17.1: not ok By: nappsoft (nappsoft) 2017-09-05 14:15:06.466-0500 I've identified the commit causing the regression: bc51d4324a69a0b8ee4a3be208b91bb2081124ff By: Joshua C. Colp (jcolp) 2017-10-20 11:40:41.030-0500 This issue should be resolved in the current release candidates. A fix was put in to resolve an issue where we would not switch our sending codec as expected. Please try and see. By: nappsoft (nappsoft) 2017-11-15 07:10:15.802-0600 The fix seems to have solved the issue, thanks.