Asterisk
  1. Asterisk
  2. ASTERISK-17408

[patch] IAX2 incompatible requested/capability between 1.8 SVN and any 1.8.x.y tagged release <= 1.8.2.3

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2
    • Target Release Version/s: None
    • Component/s: Channels/chan_iax2
    • Labels:
      None
    • Source Revision Number:
      301264
    • Mantis ID:
      18812
    • Regression:
      No

      Description

      1.8 SVN iax call to 1.8.2.3 box is rejected.

      console output on 1.8.2.3 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 1.8.2.3 all is well again.

                • ADDITIONAL INFORMATION ******

      Codec bit fields seem to be reversed!

      Category reported as a chan_iax problem, as that is how it presents itself.

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        John Covert added a comment -

        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.

        Show
        John Covert added a comment - 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.
        Hide
        Alec Davis added a comment -

        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 1.8.2.3, while 1.8.3 is still in 'testing' or release candidate. So deployments today of 1.8.2.3 won't be able to communicate with a box 1.8.3 next month.

        My suggestion of a minor release update to 1.8.2.4 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.

        Show
        Alec Davis added a comment - 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 1.8.2.3, while 1.8.3 is still in 'testing' or release candidate. So deployments today of 1.8.2.3 won't be able to communicate with a box 1.8.3 next month. My suggestion of a minor release update to 1.8.2.4 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.
        Hide
        Terry Wilson added a comment -

        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.

        Show
        Terry Wilson added a comment - 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.
        Hide
        Alec Davis added a comment -

        Ignoring past releases then, 1.8.2.3 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 1.8.2.3) when it's out of release candidate.

        Admittedly the 1.8.2.3 deployments need to be alerted some how.

        Show
        Alec Davis added a comment - Ignoring past releases then, 1.8.2.3 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 1.8.2.3) when it's out of release candidate. Admittedly the 1.8.2.3 deployments need to be alerted some how.
        Show
        Leif Madsen added a comment - Issue closed per http://lists.digium.com/pipermail/asterisk-dev/2011-February/048032.html

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: