[asterisk-bugs] [JIRA] (ASTERISK-26611) res_rtp_asterisk: Fix byte order on non-8kHz signed linear

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-26611:
-----------------------------------

    Assignee: Vitaly K  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

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.

> res_rtp_asterisk: Fix byte order on non-8kHz signed linear
> ----------------------------------------------------------
>
>                 Key: ASTERISK-26611
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26611
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/RTP
>    Affects Versions: 13.7.0
>         Environment: Ubuntu 14.04.5  on i686 
>            Reporter: Vitaly K
>            Assignee: Vitaly K
>            Severity: Minor
>         Attachments: L16_sending_little_endian_bugfix.patch
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)