| Summary: | ASTERISK-26611: res_rtp_asterisk: Fix byte order on non-8kHz signed linear | ||||
| Reporter: | Vitaly K (bg1) | Labels: | |||
| Date Opened: | 2016-11-18 02:12:12.000-0600 | Date Closed: | 2017-02-21 14:42:52.000-0600 | ||
| Priority: | Minor | Regression? | |||
| Status: | Closed/Complete | Components: | Core/RTP | ||
| Versions: | 13.7.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 14.04.5 on i686 | Attachments: | ( 0) L16_sending_little_endian_bugfix.patch | ||
| Description: | I try use L16/16000 codec enabled by allow=slin16 in sip.conf of asterisk-13.7.0 on x86 arch with communication with softphone on top of pj-project.
When play test wav file peer side heard noise instead of music. With other codec selected - music heard as expected. I run tests with MixMonitor on asterisk - record is music not noise. I convert wav file to raw sln16 and convert it to big-endian (because asterisk can't read big-endian wav files aka RIFX) In this case peer heard music not noise! I run tcpdump for catch rtp stream and manually examine raw rtp data and raw sln16 (but big-endian) file. Byte order in this sources is same! I make some review for asterisk source code and found: a) asterisk allow to read only little-endian wav files aka RIFF b) when this type of file readed always convert to native machine byte order and define this format as slin16 c) when select codec is L16 same format used and no convertion of byte order before send rtp d) on little-endian machines this cause outgoing stream placed in little-endian byte order It breaks of RFC what define L16 have big-endian byte order. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-11-18 02:12:13.709-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: Rusty Newton (rnewton) 2016-11-23 15:47:45.951-0600 There has been a ton of fixes since 13.7.0 (nearly a year ago) and chan_sip is extended support since version 12. Although, I believe the results will probably be the same, can you test with pjsip and a recent version of 13 to verify? Can you additionally include a pcap from your machine, demonstrating the issue? Thanks! By: Vitaly K (bg1) 2016-11-24 22:09:07.255-0600 Patch By: Joshua C. Colp (jcolp) 2016-11-28 06:19:01.385-0600 Assigning to you until license is accepted and patch appears. Afterwards if you'd like to follow the wiki page linked on the initial comment for getting it up for code review it will be included faster, otherwise it falls to someone else to do so. By: Rusty Newton (rnewton) 2016-11-29 09:24:09.368-0600 [~bg1] , to be clear - your patch will not show up on the issue until the license is accepted. As we cannot accept a patch submitted without an associated license submission. By: Asterisk Team (asteriskteam) 2016-12-13 12:00:01.503-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Sean Bright (seanbright) 2017-02-21 14:42:52.256-0600 Resolved by https://gerrit.asterisk.org/#/c/4843/7 | ||||