[Home]

Summary:ASTERISK-12475: Attended transfers call is lost
Reporter:Kaloyan Kovachev (knk)Labels:
Date Opened:2008-07-28 13:53:18Date Closed:2009-03-16 09:12:34
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) callrec.txt
( 1) calltrace.txt
Description:when the call is (attended) transferred and the transferrer hangs-up there are two channels, but no call associated with them, which in turn does not execute h extension on hangup.

****** STEPS TO REPRODUCE ******

A makes a call to B, then issues an attended transfer to C.
When C picks up the channel named 'Local/<C_number>' is closed.
When B does hangup the channel '<Tech>/<B_number>' is closed.
Now there are two channes with no call:

Ast*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/1014-0092d5a0    s@macro-OnAnswer:2   Up      Transferred Call(SIP/1016-0094
SIP/1016-00942de0    1016@Internal:1      Up      Transferred Call(SIP/1014-0092
2 active channels
0 active calls

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

there is a call timelimit involved and macro-OnAnswer just sets some variables passed as arguments to the calee's channel.

in 1.2 the is a new channel 'Transferred/<C_number>' when executes the h extension when the new (transfered) call is closed.

in 1.4 rev 113648 the bug is not present, but don't know (yet) when it was introduced
Comments:By: Kaloyan Kovachev (knk) 2008-08-05 09:27:16

the problem was introduced with commit 122589
By: Kaloyan Kovachev (knk) 2008-08-05 10:20:56

the commit have changed the Local channel not to contain the /n flag, which have caused the channel to be hangup after the remote party answers the call.

I can't upload the patch (single line to restore the flag), because it seems my previous 'Disclaimer of file' is lost. Should I sign a new one?
By: Mark Michelson (mmichelson) 2008-08-06 11:18:41

Last year we upgraded our installation of Mantis. part of this upgrade involved changing the way licenses are handled for submitting source code as well as changing the license itself. Since the license has changed, you need to sign the  new license agreement if you wish to make code submissions.

On to the issue: part of the reason that the /n flag was removed was in order to prevent a problem that allowed transferred users to gain transfer capabilities that they should not have. If I recall correctly, the removal of the /n from the Local channel was a major part of the fix and so just reverting that is not an option. A different solution will need to be made which correctly handles the situation.
By: Jeff Peeler (jpeeler) 2008-11-18 15:10:17.000-0600

I'm seeing the h extension get executed for the local channel, the zombie, the transferrer, as well as the final leg of the call. If this is still a problem a specific call flow would be helpful.
By: Mark Michelson (mmichelson) 2008-11-18 18:14:10.000-0600

This was probably introduced with the move to execute the h extension at the end of a bridge. In addition to what jpeeler has suggested, I would also highly recommend updating to a new checkout of 1.4 and verifying that this has not already been fixed independently.
By: Kaloyan Kovachev (knk) 2008-11-20 06:50:03.000-0600

It has probably already been fixed, as pointed from putnopvut. I will try to test with a new checkout this weekend and will confirm.
By: Leif Madsen (lmadsen) 2008-11-20 08:45:29.000-0600

Status changed to feedback while we wait for responds from reporter indicating this is fixed :)


By: Kaloyan Kovachev (knk) 2008-11-23 06:17:40.000-0600

I have updated to revision 158757 and hit a problem before the tests ...

with commit 156386 peer->whentohangup is set to "time(NULL) + 1" when "timelimit > 0" which is allways true when L(x:y:z) is used - i think it should be "timelimit > 0 && timelimit < 1000". As it is a single line of code its not worth the separate bugreport

test results for this bug comming soon
By: Kaloyan Kovachev (knk) 2008-11-23 07:01:12.000-0600

nope its still the same:
Ast*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/1070-b0884890    1014@Internal:1001   Up      Transferred Call(SIP/1016-0074
SIP/1016-007493a0    1016@Internal:1      Up      Transferred Call(SIP/1070-b088
2 active channels
0 active calls

just now there is a new channel SIP/1014 which is hangup together with Transfered/SIP/1070<ZOMBIE>, which never went trough the dialplan, but is hangup and the called extension is "unknown", the call's UNIQUEID for SIP/1014 is 1227444453.48 (1227444453.47 was the one for the initial/transferred call) and still no h extension is executed for SIP/1070 (and UNIQUEID 1227444453.47) at the end of the call even if it is several hours
By: Kaloyan Kovachev (knk) 2008-11-23 10:53:39.000-0600

sorry SIP/1014's hangup is not newly introduced (even it was unexpected) and looking a bit more on this again - it is the Transferred channel that should stay up until the end of the call, but ...
it is masqueraded and marked as ZOMBIE then the h extension is run on the ZOMBIE immediately after the masquerade (when the transferrer hangs up) and the original "Transfered/SIP/1070" channel disappears silently ...

isn't it that SIP/1070 is the one that should be masqueraded instead of Transferred/SIP/1070 ? ... i am completely lost here between ZOMBIEs and masquerades


EDIT: in the original report 1014 = 'party A', 1070 = 'party B' ... now it was the oposite and 1016 = 'party C' in both cases


By: Mark Michelson (mmichelson) 2008-11-24 19:21:45.000-0600

It isn't really clear how you are triggering this behavior, nor is it clear if the time limit is a factor on this issue. As jpeeler mentioned earlier, a specific call flow would be very helpful in trying to reproduce and determine how to resolve this issue. I tried several variations of hanging up various phones during  steps of the transfer but could never end up with any channels stuck in the states you are showing.
By: Kaloyan Kovachev (knk) 2008-11-25 02:07:16.000-0600

i have the call flow described in "Steps To Reproduce" ... will prepare a simple dialplan and test without time limit today and post the results (including the dialplan)
By: Kaloyan Kovachev (knk) 2008-11-25 12:08:15.000-0600

simple dialplan:
exten => _10XX,1,Dial(SIP/${EXTEN}|300|ghtwHTW)
and some NoOp() in h extension to help identifying the calls.
The call flow attached as calltrace.txt
By: Mark Michelson (mmichelson) 2008-11-25 14:28:26.000-0600

I am completely lost here.

In the attachment, I see the h extension executed for all three legs of the transfer. You make a note that if 1070 hangs up, then the h extension is not executed. I tried a test where the transferee hangs up while he is listening to music. The h extension does not execute immediately, but it does execute after either the transferor or transfer target hangs up. Is the problem that the h extension execution is delayed in this case?
By: Kaloyan Kovachev (knk) 2008-11-26 02:49:55.000-0600

well if 1014 hangs up and 1070 keep talking to 1014 we have the
"2 active channels
0 active calls"
case, so its more like that h extension is associated with 1014 instead of 1070, not just delayed (as mentioned in note 95343 its probably the wrong channel being masqueraded) ... will try to compare the code from 1.2, but it will probably take some time
By: Kaloyan Kovachev (knk) 2008-12-11 03:45:31.000-0600

could not find any (related) difference in the masquerading code between 1.2 and 1.4, but i still have the feeling that the wrong channel is masqueraded, because Local/1016 have never entered the dialplan, but is running the h extension when answered (lines 10-20 in calltrace.txt)
By: Leif Madsen (lmadsen) 2009-02-02 16:50:59.000-0600

KNK: think you could give this a shot again? A bunch of changes have happened in 1.4 and 1.6 lately in regards to transfers.
By: Kaloyan Kovachev (knk) 2009-02-03 03:30:19.000-0600

I think with 1.6 it was OK, but will test that too (hopefully by the end of the week)
By: Leif Madsen (lmadsen) 2009-02-03 07:59:06.000-0600

Great thanks for the update. Look forward to hearing back!
By: Kaloyan Kovachev (knk) 2009-02-03 10:40:34.000-0600

unfortunately it is still the same :(
attached is the CLI output from 1.4 where the call is lost and from 1.6 where it is OK.
btw in 1.6 the /n flag was never removed, but don't know how exactly the issue with transfer capabilities inheritance was fixed there
By: Barry Flanagan (barryf) 2009-02-23 12:21:59.000-0600

Hi,

I am having the same issue, with the latest 1.4 SVN code.
By: Kaloyan Kovachev (knk) 2009-02-24 03:09:26.000-0600

I am afraid that this can't be fixed without bringing back the '/n' flag for the Local channel or ...
Not sure if it is possible (safe?) to rename the newchan using xferto variable after it is answered and then set the h exten execution flag (where?) on it ...
By: Leif Madsen (lmadsen) 2009-03-02 17:54:32.000-0600

Assigned to dvossel to see if he can make any progress moving this issue forward. Thanks!
By: Russell Bryant (russell) 2009-03-16 09:12:12

After reviewing this issue, this is a change in behavior that we're just going to have to live with.  We really can not add the "\n" back in.  It caused a number of problems that were worse than this.  The only reason the 'h' extension ran before was a side effect of having the Local channel in the call path.

I completely agree that the behavior of the 'h' extension in this call scenario is not very ideal.  As soon as you bring in parking, transfers, and other things into play, the 'h' extension behavior is not necessarily what people expect.  However, improving it would be quite invasive, and will likely have to be a project that would only go into a new release of Asterisk.