Subject: [Sipping] transfer call flows

From: Jim Deverick <[email-masked]>
Date: Mon, 19 Mar 2007 15:08:40 -0400

Hello all,

I'm working on interop testing with a call transfer implementation  
using the resiprocate stack, and have discovered two different call  
flows for transfer in sipping drafts.

In a call flow where Bob calls Alice, but Alice transfers Bob to  
Carol...

sipping-cc-transfer-07 (sections 6.2 and 6.3) indicates that Alice  
puts Bob on hold and sends a REFER to him. Bob NOTIFYs Alice that he  
is trying to reach Carol, as instructed by the REFER. When the call  
to Carol completes, Bob notifies ALICE, who ends the initial call  
with a BYE.

If the transfer fails, Bob's second notification to Alice will  
indicate that, and Alice will take Bob off of hold instead of ending  
the original call.

sipping-service-examples-12 (section 2.4) does not indicate that  
Alice should put Bob on hold, and just issues the REFER directly. In  
this draft, when Bob NOTIFYs Alice that he is trying to call Carol,  
Alice acknowledges the notification and sends a BYE, before the  
transfer completes. Bob still sends a NOTIFY to Alice at the end of  
the transfer, even though the call between them has ended.

If the transfer fails, Bob is responsible for calling Alice back.

The two main differences are 1) when the original call between Alice  
and Bob is ended, and 2) who reestablishes the original call between  
Alice and Bob if the transfer fails.

Because both of these drafts are current and heavily revised, I'd  
like to hear people's opinions on the two approaches. I'm working on  
an implementation, and want to make sure that it will interoperate well.

Thanks,
Jim

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 01:12:21 -0500

Recently had long conversations about call transfer in SIP.

Both are valid flows, although I personally prefer that the referror not
disconnect until it receives the NOTIFY telling it that the transfer
succeeded, there is a school of thought that says otherwise. For
instance, if you are looking at how legacy networks perform call
transfer, when you hit that transfer button to complete the feature
activation, the call is gone. If you fat-finger the number, the referred
party gets hosed. If you want to maintain service parity, then send a
BYE immediately.

If you want to do better than this, then you wait around for the NOTIFY
before hanging up. You should note that it's entirely possible that the
party being transferred may BYE down the call at any time. Perhaps it
sends a BYE when the 200 OK to the new INVITE comes in, or some other
reason. I've seen interop issues because someone only designed to one
embodiment of the call flow.

IMHO-- If you're not going to pay any attention to the NOTIFY because
you're going to send a BYE right after you get a 202 to the REFER, then
you should simply use the norefersub option from RFC-4488 and try to
suppress the entire implied subscription. You're just making busy work
for the party you're transferring.

Regards,
Brian

> -----Original Message-----
> From: Jim Deverick [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 2:09 PM
> To: [email-masked]
> Subject: [Sipping] transfer call flows
> 
> Hello all,
> 
> I'm working on interop testing with a call transfer 
> implementation using the resiprocate stack, and have 
> discovered two different call flows for transfer in sipping drafts.
> 
> In a call flow where Bob calls Alice, but Alice transfers Bob 
> to Carol...
> 
> sipping-cc-transfer-07 (sections 6.2 and 6.3) indicates that 
> Alice puts Bob on hold and sends a REFER to him. Bob NOTIFYs 
> Alice that he is trying to reach Carol, as instructed by the 
> REFER. When the call to Carol completes, Bob notifies ALICE, 
> who ends the initial call with a BYE.
> 
> If the transfer fails, Bob's second notification to Alice 
> will indicate that, and Alice will take Bob off of hold 
> instead of ending the original call.
> 
> sipping-service-examples-12 (section 2.4) does not indicate 
> that Alice should put Bob on hold, and just issues the REFER 
> directly. In this draft, when Bob NOTIFYs Alice that he is 
> trying to call Carol, Alice acknowledges the notification and 
> sends a BYE, before the transfer completes. Bob still sends a 
> NOTIFY to Alice at the end of the transfer, even though the 
> call between them has ended.
> 
> The two main differences are 1) when the original call 
> between Alice and Bob is ended, and 2) who reestablishes the 
> original call between Alice and Bob if the transfer fails.
> 
> Because both of these drafts are current and heavily revised, 
> I'd like to hear people's opinions on the two approaches. I'm 
> working on an implementation, and want to make sure that it 
> will interoperate well.
> 
> Thanks,
> Jim
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: [email-masked]
Date: Tue, 27 Mar 2007 14:27:20 -0500

From: Jim Deverick <[email-masked]>

We've found that this is very obnoxious.  As someone said, it's much
like tradtitional PBXs, in that if you attempt to transfer someone to
a non-existent extension, the call is dropped.  But unlike traditional
PBXs, in a SIP system, if the transfer target extension is *busy*, the
call is also dropped.  In a traditional PBX, the transfer attempt is
rejected immediately if the transfer target is busy.

I'd say that good rules for blind transfer are:

- Implement in-dialog REFER correctly.

- Execute a blind transfer by sending a REFER, then waiting for either
  a BYE from the transferee or a NOTIFY containing a 2xx response from
  the transfer attempt (at which point, send BYE).  If you receive a
  NOTIFY with a failure response, take the call off-hold (if you put
  it on hold) and make it the current call in the UI again.

- When executing an in-dialog REFER, if you get a success response to
  the new dialog, send a BYE on the old dialog, and make the new
  dialog the current call in the UI (if the old dialog was).  If you
  get a failure response, resume the old dialog (including taking it
  off hold if you put it on hold).

Dale