[SIPForum-discussion] Blind transfer using REFER

[Stephen James]

In terms of SIP the refer transaction completes when the final response (202 is 
received). 

The endpoint should accept the BYE and terminate the INVITE dialog and the 
underlying subscription.

Stephen

 
Stephen James 
sjames_1958 at yahoo.com
 
We are not princes of the earth, we are the descendants of worms, and any 
nobility must be earned.





________________________________
From: "Nenni Jr, Mark" <MNenni at allworx.com>
To: Michael Trank <michael_trank2001 at yahoo.com>; "discussion at sipforum.org" 
<discussion at sipforum.org>
Sent: Tue, May 29, 2012 7:12:21 PM
Subject: Re: [SIPForum-discussion] Blind transfer using REFER


The REFER transaction is not complete until the next call is set up (INVITE 
after REFER to the referred call ID).  If you hang up the existing call with a 
BYE before the new call is set up then the original call no longer exists.  
Therefore there is no call to REFER to the new URI and call ID.
 
 
From:discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On 
Behalf Of Michael Trank
Sent: Friday, May 25, 2012 5:28 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Blind transfer using REFER
 
Friends:

Please help me resolve an interoperability dispute. The SIP flow chart 
below shows the series of SIP messages  between my server ("ME") and 
another vendor's server ("THEM").

They are calling my server, and connecting and some seconds later, my side
sends back a REFER, with a new SIP URI that the calling party should call.

This is meant to be an "unattended" or "blind" transfer. The stack software 
that I am working with waits until a 180 message comes in, and then 
immediately sends a BYE. I believe this to be correct according to RFC3515, 
and this flow works with many other vendors' devices. However, as you can see,
there is an anomaly at the end.... the THEM side sends back a 481 in 
response to the BYE.  They also tell me that the new call launched by the 
calling party in response to the REFER message is terminated as soon as 
the callee answers, and they say it's because of the BYE.

ME             THEM
_____________________

 <--------  INVITE
 100 Trying ----->
 180 Ringing ---->
 200 OK   ------->

 <----- RTP ----->

 REFER ---------->
 <--- 202 Accepted

 <--- NOTIFY w/180
 200 OK --------->

 BYE  ----------->
 <---- 481 Does Not Exist


The support people for the "THEM" device claim that the new call is being
lost because we are sending the BYE too soon. In my discussion with the support
people from the other side, I received the following note, which is referring 
to the ME side:


QUOTE:
A cursory reading of RFC 5589 shows that the device's behavior is incorrect.
The relevant section is 6. Basic Transfer. Here's the most part where
they're broken:

>From RFC 5589:
'If the Transferor's agent does not wish to participate in the remainder of
the REFER process and has no intention of assisting with recovery from
transfer failure, it could emit a BYE to the Transferee as soon as the REFER
transaction completes. This flow is sometimes known as "unattended transfer"
or "blind transfer".'

The key part is that the Transferor emits a BYE as soon as the REFER
transaction completes.
In this case, the device is emitting the BYE before the REFER transaction
completes. The completion of the REFER transaction is indicated by receiving
a final response in a NOTIFY packet. The "180 Ringing" response received in
the first NOTIFY packet is not a final response and should not be cause for
the device to emit a BYE. The BYE should come after the second NOTIFY packet
which carries a "200 OK" response indicating that the REFER transaction has
completed.

END QUOTE

This RFC 5589 has some new stuff about call transfers using REFER, but also 
seems to 

restate most of what is in RFC3515 with regard to using REFER for call transfers
in the INVITE dialog. 

So this guy is saying that my side needs to wait for all of the NOTIFY's in the 
subscription dialog to finish with a 2XX or better response before I send the 
BYE
message. 

That's not right, is it? 

In my mind the REFER "transaction" is complete when the 202 Accepted is received
on my side (not after the NOTIFYs stop arriving), and I am free to send the BYE, 

thereby making a "blind" transfer, rather  than an "attended" one, which is what 

I would be doing if I wait for the NOTIFY with  a 200 OK final response.

Right?

I would appreciate comments on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120529/2d47c454/attachment-0002.html>