Summary:	ASTERISK-02226: [post 1.0] REFER transfer fails with certain hardware (REFER requires NOTIFY)
Reporter:	florian (florian)	Labels:
Date Opened:	2004-08-16 03:43:27	Date Closed:	2004-09-25 02:09:44
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	REFER transfer works properly with SNOM, but not with Cisco ATA186. In such cases the transfer should probably be followed by NOTIFY to close it properly. Asterisk should also be able to accept NOTIFY from other partys in this situation. ****** ADDITIONAL INFORMATION ****** REFER: http://www.faqs.org/rfcs/rfc3515.html Replaces: http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-05.txt See also: http://www.softfront.co.jp/tech/ietfdoc/org/draft-ietf-sipping-cc-transfer-02.txt (Note, this Replaces header proposal has expired!)
Comments:	By: florian (florian) 2004-08-16 03:45:04 Thanks to OEJ who helped figure this out. I will do my best to whip up a quick hack on the first part, so ATA186 can do proper transfer. More work is probably needed however. By: Olle Johansson (oej) 2004-08-16 03:54:41 We should propably make the transmit_notify function more generic than now and move the current transmit_notify to transmit_notify_mwi. I'll look into that. By: Mark Spencer (markster) 2004-08-16 09:38:12 And why is this labeled "MAJOR"? By: florian (florian) 2004-08-16 09:43:55 If my reading up RFC's is correct this issue indicates the way Asterisk does REFER is _not entirely RFC compliant_ and its behaviour may break compatibility with certain hardware. You may feel differently, ofcourse. BTW, I see other issues with the MAJOR label that I feel are more or less of the same weight. If it is not, my apologies. Feel free to moderate. By: Mark Spencer (markster) 2004-08-16 09:47:44 Eh, I'll leave it for now.  I accept that it's not RFC compliant -- although it's hard to imagine that there is any way in which this non RFC-compliance could cause a real issue. Anyway do you have a device which sends the REFER and expects the notify?  If so I can go ahead and modify the code to support it. By: florian (florian) 2004-08-16 09:47:59 Checked against the bugguidelines: - It prevents proper transfer with ATA186, where all documentation says it should work this way - I think it is a protocol violation By: Olle Johansson (oej) 2004-08-16 09:49:44 Changed severity. This requires a lot of coding and testing, so it will not be ready to include before 1.0. It is a major flaw, but not a bug that will stop 1.0 from being released. Still, not fully supporting transfer on Cisco phones is a rather problematic situation with the large user base of Cisco ATA and 79xx phones. By: florian (florian) 2004-08-16 09:52:19 Mark, yes, ATA186 SIP v3.1.0 appears to behave this way, and I have a few on my testlab. By: Mark Spencer (markster) 2004-08-16 11:06:45 I don't think it's *that* much work.  I'd give it a good shot of pre 1.0 if I can get on the system having the trouble. By: florian (florian) 2004-08-16 11:37:03 User account details mailed privately. Let me know if there is testing to be done. I will try and figure through the code myself too. By: Olle Johansson (oej) 2004-08-16 11:44:43 Let's feed Mark while he's hungry! Florian - can we write down a script based on our discussions on IRC and the documents so Mark has something to work on. I think the Cisco document was pretty good in explaining what happens. Basically, as soon as a caller requests a call to be transfered, he's sending a REFER. After that, Asterisk should send the caller updates on the transfer with SIP NOTIFY packets of type Event: refer with a body of message/sipfrag and a SIP result code in it, like "200 OK" if the transfer is accepted by the other side or "503" if cancelled.  We could also relay "180 ringing" the same way, but that's advanced mode. I think what the ATA is missing is the "200 ok" or the cancel code. By: florian (florian) 2004-08-16 15:05:38 Oej came up with this nice document from Cisco showing SIP REFER call flow http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110c01.html From the RFC I understand that returning 'NOTIFY' with sip message part '200 OK' is more or less the 'minimum requirement' By: florian (florian) 2004-08-16 15:34:14 By adding a few lines of printf() I found that with the ATA186 it doesnt seem to be considered a supervised transfer at all (line 4906). On review though, this makes sense, because there is no Replaces header :-P. However, it might make fixing the issue a bit more complex ? edited on: 08-16-04 15:25 By: florian (florian) 2004-08-16 16:43:53 Okay, so from the perspective of the middleman SIP device (the phone doing the transfer): A call B B puts A on hold to call C B speaks to C and transfers The REFER is sent with callid van first call leg (AB) replaces header gives second call leg (this one can be dropped after the transfer) (BC) The big issue with ATA186 is that, as far as I can tell from tcpdumps, it doesnt send us any indication of what the callID of BC is. We think we need to to send a NOTIFY first, to get it (or is there another way to figure it out?). The quick way to do it would be to catch this in the 'unsupervised' transfer part (lines 4946 and higher) ??? By: Mark Spencer (markster) 2004-08-17 09:24:51 NOTIFY does not retrieve it for us.  I really think this is just syntactic sugar for the uber RFC minded.  Still would be nice to add it if it's supposed to be there. By: Brian West (bkw918) 2004-08-17 09:40:20 the ata186 has never done this correctly.. My cisco 7960's work fine doing this. bkw By: florian (florian) 2004-08-17 09:44:03 BKW: But with a CCM setup they do work as expected, and I cannot find anything in the REFER docs that say they are doing it wrong. I have a growing install-base with ata186's and need to be able to support this. By: florian (florian) 2004-08-17 09:52:48 Mark: Can I get your debugging code (notify) to do more testing ? By: Mark Spencer (markster) 2004-08-17 22:31:50 Added the NOTIFY code to CVS and got a test back to confirm it works. By: florian (florian) 2004-08-18 02:33:37 Sorry Mark, I disagree: We are now dealing with REFER more cleanly, thats true. Unfortunately our ideas were not entirely correct: Just adding the NOTIFY does not make the transfer go cleanly - I am doing a documented supervised transfer, and Asterisk still thinks it is unsupervised, the call setup is incorrect as documented earlier. By: Olle Johansson (oej) 2004-08-18 02:45:11 Hmm, Mark: you're adding tmp2, that isn't initialized to anything. By: Mark Spencer (markster) 2004-08-19 09:43:56 Good eye on the tmp2 thing, that got fixed yesterday.  The REFER in the trace does not include a "replaces" header, therefore it is not, by spec, a supervised transfer, and I can't even find anything else to use even if I wanted to, so it's CERTAINLY not a bug, and could be listed as a feature ONLY if there is some spec to be provided.