Summary:	ASTERISK-17930: Attended transfer - transfering phone left connected
Reporter:	Maciej Krajewski (jamicque)	Labels:
Date Opened:	2011-05-26 09:52:14	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) invite_replaces ( 1) mk.pcap
Description:	The issue 0015833 still exists in newest version of Asterisk. 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.
Comments:	By: Maciej Krajewski (jamicque) 2011-05-26 09:52:52 issue 0019371 - blocks this issue By: David Woolley (davidw) 2011-05-27 06:12:52 I can't understand the scenario here, but: - at least up to 1.6.x asterisk cannot originate invite/replaces - transfers are done as internal manipulations - the rationale is that it is a back to back users agent, so you are transferring between the nearside user agents on asterisk; - if you have a proxy in this context, you have to make it translate any replaces into the namespace understood by the asterisk to which you are directing the request. Things may have changed in 1.8, but I would have hoped to have become aware of that, although we are locked into 1.6, at the moment. By: Maciej Krajewski (jamicque) 2011-05-27 06:29:36 The scenario is very simple. I've attached the SIP flow with 2 sides (A and B) and 2 connections. A send Invite to B B send Invite with replaces (second connection). A accepts it. But it does not send Bye to the first connection. According to attended transfer scenario it should. This issue has been patched very long time ago in https://issues.asterisk.org/view.php?id=7784 However no changes have been made to SVN. By: Leif Madsen (lmadsen) 2011-05-27 10:45:41 Is this reproducible without the proxy in front? By: Maciej Krajewski (jamicque) 2011-05-29 07:23:56 No it can't be reproduced without proxy. However, I can deliver an entrance to test environment to reproduce this problem. By: Maciej Krajewski (jamicque) 2012-01-20 16:06:22.201-0600 The issue ASTERISK-17929 seems to be solved. I've tested the newest trunk. The no BYE  problem still occurs. By: Matt Jordan (mjordan) 2012-03-06 17:13:53.107-0600 jamicque: are the SIP peers using directmedia=yes? By: Maciej Krajewski (jamicque) 2012-03-06 17:23:46.138-0600 directmedia is set no By: Maciej Krajewski (jamicque) 2012-05-18 08:42:51.579-0500 should this be assigned to me? By: Pawel Sternal (sternalp) 2013-01-31 05:14:39.815-0600 I have a similiar scenario. A call to B, B call to Asterisk, B xfer, Asterisk receives INVITE packet with Replaces, A and Asterisk stay connected, but B holding B to Asterisk. In attached there're [^invite_replaces] with log when Asterisk received INVITE with Replaces. By: David Woolley (davidw) 2013-02-06 12:07:38.143-0600 I was originally confused because the first report appeared to be saying Asterisk is sending INVITE/Replaces, when it is actually receiving it.  This is not a simple or frequently exercised case.  In fact it was completely broken for a long time in the early 1.6s.  The sort of trace provided with the more recent report would be needed to gain any real understanding of what was happening with the first case. In the latest report, I would suggest that this line is the key: [Jan 31 10:14:01] DEBUG[17358] chan_sip.c: SIP Transfer: Not hanging up right now... Rescheduling hangup for 207af371-6a71d8ba-5c260fdb@192.168.2.55. I would guess that either it never actually got re-scheduled, or the channel got destroyed before it could be re-scheduled. Incidentally, this second case needs two calls to Asterisk.  At the moment, I would have to guess that B xfer actually means that means that B sends REFER/Replaces to A and A sends INVITE/Replaces to Asterisk. By: piero ferraresso (ferrored) 2013-12-05 08:18:10.454-0600 Any news? I verified that it still happens in the version 11.6.0. Thanks   Piero Ferraresso By: Matt Jordan (mjordan) 2013-12-05 09:10:15.152-0600 If the issue is Open and no one is working on it, then I would expect that this bug would still be a problem in the latest version of all supported branches of Asterisk. By: piero ferraresso (ferrored) 2014-01-21 04:35:49.814-0600 If could be useful, I notice that the problem doesn't appear on version 12.0.0.