Asterisk
  1. Asterisk
  2. ASTERISK-9066

[patch] Attended transfer fails when hanging up before answer.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Resources/res_features
    • Labels:
      None
    • SVN Revision Number:
      59083
    • Mantis ID:
      9338
    • Regression:
      No

      Description

      An attended transfer fails if the transferer hangs up before answer.

      1. Call comes in to Phone 1 (IAX to SIP in this case).
      2. Phone 1 initiates an attended transfer to any destination (SIP/IAX/whatever).
      3. Destination is ringing.
      4. Phone 1 hangs up.

      When Phone 1 (transferer) hangs up, both the destination and the incoming call (transferee) will be terminated as well. I believe this is not the expected behaviour. Instead it should be "converted" to a blind transfer. The expected behaviour would be to connect the destination with the transferee.

      This issue has been discussed in bug 0003729, but it seems like the committed code does not handle this kind of hangup as expected. The current code handle this scenario partially. When the transferer hangs up, this is taken care of by flagging it as "ready" anyway (in ast_feature_request_and_dial), which allows the transfer to proceed.

      The failure occurs in builtin_atxfer because the destination is not up (newchan->_state != AST_STATE_UP). The state at that point is AST_STATE_DOWN (OT: Is this really the correct state? Why not AST_STATE_RINGING?).

                • ADDITIONAL INFORMATION ******

      A patch, features_attended_rev0.diff, has been attached to this bug. It removes the newchan->_state check. Based on my own testing, I have not seen any scenario yet where this channel status is necessary there. If the channel status is set to anything other than AST_STATE_DOWN at that point, it seems to trigger anyway (because another expression evaluates true).

      Is this a correct assumption? Give it a shot and let me know.

        Activity

        Hide
        David Svanlund added a comment -

        Added a note to bug 8413, which might solve this issue. It depends on the outcome of that bug.

        Show
        David Svanlund added a comment - Added a note to bug 8413, which might solve this issue. It depends on the outcome of that bug.
        Hide
        Russell Bryant added a comment -

        This patch is correct. That check really isn't necessary. It has been committed to 1.2, 1.4, and trunk in revisions 62547, 62548, and 62549. I am going to continue to work on the patch from 8413 because it adds some additional features that would be nice, but that will only be for trunk.

        Thanks!

        Show
        Russell Bryant added a comment - This patch is correct. That check really isn't necessary. It has been committed to 1.2, 1.4, and trunk in revisions 62547, 62548, and 62549. I am going to continue to work on the patch from 8413 because it adds some additional features that would be nice, but that will only be for trunk. Thanks!

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development