On Tue, Aug 17, 2010 at 4:10 PM, Paul Kyzivat <pkyzi...@cisco.com> wrote: > > > M. Ranganathan wrote: >> >> On Tue, Aug 17, 2010 at 9:50 AM, Paul Kyzivat <pkyzi...@cisco.com> wrote: >>> >>> M. Ranganathan wrote: >>>> >>>> Hello, >>>> >>>> I am implementing a B2BUA ITSP bridge that bridges a PBX with an ITSP. >>>> In one of the call flows, I get a REFER from the PBX which I have to >>>> convert to an INVITE. The INVITE could take a long time to return OK ( >>>> human in the loop ) or it could fail if there is a processing error. I >>>> need to delay returning 202 or DECLINED to REFER until I know the >>>> outcome of the INVITE. To keep the REFER client transaction alive, I >>>> propose to send 100 responses periodically. I assume that would keep >>>> the REFER client transaction in PROCEEDING state. >>>> >>>> What would be a recommended frequency? >>> >>> You must not use provisional responses for non-INVITE transactions. (See >>> RFC >>> 4320). >>> >>> The response to REFER is not supposed to be delayed until the resulting >>> action is complete. It should be sent as soon as you have decided to >>> accept >>> the refer. >>> >>> The outcome of the resulting INVITE is reported via NOTIFY to the >>> implicit >>> subscription that results from the REFER. >>> >>> Thanks, >>> Paul >>> >> >> The problem is that the entity sending the 202 is a B2BUA (not a UA). >> So if it blindly sends 202 it has no notion of what the transfer >> target will do at that point, the transfer controller assumes the >> transfer is done and cannot recover the transferee. The effect we want >> is for the transfer controller to roll back to the transferee if the >> transfer fails. >> >> How does one deal with that? > > Is the B2BUA forwarding the REFER to the transfer target?
No. > Or is it carrying out the REFER itself, using 3pcc, by sending a new INVITE > to the Refer-To, and then splicing things together? (I gather so.) Correct > > If so, then I presume its the invite to the Refer-To URL that will take a > long time. That is the same as might be the case if there were no B2BUA and > you just sent a REFER to a peer UA. > > This really is what the implicit subscription and its NOTIFYs are for. You > can send NOTIFY messages indicating the progress of the INVITE. And if it > fails, you notify about that too. Then the Refering UA can take the call > back. (Actually it had the call all the time. It just then forgets about > sending BYE and goes back to interacting with it.) Phones seem to be bad at handling that. (at least in the consultative transfer case).Very clunky call recovery. I found that delaying sending REFER 202 until the transfer target picks up is a smoother user experience (at least for Polycomm phones). Of course this is nothing to do with the protocol operation and much more to do with the way the phone behaves. This could aso be different for different phones. There is another problem here. Phones ( polycomm phones in particular ) are set up so you can hit the transfer button on a consultative transfer even before the potential transfer target answers (the infamous "consultative transfer turned blind" case). This is very annoying for a B2BUA because the transfer target dialog is in an EARLY state when the transfer is requested and hence no in-dialog requests can be sent down that path. I would like to at least trap such a condition and return REFER 603 but alas, I have no idea that the transfer agent is going to act this way until the potential transfer target has picked up the phone. INVITE has a much longer lifetime than REFER unfortunately, and hence I cannot delay sending REFER 202 ( or REFER 603) else the REFER transaction times out. In fact this is the use case that lead me to wonder if the REFER client transction could be kept alive by sending 100 responses periodically. I think the answer I am hearing is "No" Thanks for your help. Ranga > > Thanks, > Paul > > -- M. Ranganathan _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
