Summary:	ASTERISK-19488: Rejected supervised transfer hangs up on calling party
Reporter:	David Cunningham (dcunningham)	Labels:
Date Opened:	2012-03-05 22:56:19.000-0600	Date Closed:	2012-03-13 07:15:17
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/PBX
Versions:	1.8.9.2	Frequency of Occurrence	Frequent
Related Issues:	is related to ASTERISK-19442 unaccepted attend transfer hangup caller
Environment:	CentOS release 5.6 (Final)	Attachments:	( 0) trace.txt ( 1) trace-19488.pcap
Description:	The caller Party A (x1234201) calls party B (x1234202) and establishes call. Party B performs a supervised transfer to Party C (x1234513). Party C (x1234513) hangs up because he does not want to speak to Party A (x1234201) which causes the call between Party A and B (x1234202 and 1234201) to disconnect which is not as expected. In the Asterisk trace I will attach, I notice the following error from immediately after the call to party C hanging up: [Mar  5 18:07:05] ERROR[14569]: utils.c:1164 ast_carefulwrite: write() returned error: Broken pipe Can you please advise why the call from A drops? Thank you.
Comments:	By: David Woolley (davidw) 2012-03-06 04:58:13.884-0600 As I don't want to trawl through a long trace to find the answer, is this a features.conf transfer or a SIP REFERS/Replaces ones? The warning message indicates a coding error in the AGI script (or possibly an AMI one).  Typically it means that you either didn't logout, or you didn't wait for the response to the logout.  Both of these cases are cosmetic. By: David Cunningham (dcunningham) 2012-03-06 05:15:33.296-0600 It is a SIP REFER transfer, although the REFER doesn't actually happen since party C hung up the call. The error I pointed out may be unrelated to the actual problem reported - I just mentioned it as I'm not sure. Thanks. By: David Woolley (davidw) 2012-03-07 04:46:13.315-0600 Asterisk has no way of knowing that the enquiry call is part of a transfer, or even related to the incoming call, until it receives the REFER.  This appears to be an issue with the Yealink.  Basically, when Asterisk has forwarded the clear on the enquiry call, the Yealink, has initiated a clear on the incoming call. By: David Cunningham (dcunningham) 2012-03-07 04:59:06.887-0600 I'm not sure which Yealink you're referring to? Surely if the party being transferred to (C) hangs up, the original parties (A and B) should be reconnected? By: David Woolley (davidw) 2012-03-08 04:39:58.574-0600 For a SIP transfer, this is the responsibility of the transferring device, not the PABX. At no point in the call in question does Asterisk know that the user is intending a transfer. For a SIP attended transfer, the transferror sets up a completely new call for the enquiry.  Although it would normally contain the same domain-name/address in the From header as the To (From) header of the original call, there is no requirement for that, and having the same domain can happen for reasons other than an enquiry.  Normally it would also hold the original call, but there is no fundamental requirement for this. If the call is completed, the transferror's device sends REFERS/Replaces on one of the two calls, telling the other end of that call to do an INVITE/Replaces to the remote end of the other call.  (In practice, with a back to back user agent, there is no physical INVITE/Replaces.)  If the enquiry call fails or is abandoned, one would expect the transferring device to continue with the original call, unholding it if it had put it on hold. Until they are associated by the REFERS/Replaces, these are two complately separate calls from the point of view of Asterisk. By: David Cunningham (dcunningham) 2012-03-08 07:15:09.242-0600 Thanks, but I do understand how the SIP transfer works and don't think that's the issue here. The issue is that after party C hangs up Asterisk is dropping the first call. I agree they are completely separate calls at that point, so why is Asterisk dropping the first one? It's not the user that's requesting the call first call drop - it's Asterisk. By: Mark Petersen (roadkill) 2012-03-08 14:10:43.305-0600 can you provide a pcap of the call, as it will more clearly show who is hanging up By: David Woolley (davidw) 2012-03-09 04:47:50.532-0600 There aren't enough legs for that to be a SIP attended transfer, although the RTP has been stripped, so I can't check for the digits for a features transfer. Specifically it missing the enquiry leg outgoing from the transferror.  It has Party A -> Asterisk; Asterisk -> Party B; Asterisk -> Party C. By: David Cunningham (dcunningham) 2012-03-11 16:37:45.714-0500 Sorry, my mistake. It is a features.conf transfer. By: David Cunningham (dcunningham) 2012-03-13 07:15:17.432-0500 Customer advised this is no longer an issue after a restart. Thanks for your help. By: David Cunningham (dcunningham) 2012-06-11 17:06:57.098-0500 Hello, Regarding the comment: "The warning message indicates a coding error in the AGI script (or possibly an AMI one). Typically it means that you either didn't logout, or you didn't wait for the response to the logout. Both of these cases are cosmetic." AGI doesn't have the concept of "logging out". After all, it's Asterisk that connects to the FastAGI, not the FastAGI to Asterisk. So what exactly does this mean? We are seeing a lot of these errors. By: David Woolley (davidw) 2012-06-12 06:13:44.261-0500 That's really a support request.  For AGI, it means that you didn't read all the responses before closing the socket. By: David Cunningham (dcunningham) 2012-06-14 02:51:29.078-0500 In the trace that was attached before you can see: <SIP/product-local-000051a8>AGI Tx >> HANGUP <SIP/product-local-000051a8>AGI Tx >> HANGUP [Mar  5 18:05:55] ERROR[14365]: utils.c:1164 ast_carefulwrite: write() returned error: Broken pipe From testing, it appears the "Broken pipe" error is due to the second HANGUP not being read by the AGI. The question is, why does Asterisk send two HANGUP messages? Thanks for your help. By: David Cunningham (dcunningham) 2012-06-26 02:50:41.081-0500 Would someone have a reply please?