On 9/12/11 12:03 PM, Francis Joanis wrote:
> Hi,
>
> Apologies if this has been answered before...
>
> I have a question about when the BYE between the Transferor and the
> Transferee is sent in the case of an unattended transfer.
>
> RFC 5589 says in Section 6 that "[the transferor] could emit a BYE to
> the Transferee as soon as the REFER transaction completes". In Figure
> 1, it is shown that the BYE is sent after the processing of the NOTIFY
> (SipFrag 200 OK).
>
> I assume that this is the current best practice but I have also
> noticed that the unattended transfer diagram shown on tech-invite.com
> (http://www.tech-invite.com/Ti-sip-service-04.html) shows the BYE
> being sent after the processing of the NOTIFY (SipFrag 100 Trying), so
> before the end of the REFER transaction.
>
> When implementing a UA that needs to act as the Transferee (i.e.
> receive the REFER), would it be safe to assume that the BYE can only
> be received once the new INVITE transaction (to the transfer target)
> has been completed (i.e. after the 200/ACK), or should the UA also
> support receiving the BYE before receiving the final response for the
> INVITE (like shown in
> http://www.tech-invite.com/Ti-sip-service-04.html)?
You can do this in a variety of ways, as you wish:
- when you get the 200 to the REFER
- when you get *some* NOTIFY as a result of the REFER
- when you get a NOTIFY that indicates the success of the resulting INVITE
- when you get the NOTIFY indicating termination of the subscription
The main concern is that you not send the BYE too soon, and so about the
call without there being a replacement. For that, *either* a 200 to the
REFER or a NOTIFY, whichever comes first, is probably sufficient.
Beyond that, it depends if you have any logic to recover if the REFER
fails. If not, then the above is probably fine. If you can recover in
some way, then you might want to wait till you can verify that the REFER
resulted in a successful INVITE, and otherwise keep the call and do the
recovery. (Just displaying that the tranfer failed might be useful.)
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
