Summary:	ASTERISK-15145: SIP REFER initiated from the Asterisk Transfer application fails on a SOPHO iS3000 SIP Server
Reporter:	James Taylor (jamestaylor)	Labels:
Date Opened:	2009-11-16 12:35:37.000-0600	Date Closed:	2011-07-26 14:31:44
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) Asterisk_debug_log ( 1) eyebeam_SIP_trace
Description:	A SIP Extension configured on the SOPHO iS3000 SIP Server supports SIP REFER. This has been proved by carrying out a blind transfer using Eyebeam (see attached SIP trace). When the same was attempted using the Asterisk Transfer application the iS3000 SIP Server responded with 503 Service Unavailable (see Asterisk attached debug SIP trace). The only difference that can be seen between the two traces is that Eyebeam performs a re-invite (a=sendonly) before issuing the refer, which is when the call is placed on hold. It is believed that the SOPHO iS3000 is also expecting a re-invite before receiving REFER. ****** ADDITIONAL INFORMATION ****** Both tests involved registering Eyebeam / Asterisk with the iS3000 SIP Server, making a call to this SIP Extension, answering the call, transferring the call. Asterisk dialplan was configured as follows: exten => 5555,1,Answer() exten => 5555,n,Wait(5) exten => 5555,n,Transfer(SIP/5566@10.0.1.10) exten => 5555,n,Wait(60) 5555 the number of the SIP extension. 07711223344 is the CLI of an incoming call. 5566 the number that the call is transferred to. 10.0.1.10 is the iS3000 SIP Server. This Asterisk version is a patched version of Asterisk 1.6.1.0. We cannot test a clean, newer version of Asterisk because the system is an operational system on a customer’s site.
Comments:	By: David Woolley (davidw) 2010-01-12 11:50:47.000-0600 We got it to accept blind transfers by forcing Asterisk to negotiate outgoing sendonly status (Philips is fussy and will not accept inactive) immediately before doing the transfer, and backing it out if the transfer failed.  This was done in conjunction with some rationalisations to the way that hold signalling in the other direction worked. However, we also wanted to do supervised transfers, for which we have prototype extensions to Transfer, which take the replaced channel as a second parameter.  As the Philips only accepts transfers on what it considers to be extensions, so needs the enquiry to be on the same "extension", we needed to hold during the enquiry, so we made CONTROL_HOLD and UNHOLD actually renegotiate the SDP direction attribute.  Whilst I believe this is what should have been happening anyway (MOH should be associated with outgoing a=sendonly) and it results in suitable phones (Polycom) actually showing a held status during MOH, it is far from a general solution, because there are lots of places where MOH is manipulated without using the CONTROL messages, and because the status really should change to reflect the new partner, during a bridging. Further, Philips specific information: - the Philips seems to generate NOTIFY OK immediately in response to a bad transfer, and then tries to re-present the call, as a new call; - the Philips seems to ignore the Replaces clause on the the Refer-To and, instead, deduces that it is dealing with an attended transfer by noting the existence of the second leg on the same "extension"; - the Philips has a refractory period after re-invites that changes the SDP direction attributes, in which it silently discards further re-invites, leading to an exponential back off and some quite long delays before the hold state can be changed.  This is of the order of five seconds. The last issue may lead us to violating some of the layering in the handling of holds, in order to avoid a hold, unhold, hold sequence. I hope, eventually, to be able to provide some of our patches in this area, although I need to wait for them to stabilise, and also to decompose them into fixes and new features, and to forward port the new features. By: Leif Madsen (lmadsen) 2011-07-26 14:31:38.786-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!