blind transfer works but not Xfer on aastra

Home » Asterisk Users » blind transfer works but not Xfer on aastra
Asterisk Users 6 Comments

Upgraded from 16.2.14 to 1.6.2.15 on Fedora 13, with aastra 9133i and 57i.

On 9133i and 57i:

## works for a blind transfer.

XferXfer doesn’t!

All this worked on 1.6.2.14.

Nothing useful on cli, verbose 3, DEBUG. Here extension 169 answers an
outside call, and tries to transfer it to 145 using the Xfer button:

6 thoughts on - blind transfer works but not Xfer on aastra

  • href=”mailto:asterisk-users@lists.digium.com”>asterisk-users@lists.digium.com

    This was supposedly fixed in 1.6.2 on November 22, 2010. So isn’t the
    fix in 1.6.2.15, released 12/8?

    In any event, that bug has been declared fixed, so you can’t add a note.

    sean

  • Not necessarily, no. Releases go through a ‘release candidate’ phase for
    a week (or two, sometimes three) before being declared ‘ready’, so fixes
    made before the release date aren’t necessarily included. The changelog
    included in the release will always indicate what revisions are included
    in it, though.

  • That is indeed the purpose; was the issue reported prior to 1.6.2.15
    graduating to a full release? If not, that means nobody saw it, which is
    unfortunate, but given that it’s not realistic to expect hundreds of
    users to test release candidates in real-world scenarios, it’s what happens.

    This is also why the Asterisk test suite continues to grow, in order to
    be able to catch regressions of this type before they even get into a
    release candidate. If there’s not an existing test that could catch this
    problem, then that’s an area where some help would be quite welcome.

  • But the 1.6.2.15-rc1 tag was made on 2010-11-15, one week earlier.
    Granted, a one week delay between the tag being made and being announced
    is a bit excessive, but it still completely explains why the fix was not
    in -rc1.

    The 1.6.2.15 release was made on 2010-12-02, which certainly indicates
    that not being aware of this regression and getting the fix into the
    release is something the release management team needs to look into. At
    a minimum, this issue being fixed on the 22nd should have prompted an
    -rc2 release, with this issue being listed as a ‘blocker’ for the
    eventual 1.6.2.15 release. In fact, this issue was known about for about
    three weeks before 1.6.2.15-rc1 was made, so I’d suggest that the -rc
    shouldn’t have even been made with this outstanding. There was a
    breakdown in the process somewhere.