Summary:	ASTERISK-05358: slinear inconsistently byteswapped
Reporter:	Lee Howard (faxguy)	Labels:
Date Opened:	2005-10-24 07:24:51	Date Closed:	2011-06-07 14:10:30
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When using slinear for the codec sometimes the server expects and delivers the audio data from the client "byteswapped", and on other servers it does not. For example, I have Asterisk installations on Pentium III and Athlon servers.  All of these servers expect and deliver slinear data "byteswapped" (meaning that I have to byteswap it in order for spandsp to utilize it).  On the other hand, some other users of IAXmodem (these have Pentium 4 servers) must not perform the byteswapping. I realize that there may be some issue of needing to handle 16-bit integers differently on different systems (internally).  However, when dealing with external client communications there must be a single standard.
Comments:	By: Russell Bryant (russell) 2005-10-24 20:45:25 Big endian would be the standard.  (This means that the most significant byte is sent first.)  Which is not doing it correctly? By: Lee Howard (faxguy) 2005-10-25 11:39:46 Honestly, I don't have the information to answer your question. Here's what I know: IAXmodem uses slinear audio data, as that's what spandsp uses.  I'm not sure which endianness spandsp uses, but you could ask Steve to find out, I guess, but I'm not sure that knowledge will help you fix an inconsistency in how chan_iax is delivering audio data to the client.  On some platforms it sends it big-endian, and on others it sends it little-endian.  You're saying that it needs to be big-endian, and that's fine, but I can't tell you which platform is using big-endian or not. On all of my systems and installations I have had to byteswap the audio data coming from the Asterisk server before feeding it into spandsp.  This is fine.  This is not the problem.  The problem is that I have reports from other IAXmodem users where the byteswapping breaks things for them.  So I'm in a situation, then, where I have to create a configuration option to control the byteswapping, and the user then needs to "listen" to test the audio to see if it is not staticky, and if it is, then to change the byteswapping configuration.  That's more than a user should be expected to do with network communications.  I would think that chan_iax should be communicating in a single endianness over all platforms... regardless of how it is handled internally. Now, it is fully possible that something has changed in Asterisk over the last several months and that these reporters are using a sufficiently different Asterisk version from me... and that the endianness was "fixed" between my version and their version (or vice versa).  I'm using a CVS v1_0 from 8/31. By: Julian J. M. (julianjm) 2005-10-26 13:36:31 I'm one of those users who needed to comment the byteswap() lines. I'm runing asterisk 1.0.7+bristuff. CPU: Pentium4 2.Ghz Motherboard: Asus P5P800 (Intel 865 chipset) Julian. By: Lee Howard (faxguy) 2005-10-26 13:49:17 I do suppose that it's possible that the issue is on the spandsp-side of things (like maybe it's not handling 16-bit signed data in the correct endianness for some platforms, and so IAXmodem's byteswapping is merely covering-up a spandsp oversight).  I'll bring this up with Steve next time I chat with him.  Anyway, I'm not saying that's what it is, but only a possibility. By: Mark Spencer (markster) 2005-10-30 02:24:10.000-0600 I do not believe this is a problem in CVS head, can you confirm?  You will obviously have to test asterisk + cvs head to asterisk + cvs head, then you can try asterisks + cvs stable.  Do *not* test with bristuff. By: Lee Howard (faxguy) 2005-10-31 11:13:49.000-0600 Alright.  So if we say that IAX consistently delivers data in big-endian, and since spandsp is always going to accept data in the native byte ordering... then it can only mean that on those systems that do not require byteswapping of the IAX voice data before passing it on to spandsp that they must not be little-endian, despite the processor type.  (Meaning, something, somewhere on the system caused spandsp - autoconf, I believe - to think that it was big-endian... and thus the error is either in the system or in autoconf or in whatever is misunderstanding the system type to be big-endian when it should be little.) So, with this conclusion I think that this bug report can be closed. By: Russell Bryant (russell) 2005-10-31 13:52:15.000-0600 Data is always (supposed to be) sent Big-Endian over the network.  On the receiving side, it is converted to native endian using ntohs (man ntohs).  This should be done in IAXmodem. If you think there is still a problem, feel free to re-open this report.