[SIPForum-discussion] Blind transfer using REFER

[Stephen James]

The subscription is within terms of the INVITE dialog. The REFER transaction ends with the final 202 response. You have three elements at work here, the INVITE dialog, the REFER transaction and the implicit subscription. Only the REFER transaction ends with the 202. This is basic 3261 behavior. This is why the implicit subscription is required as there is no context within which to communicate the transfer once the REFER transaction ends. 

Sent from my iPad

On Aug 3, 2012, at 4:31 AM, mehmet <eng.mehmetozi at gmail.com> wrote:

> Hi,
> 
> I could not find the related sentence about sip refer transaction ends
> after 202 response.
> Could you please send me that sentence, because I know that refer
> creates implicit subscription and this is written in RFC docs.
> 
> Regards
> Mehmet
> 
> 2012/5/30 Stephen James <sjames_1958 at yahoo.com>:
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> 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
>>