[asterisk-bugs] [Asterisk 0016254]: SIP REFER initiated from the Asterisk Transfer application fails on a SOPHO iS3000 SIP Server

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16254 
====================================================================== 
Reported By:                jamestaylor
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16254
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           Older 1.6.1 - please test a newer version 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-11-16 12:35 CST
Last Modified:              2010-01-12 11:50 CST
====================================================================== 
Summary:                    SIP REFER initiated from the Asterisk Transfer
application fails on a SOPHO iS3000 SIP Server
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0116527) davidw (reporter) - 2010-01-12 11:50
 https://issues.asterisk.org/view.php?id=16254#c116527 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-12 11:50 davidw         Note Added: 0116527                          
======================================================================