[Home]

Summary:ASTERISK-16847: Blind transfer failure, A calls B, B transfers to C
Reporter:Karsten Wemheuer (kwemheuer)Labels:
Date Opened:2010-10-22 04:43:10Date Closed:2010-12-07 12:51:15.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) extensions.conf
( 1) failed.log
( 2) issue_0018185_full_log
( 3) sip.conf
( 4) working.log
Description:The summary says it: Transfers are not working in one direction. In detail:

I set up an asterisk system (version 1.8.0). While using a SIP only
environment I discovered a problem using blind transfer. The phones are
SNOM or Aastra and are using the SIP REFER Method.

For debugging purposes I stripped down the environment to a simple dialplan with only three extensions. There are three phones (Snom) registered to asterisk. I use release 1.8.0 from yesterday.

There are three extensions: 100, 150, and 180. There are three SIP-Devices: phone1, phone2, and phone3. (See extensions.conf, sip.conf)

User on phone1 dials 150 (phone2). User on phone2 transfers the call to phone3 (using blind transfer, SIP REFER Method). The calls fails (See debug output in file failed.log)

The following scenario is working: User on phone1 dials 150 (phone2). User on phone1 transfers the call to phone3 (using blind transfer, SIP REFER Method). See debug output in file working.log.
Comments:By: Paul Belanger (pabelanger) 2010-10-22 07:32:56

We'll also need a SIP debug to see what is happening (see below).

---
We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt
By: Karsten Wemheuer (kwemheuer) 2010-10-22 09:41:45

I uploaded full debug log as requested. (see issue_0018185_full_log.
By: Jonas Bofjäll (job) 2010-10-22 15:42:30

Apply patch from the ticket marked as a duplicate to this one for an emergency fix to your problem.
By: rsw686 (rsw686) 2010-10-22 20:35:00

I'm seeing the same issue with SIP REFER transfers where the call is hung up. After switching back to 1.6.2.11 from 1.8 with the same config the problem goes away.

On both 1.6.2.11 and 1.8 with FreePBX the log shows

[Oct 22 18:42:53] VERBOSE[20889] pbx.c:     -- Executing [s@macro-hangupcall:9] Hangup("SIP/1050-0000000c", "") in new stack
[Oct 22 18:42:53] VERBOSE[20889] app_macro.c:   == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/1050-0000000c' in macro 'hangupcall'
[Oct 22 18:42:53] VERBOSE[20889] app_macro.c:   == Spawn extension (from-internal-xfer, 2001, 1) exited non-zero on 'SIP/1050-0000000c' in macro 'dialout-trunk'
[Oct 22 18:42:53] VERBOSE[20889] pbx.c:   == Spawn extension (from-internal-xfer, 2001, 1) exited non-zero on 'SIP/1050-0000000c'

At this point 1.8 drops the call and nothing more is shown in the log. 1.6.2.11 continues with

[Oct 22 19:01:35] VERBOSE[24071] pbx.c:     -- Executing [2001@from-internal-xfer:1] Macro("SIP/1050-00000000", "exten-vm,2001,2001") in new stack
[Oct 22 19:01:35] VERBOSE[24071] pbx.c:     -- Executing [s@macro-exten-vm:1] Macro("SIP/1050-00000000", "user-callerid,") in new stack
[Oct 22 19:01:35] VERBOSE[24071] pbx.c:     -- Executing [s@macro-user-callerid:1] Set("SIP/1050-00000000", "AMPUSER=2000") in new stack
By: Jonas Bofjäll (job) 2010-10-23 02:26:45

rsw686: there would be nothing in the logs in the problem is the same as the one I saw in issue 18192.

The call is dropped when ast_queue_control is called in main/channel.c to read the remaining frames. You can remove that call with this patch:

--- main/channel.c 2010-10-22 18:22:31.000000000 +0200
+++ main/channel.c 2010-10-22 21:49:44.669221930 +0200
@@ -3620,7 +3620,7 @@
                * frame. */
- if (ast_check_hangup(chan)) {
- ast_queue_control(chan, AST_CONTROL_HANGUP);
- } else {
+// if (ast_check_hangup(chan)) {
+// ast_queue_control(chan, AST_CONTROL_HANGUP);
+// } else {
                       goto done;
- }
+// }
       }


By: rsw686 (rsw686) 2010-10-23 09:07:01

job: I applied your patch and the problem was resolved. The section of code you commented was not in 1.6.2.11.
By: Karsten Wemheuer (kwemheuer) 2010-10-25 01:43:28

job: I too applied Your patch from 18192. It resolves the problem I have. Will this be the final solution or is it just a quick workaround?
By: Jonas Bofjäll (job) 2010-10-25 03:29:17

It's a workaround. The behavior to eat remaining frames is new in 1.8.0 and it was probably added for a reason but I just don't know what that reason is. As it is now it drops the call before it is transferred.
By: Jonas (jonascph) 2010-10-29 06:23:23

We have the same issue. We had no problems in 1.8 rc2. So i'm quite puzzled and disapointed this made it into the final 1.8
By: Kevin Scott Adams (nivek) 2010-11-02 06:45:56

Had same issue using blind transfers from a Polycom 650 phone...Attended worked fine.  Applied patch and both blind and attended transfer work fine.
By: Örn Arnarson (orn) 2010-11-04 06:38:36

Same issue with Aastra 6757i -- commenting out the code fixed the issue for me too.
By: Jeff Otterson (otterson) 2010-11-16 12:00:34.000-0600

I have the same issue with asterisk 1.4 branch and Cisco 7960s.  The change shown in job's report of 10-23-10 makes 1.4 blind transfer work again.
By: Matt Riddell (zx81) 2010-11-17 15:46:45.000-0600

Same problem for me in Asterisk 1.4 from SVN: Rev 292411

Patch (well commenting section) from #128349 fixes it here too - Snom 320 phones.
By: Tan Tuerel (thsgmbh) 2010-11-18 02:14:50.000-0600

Patch fixed it for me too... SNOM320+SNOM360.
By: Digium Subversion (svnbot) 2010-11-22 12:46:29.000-0600

Repository: asterisk
Revision: 295790

U   branches/1.4/apps/app_macro.c
U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/include/asterisk/frame.h
U   branches/1.4/main/channel.c
U   branches/1.4/main/pbx.c

------------------------------------------------------------------------
r295790 | rmudgett | 2010-11-22 12:46:27 -0600 (Mon, 22 Nov 2010) | 46 lines

The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.

To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.

Note that if the CLI command were done on the channel call leg associated
with B it works.

This regression was a result of the fix for issue ASTERISK-15731
(https://reviewboard.asterisk.org/r/740/).

The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.

The struct ast_channel._softhangup code is a mess.  The variable is used
for several purposes that do not necessarily result in the call being hung
up.  I have added doxygen comments to describe how the various _softhangup
bits are used.  I have corrected all the places where the variable was
tested in a non-bit oriented manner.

The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.

JIRA SWP-2470
JIRA SWP-2489

(closes issue ASTERISK-16838)
Reported by: SantaFox
(closes issue ASTERISK-16847)
Reported by: kwemheuer
(closes issue ASTERISK-16873)
Reported by: zahir_koradia
(closes issue ASTERISK-16891)
Reported by: vmarrone
(closes issue ASTERISK-16950)
Reported by: mbrevda
(closes issue ASTERISK-16972)
Reported by: nerbos

Review: https://reviewboard.asterisk.org/r/1013/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295790
By: Digium Subversion (svnbot) 2010-11-22 13:28:29.000-0600

Repository: asterisk
Revision: 295843

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_macro.c
U   branches/1.6.2/include/asterisk/channel.h
U   branches/1.6.2/include/asterisk/frame.h
U   branches/1.6.2/main/channel.c
U   branches/1.6.2/main/pbx.c

------------------------------------------------------------------------
r295843 | rmudgett | 2010-11-22 13:28:27 -0600 (Mon, 22 Nov 2010) | 53 lines

Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
 
 The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
 
 To recreate the problem:
 1) Party A calls Party B
 2) Invoke CLI "channel redirect" command to redirect channel call leg
 associated with A.
 3) All associated channels are hung up.
 
 Note that if the CLI command were done on the channel call leg associated
 with B it works.
 
 This regression was a result of the fix for issue ASTERISK-15731
 (https://reviewboard.asterisk.org/r/740/).
 
 The regression affects all features that use an async goto to execute the
 dialplan because of an external event: Channel redirect, AMI redirect, SIP
 REFER, and FAX detection.
 
 The struct ast_channel._softhangup code is a mess.  The variable is used
 for several purposes that do not necessarily result in the call being hung
 up.  I have added doxygen comments to describe how the various _softhangup
 bits are used.  I have corrected all the places where the variable was
 tested in a non-bit oriented manner.
 
 The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
 hangup request so the soft hangup requests that do not normally result in
 a hangup do not hangup.
 
 JIRA SWP-2470
 JIRA SWP-2489
 
 (closes issue ASTERISK-16838)
 Reported by: SantaFox
 (closes issue ASTERISK-16847)
 Reported by: kwemheuer
 (closes issue ASTERISK-16873)
 Reported by: zahir_koradia
 (closes issue ASTERISK-16891)
 Reported by: vmarrone
 (closes issue ASTERISK-16950)
 Reported by: mbrevda
 (closes issue ASTERISK-16972)
 Reported by: nerbos
 
 Review: https://reviewboard.asterisk.org/r/1013/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295843
By: Digium Subversion (svnbot) 2010-11-22 13:36:13.000-0600

Repository: asterisk
Revision: 295866

_U  branches/1.8/
U   branches/1.8/apps/app_macro.c
U   branches/1.8/include/asterisk/channel.h
U   branches/1.8/include/asterisk/frame.h
U   branches/1.8/main/channel.c
U   branches/1.8/main/pbx.c

------------------------------------------------------------------------
r295866 | rmudgett | 2010-11-22 13:36:11 -0600 (Mon, 22 Nov 2010) | 60 lines

Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
 
 Merged revisions 295790 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
   
   The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
   
   To recreate the problem:
   1) Party A calls Party B
   2) Invoke CLI "channel redirect" command to redirect channel call leg
   associated with A.
   3) All associated channels are hung up.
   
   Note that if the CLI command were done on the channel call leg associated
   with B it works.
   
   This regression was a result of the fix for issue ASTERISK-15731
   (https://reviewboard.asterisk.org/r/740/).
   
   The regression affects all features that use an async goto to execute the
   dialplan because of an external event: Channel redirect, AMI redirect, SIP
   REFER, and FAX detection.
   
   The struct ast_channel._softhangup code is a mess.  The variable is used
   for several purposes that do not necessarily result in the call being hung
   up.  I have added doxygen comments to describe how the various _softhangup
   bits are used.  I have corrected all the places where the variable was
   tested in a non-bit oriented manner.
   
   The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
   hangup request so the soft hangup requests that do not normally result in
   a hangup do not hangup.
   
   JIRA SWP-2470
   JIRA SWP-2489
   
   (closes issue ASTERISK-16838)
   Reported by: SantaFox
   (closes issue ASTERISK-16847)
   Reported by: kwemheuer
   (closes issue ASTERISK-16873)
   Reported by: zahir_koradia
   (closes issue ASTERISK-16891)
   Reported by: vmarrone
   (closes issue ASTERISK-16950)
   Reported by: mbrevda
   (closes issue ASTERISK-16972)
   Reported by: nerbos
   
   Review: https://reviewboard.asterisk.org/r/1013/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295866
By: Digium Subversion (svnbot) 2010-11-22 13:42:05.000-0600

Repository: asterisk
Revision: 295867

_U  trunk/
U   trunk/apps/app_macro.c
U   trunk/include/asterisk/channel.h
U   trunk/include/asterisk/frame.h
U   trunk/main/channel.c
U   trunk/main/pbx.c

------------------------------------------------------------------------
r295867 | rmudgett | 2010-11-22 13:42:03 -0600 (Mon, 22 Nov 2010) | 67 lines

Merged revisions 295866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
 
 Merged revisions 295843 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
   
   Merged revisions 295790 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
     
     The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
     
     To recreate the problem:
     1) Party A calls Party B
     2) Invoke CLI "channel redirect" command to redirect channel call leg
     associated with A.
     3) All associated channels are hung up.
     
     Note that if the CLI command were done on the channel call leg associated
     with B it works.
     
     This regression was a result of the fix for issue ASTERISK-15731
     (https://reviewboard.asterisk.org/r/740/).
     
     The regression affects all features that use an async goto to execute the
     dialplan because of an external event: Channel redirect, AMI redirect, SIP
     REFER, and FAX detection.
     
     The struct ast_channel._softhangup code is a mess.  The variable is used
     for several purposes that do not necessarily result in the call being hung
     up.  I have added doxygen comments to describe how the various _softhangup
     bits are used.  I have corrected all the places where the variable was
     tested in a non-bit oriented manner.
     
     The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
     hangup request so the soft hangup requests that do not normally result in
     a hangup do not hangup.
     
     JIRA SWP-2470
     JIRA SWP-2489
     
     (closes issue ASTERISK-16838)
     Reported by: SantaFox
     (closes issue ASTERISK-16847)
     Reported by: kwemheuer
     (closes issue ASTERISK-16873)
     Reported by: zahir_koradia
     (closes issue ASTERISK-16891)
     Reported by: vmarrone
     (closes issue ASTERISK-16950)
     Reported by: mbrevda
     (closes issue ASTERISK-16972)
     Reported by: nerbos
     
     Review: https://reviewboard.asterisk.org/r/1013/
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=295867