ASTERISK-17814: When a call is blind-transfered to another extension, the CLI wrongly display the transfered call as been hung up.

[Home]

Summary: ASTERISK-17814: When a call is blind-transfered to another extension, the CLI wrongly display the transfered call as been hung up.

Reporter: thomas_foerster (thomas_foerster) Labels:

Date Opened: 2011-05-05 15:41:38 Date Closed: 2012-01-26 09:16:00.000-0600

Priority: Minor Regression? No

Status: Closed/Complete Components: Channels/chan_sip/Transfers

Versions: 1.8.4 Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) extensions.conf

Description: Phone A is on a call with PSTN caller (SIP/sbc2-00000063).
Phone A originates a blind transfer to extension B (992101)
CLI displays "== Spawn extension (customer, 992101, 1) exited non-zero on 'SIP/sbc2-00000063'"
Phone B is called and successfully bridged to PSTN caller.

There isn't any problem in the way the call is actually handled. Nevertheless the CLI displays that the transfered call is being hang up and then it bridges it to the destination SIP peer. This is happening on a server that handles a heavy load of blind transfers and Asterisk is crashing daily on this specific server. It seems that the server crashes when an "already-closed-on-the-CLI" channel is really hung up.

All this does not happen when using attended transfer instead of blind transfer.

****** ADDITIONAL INFORMATION ******

== Spawn extension (customer, 992101, 1) exited non-zero on 'SIP/sbc2-00000063' appears at two occurences during the same call.

Entire call CLI output :

[May 5 16:24:35] -- Executing [s@customer-inbound:1] Answer("SIP/sbc2-00000063", "") in new stack
[May 5 16:24:35] -- Executing [s@customer-inbound:2] Dial("SIP/sbc2-00000063", "SIP/t050992202") in new stack
[May 5 16:24:35] == Using SIP RTP TOS bits 184
[May 5 16:24:35] == Using SIP RTP CoS mark 5
[May 5 16:24:35] -- Called t050992202
[May 5 16:24:35] -- SIP/t050992202-00000064 is ringing
[May 5 16:24:37] -- SIP/t050992202-00000064 answered SIP/sbc2-00000063
[May 5 16:24:37] -- Packet2Packet bridging SIP/sbc2-00000063 and SIP/t050992202-00000064
[May 5 16:24:38] -- Started music on hold, class 'default', on SIP/sbc2-00000063
[May 5 16:24:43] -- Stopped music on hold on SIP/sbc2-00000063
[May 5 16:24:43] == Spawn extension (customer, 992101, 1) exited non-zero on 'SIP/sbc2-00000063'
[May 5 16:24:43] -- Executing [992101@customer:1] Dial("SIP/sbc2-00000063", "SIP/t050992101") in new stack
[May 5 16:24:43] == Using SIP RTP TOS bits 184
[May 5 16:24:43] == Using SIP RTP CoS mark 5
[May 5 16:24:43] -- Called t050992101
[May 5 16:24:43] -- SIP/t050992101-00000065 is ringing
[May 5 16:24:49] == Spawn extension (customer, 992101, 1) exited non-zero on 'SIP/sbc2-00000063'

Comments: By: David Woolley (davidw) 2011-05-06 06:16:51

As I understand it, mainline support for 1.6.2 ceased on April 21st.

The way that Asterisk implements SIP transfers, the original channel IS hung up. The only reservation I might have is that I think the channel should have been re-named to a zombie, at that point.

Asterisk cannot redirect a bridged channel. Instead it clones it, a process called masquerading, then allows the original channel to hang up, with some flags set to limit the amount of cleaning up that is done.

If you are getting crashes, you need to address the actual crashes, with a backtrace, using a 1.8.x version (built unoptimised).
By: Leif Madsen (lmadsen) 2011-05-09 08:49:39

Per davidw, you'll have to address the crashing on Asterisk 1.8. If you can reproduce there, then please follow up with an unoptimized backtrace. Thanks!
By: Matt Jordan (mjordan) 2011-12-15 08:59:50.324-0600

As requested by Leif and David, if this is an issue in 1.8 we need a backtrace[1] produced from that version in order to move your issue forward. As a number of blind transfer issues have been resolved in the 1.8 branch, please use the latest version of 1.8 (1.8.8.0) for your testing. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:

make install

After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report.

[1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

By: Matt Jordan (mjordan) 2012-01-26 09:16:06.489-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines