[asterisk-bugs] [JIRA] (ASTERISK-26611) L16/16000 codec send little endian data with chan_sip on x86

[Rusty Newton (JIRA)]

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

Rusty Newton updated ASTERISK-26611:
------------------------------------

    Assignee: Vitaly Khalmansky
      Status: Waiting for Feedback  (was: Triage)

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!

> L16/16000 codec send little endian data with chan_sip on x86
> ------------------------------------------------------------
>
>                 Key: ASTERISK-26611
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26611
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Codecs/General, Core/RTP
>    Affects Versions: 13.7.0
>         Environment: Ubuntu 14.04.5  on i686 
>            Reporter: Vitaly Khalmansky
>            Assignee: Vitaly Khalmansky
>
> 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)