[SIPForum-discussion] Blind transfer using REFER

[Santosh Iyer]

>From the quotes it is pretty clear that your server is RFC compliant by sending the BYE after the refer transaction is complete ie REFER->202. Now i guess "THEM" want the "ME" server to be a part of the REFER "process" to recover from a REFERed call failure as opposed to REFER "transaction". But again the REFER transaction consists only of the REFER and the 202. The notify are part of a different transaction

Santosh
--- On Sat, 5/26/12, Michael Trank <michael_trank2001 at yahoo.com> wrote:

From: Michael Trank <michael_trank2001 at yahoo.com>
Subject: [SIPForum-discussion] Blind transfer using REFER
To: "discussion at sipforum.org" <discussion at sipforum.org>
Date: Saturday, May 26, 2012, 2:58 AM

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 
sidesends 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 beinglost because we are sending the BYE too soon. In my discussion with the supportpeople 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.




            
-----Inline Attachment Follows-----

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120529/14cb3e6d/attachment-0002.html>