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?
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.)
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.)
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
