| Summary: | ASTERISK-26143: res_rtp_asterisk: One way audio when transcoding | ||||
| Reporter: | Henning Holtschneider (hehol) | Labels: | |||
| Date Opened: | 2016-06-23 10:02:03 | Date Closed: | 2017-05-15 05:59:41 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Resources/res_rtp_asterisk | ||
| Versions: | 13.7.2 13.9.1 13.11.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 12.04 x86_64, Ubuntu 14.04 x86_64, Yocto 1.5 i686 | Attachments: | ( 0) asterisk-13.13.1-one-way-audio.patch ( 1) ASTERISK-26143-extensions_2.conf ( 2) ASTERISK-26143-extensions.conf ( 3) ASTERISK-26143-full-without-t-NOK ( 4) ASTERISK-26143-full-with-t-OK ( 5) ASTERISK-26143-sip_2.conf ( 6) ASTERISK-26143-sip.conf ( 7) call-g711-to-g722-ok.txt ( 8) call-g722-to-g711-unsupported-payload.txt | ||
| Description: | This is essentially the same issue as ASTERISK-25197, but that issue has been closed due to inactivity and I am not the original reporter.
I tried both Asterisk 13.7.2 and 13.9.1 on different machines with different Linux environments with the same result: When making a call with a higher-quality codec to a destination with a lower-quality codec, e.g. G.722 to ALAW, Asterisk tries to set up a native bridge, fails to decode the lower-quality RTP coming from the called party and the line is silent at the caller's end. Setting up the call with a lower-quality codec to a called party with a higher-quality codec works fine. I tried with codecs ALAW, G.722 and G.729 all with the same result. I made calls between chan_sip peers and between chan_sip peers and PJSIP endpoints all with the same result. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-06-23 10:02:04.019-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: Henning Holtschneider (hehol) 2016-06-23 10:13:03.699-0500 I attached the CLI output of * core set verbose 9 * core set debug 9 * sip set debug on * rtp set debug on of two calls * call-g711-to-g722-ok.txt is a call from extension 101 with ALAW to extension 102 with G.722 that works fine * call-g722-to-g711-unsupported-payload.txt contains the logs of a call in the other direction, which has no audio from ext. 101 to 102 By: Joshua C. Colp (jcolp) 2016-06-24 11:48:41.797-0500 Can you please also provide the configuration in use for this? By: Henning Holtschneider (hehol) 2016-06-27 02:22:53.015-0500 I uploaded my sip.conf and my extensions.conf dialplan. By: Florian Hanig (geforce28) 2016-09-17 16:46:29.157-0500 I have exactly the same Issue with Asterisk 13.11. Can anyone help me for a fix ? By: Rusty Newton (rnewton) 2016-09-22 14:59:29.309-0500 [~geforce28] this issue is still open and hasn't been resolved. There isn't a fix available yet. Watch this issue for any updates. By: Tom Parker (tparker) 2016-09-24 14:27:30.581-0500 I am the reporter of ASTERISK-25197 and am still seeing this issue on installs of asterisk 13. I was unfortunately not able to provide the data they asked for at the time. My PBXes are all in production and in use 24/7 and a downgrade to 11 fixed the problem for me and my customers. I just installed 13.11.2 on a system upgrade and had it fail. It still works perfectly in 11. By: Marco Paland (mpaland) 2016-10-25 09:54:01.794-0500 I'm having (and observing) the same issue. My customers are angry and their systems are running 24/7 in production (13.6.0). My first fix was disabling the native bridge module (noload => bridge_native_rtp.so), but this doesn't seem to help, but makes things slightly better anyway: There are still about 10% of calls with one way or no way audio. NAT problems are N/A because the asterisk boxes have direct outside IPs. My next try is to disable all g722 codecs and use only g711 - but my customers will hate me for that. By: Joshua C. Colp (jcolp) 2016-10-25 10:01:43.806-0500 Can you try the patch on ASTERISK-26423 to see if it helps? It changes and fixes some codec problems uncovered. By: Marco Paland (mpaland) 2016-10-25 16:45:57.527-0500 Joshua, thanx a lot for the patch. I will compile a 13.11.2 system with your patch and deploy it in one of the customers branch office. Then I test it for a week and provide you feedback here afterwards. So the whole process may take up to two weeks. By: Daniel Heckl (DanielYK) 2016-11-24 09:28:20.536-0600 There is a patch for ASTERISK-26423 in ASTERISK-26603 if your problem is not fixed yet. I have a similar problem (ASTERISK-26553) and wait for publish of the patch. Please try it. By: Etienne Allovon (etienne_pf) 2017-03-22 11:29:58.785-0500 I update the issue with log from 13.14.0 on some precisions following some tests. The bug is still present in 13.14.0. An this really is a annoying bug since it means that asterisk is no longer transcoding a call with two different codecs (!) Attached is - sip.conf and extensions.conf to reproduce the problem - and full log with problem and without problem (core set debug 5, core set verbose 5, sip set debug on, rtp set debug on) Given I authorize codecA and codecB in asterisk general section in sip.conf Given I force sipPeerA to codecA Given I force sipPeerB to codecB Given sipPeerA calls B *and* given sipPeerA announces boths codecA and codecB in SDP Then, the bug appears : sipPeerA doesn't hear sipPeerB {noformat} -<- codecA ->- ->- codecB ->- sipPeerA asterisk sipPeerB -<- *codecB* -<- -<- codecB -<- {noformat} The problem is that asterisk sends RTP Note that there are 2 ways of 'solving'/masking the problem : - add option {{t}} (or, I guess, any feature option like {{ThH...}}) in dial (see exten 121009 in {{ASTERISK-26143-extensions.conf}}) : in this case, - configure sipPeerA to *only* advertise codecA. In this case, asterisk doesn't think it can send RTP Additionnal notes : - between full log with {{t}} option in Dial an without {{t}} option in Dial one of the differences is that with {{t}} option it uses simple_bridge instead of native_bridge - when it doesn't work, RTP logs show that it sends it to sipPeerA in mode P2P {{res_rtp_asterisk.c: Sent RTP P2P packet to 10.32.5.151:11784 (type 09, len 000160)}} By: Etienne Allovon (etienne_pf) 2017-03-22 11:34:37.044-0500 ASTERISK-26143-extensions_2.conf : with which tests were made ASTERISK-26143-sip_2.conf : sip.conf with which tests were made ASTERISK-26143-full-without-t-NOK : 1002 (sip/x2ces1) calls 111009 (sip/e0ujaob5) ASTERISK-26143-full-with-t-OK : 1002 (sip/x2ces1) calls 111009 (sip/e0ujaob5) - with option t in Dial By: Vitezslav Novy (vnovy) 2017-05-12 04:45:55.183-0500 bridge_native_rtp is chosen for the call although one leg in on alaw and second one on g722. I have traced the problem to sip_get_codec function in chan_sip.c and attached patch works for me. Sent to gerrit too By: Friendly Automation (friendly-automation) 2017-05-15 05:59:42.933-0500 Change 5620 merged by Jenkins2: chan_sip: Change sip_get_codec() to return correct codec list [https://gerrit.asterisk.org/5620|https://gerrit.asterisk.org/5620] By: Friendly Automation (friendly-automation) 2017-05-15 07:14:05.770-0500 Change 5621 merged by Jenkins2: chan_sip: Change sip_get_codec() to return correct codec list [https://gerrit.asterisk.org/5621|https://gerrit.asterisk.org/5621] By: Friendly Automation (friendly-automation) 2017-05-15 09:29:38.247-0500 Change 5622 merged by Joshua Colp: chan_sip: Change sip_get_codec() to return correct codec list [https://gerrit.asterisk.org/5622|https://gerrit.asterisk.org/5622] | ||||