[Home]

Summary:ASTERISK-14773: Transfering phone left connected
Reporter:Stanislaw Pitucha (viraptor)Labels:
Date Opened:2009-09-04 12:57:18Date Closed:2011-06-07 14:08:10
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full-log-a
( 1) full-log-b
Description:When doing a remote attended transfer in one of these 2 setups:

phones A,B,C --- proxy --- asterisks Z,X
when A->B call is on Z and B->C is on X, or:

phones A,B (with identity B1,B2), C --- asterisks Z,X
(A,B1 register on Z; B2,C on X)
when A->B1 call is on Z and B2->C is on X

In both scenarios Z and X are friends with no authentication needed.

The B phone doesn't get properly disconnected. asterisks invite/replace each other properly and the audio channel is ok. B itself drops one of the calls. But Z is not disconnecting B's call at all. You can replicate that scenario with minimalistic dialplan - _X.,Dial(SIP/${EXTEN}) in default on both sides.

If you do the same transfer, but on a single asterisk (local attended transfer), then the transferring phone will drop one of the call legs itself (like above) and asterisk will additionally drop the second one.

Tested with Snom 1XX, 3XX and GXP phones - problem always appears and the call is never dropped if the transfer is remote.
Comments:By: Stanislaw Pitucha (viraptor) 2009-09-07 04:27:07

Update - just tested *-1.6.1.6 with exactly the same outcome. It seems that this feature is broken in all versions.
By: Stanislaw Pitucha (viraptor) 2009-09-07 05:54:42

I believe this problem is the same as issueASTERISK-7580. Using the patch included there (applied to 1.6.1.6) resolved the problem for me (as in - the transferring party hangs up - not sure if there are any pvt or channel leaks)

I'll attach my sip debug logs (asked for in issueASTERISK-7580).
By: Leif Madsen (lmadsen) 2009-09-16 10:48:36

I'm marking this as Ready for Review as the reporter successfully tested the patch on issue ASTERISK-7580 (according to the notes here).

The patch that needs to be reviewed and possibly committed is attached to issue ASTERISK-7580. Thanks!
By: Stanislaw Pitucha (viraptor) 2009-09-16 11:10:47

Just in case someone is testing the patch on issue 0007784: I don't know the asterisk's internals that well, but there might be a mistake in the patch too - it sets the AST_... flag on ...->refer_call->flags[0], instead of ...->refer_call->owner. If it is wrong, it might have worked by accident previously.

I've tested the patch, but with the flag set on ->owner instead. It's working properly in production since 2009-09-07 and all transfers are being hung up.
By: c0rnoTa (c0rnota) 2009-10-21 10:26:06

So, I have a call drops on my production systems. I'm using E1 channel for external calls, IAX2 for inter asterisk calls and SIP for local calls.
Asterisk ver. 1.4.26
Dahdi 2.2.0
Libpri WAS 1.4.10.1

Operators (in queue) on first asterisk receive calls from DAHDI, make attended transfer via IAX on second asterisk, speake with another operator (in queue) and then brige dahdi caller with second operator. So. legs are not brige - call drops.

First of all, I found an issue PRI-68. I have updated libpri, but calls are droping.
Then I'v found busydetect=yes option in chan_dahdi.conf for my E1 channel. Set it to NO. Amount of call drops less then early. But still exist.

Today i'll try patch from ASTERISK-7580 with modification (set on ->owner). Is it my situation?

I'll tell you results.
By: Stanislaw Pitucha (viraptor) 2009-10-21 10:41:48

c0rnoTa: I don't think so. The problem in this bug is that the call is transferred correctly every time, but the transferring side is not hung up. It's not about the transfer failing, or call drops.
Also this case is sip-only - you seem to be using only zap and iax.
By: c0rnoTa (c0rnota) 2009-10-21 11:00:55

Wow. Thanks that you stoped me!

Another reason for call drops was issue ASTERISK-1582010.
By: Paul Belanger (pabelanger) 2010-05-11 20:46:45

Is this still an issue? Since patches have already been merged?
By: Leif Madsen (lmadsen) 2010-05-17 10:45:56

Suspending this issue. If this continues to be a problem please open a new issue reported against the latest release in the branch you're using in production (i.e. latest 1.4.x, or 1.6.2.x)