Summary: | ASTERISK-27352: Asterisk ignoring top codec in 200 OK | ||
Reporter: | Luke Escude (lukeescude) | Labels: | |
Date Opened: | 2017-10-16 11:36:21 | Date Closed: | 2017-10-20 10:03:16 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | |
Versions: | 15.0.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | x64 CentOS | Attachments: | ( 0) debug_output.txt ( 1) one-way.pcap ( 2) pjsip.conf.txt |
Description: | Endpoint codecs configured in Asterisk:
1. ulaw 2. iLBC:30 3. g729 Codec order on the phone itself: 1. iLBC:30 2. g729 3. uLaw Inbound call from Asterisk -> Endpoint: Asterisk sends INVITE with codec order above. Endpoint responds with 200OK with iLBC on the top. Result: One-way audio: Endpoint is sending iLBC:30 to Asterisk, but Asterisk is sending uLaw to endpoint. | ||
Comments: | By: Asterisk Team (asteriskteam) 2017-10-16 11:36:21.645-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:36:46.338-0500 Packet capture By: Joshua C. Colp (jcolp) 2017-10-16 11:49:21.169-0500 The console output with debug enabled is needed for this to see how things are negotiated within Asterisk. The configuration itself is also needed as there are options which can alter this behavior. By: Luke Escude (lukeescude) 2017-10-16 12:46:33.681-0500 Attaching pjsip.conf and debug output. By: Jared Hull (fortytwo) 2017-10-16 14:04:53.674-0500 This seems to be fixed in 15.1.0 RC By: Rusty Newton (rnewton) 2017-10-16 15:58:22.261-0500 Luke, can you confirm if this is reproducible in latest 15 or in 15 GIT branch ? By: Luke Escude (lukeescude) 2017-10-16 16:02:13.013-0500 Rusty, it does appear to be fixed in 15.1-RC1 By: Joshua C. Colp (jcolp) 2017-10-20 10:03:16.908-0500 I'm going to mark this as fixed since it is resolved in the 15.1.0 release candidate. |