Summary:	ASTERISK-16912: Attended transfer failure
Reporter:	Karsten Wemheuer (kwemheuer)	Labels:
Date Opened:	2010-11-04 13:57:55	Date Closed:
Priority:	Major	Regression?	No
Status:	Open/New	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) issue-18254_directmedia.txt ( 1) issue-18254_nodirectmedia.txt ( 2) issue-att-transfer.log
Description:	I set up an asterisk system (1.8 SVN revision 293886 checked out today) and do some testing in a SIP only environment. With three phones doing attended transfer I have some weird behaviour. phone1 calls phone2, phone2 sets call on hold and calls phone3. Then phone2 is doing an attended transfer. With Snom phones there seems to be no problem. With aastra phones the call is terminated on one side only. In the described scenario phone3 seems to be connected, whereas phone1 is idle (see issue-att-transfer.log). From Asterisk's point of view both legs are terminated. It doesn't matter, who is doing the transfer. If the original call (in the above senario phone1) is doing the transfer, there is also one party hung up while the other seems to be connected (on the phone side). This might be related to ASTERISK-16847, but the behaviour is different, so I make up a new ticket. The workaround fix from ASTERISK-16847 doesn't work (the logfile attached is from an original svn checkout, no patches applied).
Comments:	By: Stefan Schmidt (schmidts) 2010-11-19 13:07:38.000-0600 what i see in the log is that directmedia in used so rtp data from phone A to phone B doesnt pass asterisk. Maybe thats why there is something strange going on. Please try to turn of directmedia and tell us what happens. thanks! Stefan By: Karsten Wemheuer (kwemheuer) 2010-11-22 04:11:26.000-0600 I updated my installation to current svn and do some testing. phone1 dials extension 150 (phone2). phone2 tries an attended transfer to extension 180 (phone3). In file "issue-18254_nodirectmedia.txt" you can see debug output of the test with "directmedia=no". All is working correctly. In file "issue-18254_directmedia.txt" you can see debug output of the same test with directmedia=yes". After transfer the connection is dropped. By: Henning Holtschneider (hehol) 2011-01-12 05:31:16.000-0600 I can confirm the behaviour using both Asterisk 1.8.1.1 and SVN trunk revision 301403. The problem does not occur with directmedia=no. All other directmedia settings result in the behaviour described by kwemheuer. By: Alvaro Ivan Parres Peredo (arabe) 2011-04-04 14:10:26 THe behaviour continues on Asterisk 1.8.3.2 with directmedia=yes By: Henning Holtschneider (hehol) 2011-06-24 14:22:47.419-0500 I had another look at the problem and I'm not so sure that this is actually an Asterisk problem. I can reproduce the problem with Aastra firmware 3.2.0 and 3.2.1. Looking at a SIP PCAP trace of the conversation between Asterisk and the phone, I noticed that the phone responds with a 500 Internal Server Error to the final re-INVITE from Asterisk. If I change the sendrpid=pai to sendrpid=yes, there is no 500 Internal Server error. Of course, the phone will not display the contents of the Remote-Party-ID header, but the change indicates that the rest of the SIP packet sent by Asterisk is acceptable to the phone. By: Matt Jordan (mjordan) 2012-09-05 08:42:41.974-0500 I agree with Henning. If the phone sends back a 500 Internal Server Error when we send it a re-INVITE, then Asterisk is behaving correctly by tearing the call down.  The fact that the phones are apparently not handling the Remote-Party-ID header correctly is a function of the phone firmware, and not Asterisk. I'm going to go ahead and close this out as 'not a bug'.  If you'd like this issue reopened, please contact a bug marshal in #asterisk-bugs.  Thanks! By: Matt Jordan (mjordan) 2012-09-05 10:25:27.434-0500 Update from Karsten: "I contacted vendor Aastra a few days ago, and they told me, that the phone behaves correctly. They found out, that asterisk is sending two re-invites in a short time frame and without waiting for an response of the phone. According to RFCs the phone can respond with "500" and a "Retry Later"-Header. So I think, asterisk should wait with the second re-invite or should act upon the 500 with "retry later" in a way, that not terminates the call. If You take a look at attachment "issue-18254_directmedia.txt", You'll see in line 4364 the first INVITE sent to 192.168.10.202. In line 4456 there is the second INVITE sent to the same phone. There are no responses from the phone in between. In line 4935 the 500 Error is received by asterisk." By: Henning Holtschneider (hehol) 2012-09-05 12:16:37.157-0500 RFC 3261 says that you have to wait for an INVITE message to be confirmed by the SIP UA before you may send another INVITE within the same dialog. The way I understand chan_sip's state machine, this would not be trivial to achieve. chan_sip lacks a way to properly track the responses to the INVITE messages once the channel is in an established state. I'm not sure if Asterisk would be allowed to reject the fatal 500 error with a retry later header. Aastra is right in saying that Asterisk is doing something wrong and their phone behaves correctly. However, this does not explain why the phone only responds with the 500 error if a P-Asserted-Identity header is present. The phone seems to be less strict about non-ACK'ed INVITE messages under certain conditions. By: Karsten Wemheuer (kwemheuer) 2012-09-05 12:51:57.892-0500 The phones do not respond differently to certain conditions. The only condition where asterisk is sending two Re-Invites directly after each other is the situation with sendrpid=pai and directmedia=yes. If You disable directmedia there is only one Re-INVITE. If You use directmedia=yes and disable sendrpid there is also only one Re-INVITE. There is no problem with the phones, if there is only on Re-INVITE. Another remark from aastra: If You use directrtpsetup=yes instead of directmedia=yes and set sendrpid=pai all is fine. In this situation there is also only one Re-INVITE. By: Karsten Wemheuer (kwemheuer) 2012-09-06 08:03:21.492-0500 As a customer told me, it seems that gigaset phones do have the same problem. I have a short look at a network capture showing exactly the same: asterisk sends two Re-INVITEs and the phone sends 500 Server error with "Retry later" Header. By: Sascha Daniels (sascha.daniels) 2013-04-17 04:56:03.450-0500 Is there any work in progress? The Problem still exists in 1.8.21.0 By: Matthew Hooton (ftnit) 2013-05-02 14:05:27.450-0500 Running 11.3 I experience call drops on blind and attended transfer in this same fashion as well. By: Matt Jordan (mjordan) 2013-05-02 16:38:07.962-0500 This issue is still in the "Open" state, and has not yet been worked. There are no issues linked with this one, nor are there any duplicates of this issue that are known of in the issue tracker. Hence, it is not expected that the behavior of Asterisk will have changed. Adding the equivalent of "+1" doesn't help. As time and developer resources become available, the issue will be worked. As an aside, issues with patches tend to get addressed much faster than issues without patches.