> -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@xxxxxxxxxxxx] > Sent: 12 March 2009 13:33 > To: Elwell, John > Cc: sipping@xxxxxxxx > Subject: Re: > I-DAction:draft-loreto-sipping-context-id-requirements-02.txt > > 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] Most devices support transfer anyway, so it is a case of adding 3PCC support. Yes, that is non-trivial. But also adding support at a multi-media terminal for interworking with remote users where media are spread across 2 terminals is also non-trivial, and will multi-media terminal vendors be motivated to do this? > > > [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. [JRE] I don't want to block any work on exploring the solution space for the general problem, which is for a user participating in a multi-media session to use different devices for different media. However, I would like the requirements expressed in a way that does not limit the solution space unnecessarily. John > > 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
