[SIPForum-discussion] Blind transfer using REFER

[Michael Trank]

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 calllaunched 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/20120525/7af2d0fc/attachment-0002.html>