[SIPForum-discussion] Blind transfer using REFER

[Nenni Jr, Mark]

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/447b50d3/attachment-0002.html>