| Summary: | ASTERISK-26745: Asymmetric codecs when asymmetric_rtp_codec=no | ||||
| Reporter: | Jesse Ross (jmross) | Labels: | patch pjsip | ||
| Date Opened: | 2017-01-23 12:57:09.000-0600 | Date Closed: | 2017-08-16 06:42:02 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Core/General | ||
| Versions: | 13.13.1 14.2.1 GIT | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 1818d2e.diff ( 1) c4f201c.diff ( 2) debug.txt ( 3) endpoint1.txt ( 4) endpoint2.txt ( 5) ht802.txt | |||
| Description: | Calling from a Grandstream HT802 (opus,ulaw) to a trunk (ulaw), causes one way audio (no audio heard on HT802)
Wireshark shows HT802 send opus and receives ulaw packets. I am able to play these received ulaw packets and hear audio. My assumption is that this ATA does not support asymmetric codecs. I tried this on various versions of 13 and 14 before and after the fix was applied for asymmetric codecs. I also pulled the 13 and 14 branches from the git repo and had the same issue. In my case, it was not solved by this: ASTERISK-26603 Attached are debug.txt (verbose=10, debug=10, rtp and pjsip debugging on) endpoint1.txt (HT802 endpoint calling from) endpoint2.txt (sip trunk endpoint) ht802.txt (snippet of syslog from GS ATA) I originally made this post: https://community.asterisk.org/t/problems-with-opus-grandstream-ht802-directmedia-native-rtp/69459/5 My dialplan is quite simple so I didn't include it here. Dialed extension pass to our ARI app for processing. We are currently using the Asterisk 13 method of creating a channel and bridging (no separate create then dial). If I disable native_rtp bridging (using "bridge technology suspend native_rtp") I do get audio in both directions. Asterisk creates a simple_bridge in this case. If I calling using this ATA to an extension set up to just play music on hold, I can hear audio. Asterisk first sends ulaw then correctly identifies that it received a opus packet and switches to match. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-01-23 12:57:10.453-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: Luke Escude (lukeescude) 2017-01-23 17:34:45.040-0600 I created a ticket about this (Opus/uLaw) and they solved it - it'll be in the next release. ASTERISK-26666 By: Jesse Ross (jmross) 2017-01-23 18:00:52.614-0600 Yes, I saw the issue you submitted. It was stated by an Asterisk developer that they "suggest using 13 from git or waiting until the next release as I believe this was already fixed by ASTERISK-26603" on your submission. I installed this version and confirmed I had this fix but the issue is still happening. By: Jesse Ross (jmross) 2017-05-02 15:57:43.284-0500 Has there been any update on this issue? I just installed 13.15.0 but I am experiencing the same thing. By: Joshua C. Colp (jcolp) 2017-05-02 16:21:40.616-0500 This issue is still open, any updates will be posted on the issue itself. By: Torrey Searle (tsearle) 2017-07-28 07:52:09.474-0500 I think I have a patch that will resolve your issue. By: Torrey Searle (tsearle) 2017-07-28 08:22:24.080-0500 Could you give this patch (1818d2e.diff) a try? By: Torrey Searle (tsearle) 2017-08-04 03:47:04.921-0500 The previous version of the patch had a deadlock issue, could you try this one instead? | ||||