Summary:ASTERISK-17408: [patch] IAX2 incompatible requested/capability between 1.8 SVN and any 1.8.x.y tagged release <=
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2011-02-15 04:47:45.000-0600Date Closed:2011-06-07 14:00:45
Versions:1.8.2 Frequency of
Environment:Attachments:( 0) bug18812-strcompat.diff.txt
Description:1.8 SVN iax call to box is rejected.

console output on destination box

[Feb 15 23:22:52] NOTICE[16398]: chan_iax2.c:10958 socket_process: Rejected connect attempt from XXX.YYY.ZZZ.AAA, requested/capability '0x800000000000000 (nothing)'/'0xf07000000000000 (nothing)' incompatible with our capability '0x70f (g723|gsm|ulaw|alaw|g729|speex|ilbc)'.

reverting the 1.8SVN box back to all is well again.


Codec bit fields seem to be reversed!

Category reported as a chan_iax problem, as that is how it presents itself.
Comments:By: Alec Davis (alecdavis) 2011-02-16 02:47:25.000-0600

Temporarily reverting changes implemented in ASTERISK-17209 fix it.
These boxes are both Intel, Debian lenny.

Further testing, without patch:
Originating a call from 1.8 SVN (Asterisk SVN-trunk-r308099) to any of
  1.8.2 fails with the following on the destination console:

[Feb 16 22:22:49] NOTICE[13425]: chan_iax2.c:10958 socket_process: Rejected connect attempt from xxx.yyy.zzz.aaa, requested/capability '0x800000000000000 (nothing)'/'0xf07000000000000 (nothing)' incompatible with our capability '0x70f (g723|gsm|ulaw|alaw|g729|speex|ilbc)'.

But to 1.6.2 still works.

Thus, all branch and tag versions of 1.8.x up to and including require  patch bug18812.strcompat.diff.txt

By: Alec Davis (alecdavis) 2011-02-16 04:38:31.000-0600

This in the future may create huge IAX issues for users ugrading to a seemingly stable tagged release version of 1.8.0, or, and the others keeping more upto date with next tagged 1.8.3 and 1.8 the branch.

Seems like there needs to be a, and incorporating this change. Or some other way to make 1.8 SVN compatible again.

By: John Covert (jcovert) 2011-02-16 08:05:10.000-0600

By reverting the patch, more releases will be created that are wrong.

The patch fixes not only incompatibilities with other releases, it also fixes incompatibilities between two machines running the same release but with different configurations.

The original patch corrects a faulty implementation of the library routines ntohll/htonll (see http://www.unix.com/man-page/All/3socket/htonll/ ).

In a "bad release" (i.e. any release without the patch) a little endian machine without the library routines htonll/ntohll will be incompatible not only with releases with the patch but also with a system running the same release if either

(a) the machine has the library routines htonll/ntohll
   (I don't know how common this routine is in *nix releases)


(b) the machine is a big endian machine.

The correction to ntohll/htonll definitely needs to be in SVN or more releases will be created with this bug.  Creating tagged releases with this patch seems like the right thing to do.


By: Paul Belanger (pabelanger) 2011-02-16 12:21:22.000-0600

Have you tested with the 1.8.3-rc2 builds?  I ran into this issue about a month ago when Digium upgraded there version of Asterisk.  I was running 1.8.0 and to upgrade to the latest 1.8 branch to fix it.

By: Terry Wilson (twilson) 2011-02-16 12:35:22.000-0600

alecdavis: If the problem is that people haven't updated from 1.8.x, making new releases that are 1.8.x.1 or whatever that are compatible with 1.8.3+ isn't going to fix the problem. People who aren't updating won't have updated to the 1.8.x.1 release either, so it won't have fixed anything.

The only case it could possibly help is if there are regressions in 1.8.3+ that they can't live with, but they must communicate with someone who is 1.8.3+. I would think this would be a vanishingly small group of people. Not worth it, IMHO.

By: John Covert (jcovert) 2011-02-16 12:53:22.000-0600

The version of strcompat.c in 1.8.3-rc2 has the htonll/ntohll correction that is in SVN 301263

twilson is right:

>The only case it could possibly help is if there are regressions in 1.8.3+
>that they can't live with, but they must communicate with someone who
>is 1.8.3+

And if that is the case, then they can patch strcompat.c themselves simply by grabbing SVN 301264.  In fact, anyone running 1.8.x < 1.8.3 really should get strcompat 301263 and rebuild.

Reverting is just going to make the problem harder to fix in the long run.

Please don't.

By: Alec Davis (alecdavis) 2011-02-16 13:53:20.000-0600

jcovert: I'm not saying revert it. As from 1.8.3.rc1 and of course trunk it's correct.

I am saying that 1.8.0 < 1.8.3 will need to be patched to be able to communicate with a little endian box 1.8.3+

Which at the moment the last perceived stable release is, while 1.8.3 is still in 'testing' or release candidate. So deployments today of won't be able to communicate with a box 1.8.3 next month.

My suggestion of a minor release update to suggests to the 1.8.2 followers that they should update. Likewise for the more cautious 1.8.1 and 1.8.0 followers.

Patch and rebuilding is fine for the development community, but of the millions of downloads in the last year, I would have thought that the percentage of unpatched tarball deployments + tagged releases to be significant, compared to the remainder being download and patch community.

By: Terry Wilson (twilson) 2011-02-16 13:59:59.000-0600

alecdavis: If someone needs a single fix for a specific past release, they have always had to apply it manually. Making an update for all past 1.8.x releases just isn't something that is normally done.

By: Alec Davis (alecdavis) 2011-02-16 14:27:56.000-0600

Ignoring past releases then, is current, it was released with a single fix in mind to be compatible with FFA (Fax for Asterisk).

1.8.3 will cause a regression (with when it's out of release candidate.

Admittedly the deployments need to be alerted some how.

By: Leif Madsen (lmadsen) 2011-02-16 14:56:29.000-0600

Issue closed per http://lists.digium.com/pipermail/asterisk-dev/2011-February/048032.html