Hi,
[JRE] You can. You effectively do an attended transfer, e.g., send a REFER/INVITE/Replaces to the remote party, resulting an INVITE/Replaces to your other device that needs to take over the call. Certainly this requires support for REFER at the remote side, but generally that is supported (or a B2BUA will carry out the necessary functionality).
well, I hope you agree with me that adding terminal support for all this plus 3pcc is not a trivial task :o)... honestly, I do not think many terminals will support all these mechanisms.
[JRE] I fear that a 2-dialog approach will be a complicated mechanism that also requires special support from the remote UA. Perhaps when we have explored the solution space further I will be proved right or wrong. However, I would still prefer the requirements to be expressed in a form that does not imply a solution with 2 dialogs at the remote UA, together with at least a desire to minimise the impact on the remote UA.
I agree that the requirements could be phrased better. However, when it comes to the impact on the remote UA, it is a trade off, as discussed above. You can add complexity to your local terminals until you remove any impact on the remote terminal. As I indicated in my original email, different scenarios may require different resolutions for that trade off. Adding complexity to remove impacts on remote terminals may be an excellent solution in some deployment scenarios but a poor one in others.
Cheers, Gonzalo _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
