Gonzalo, > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@xxxxxxxxxxxx] > Sent: 12 March 2009 12:58 > To: Elwell, John > Cc: sipping@xxxxxxxx > Subject: Re: > I-DAction:draft-loreto-sipping-context-id-requirements-02.txt > > Hi John, > > yes, we have had this discussion a few times already. On one > side there > are people that think that most terminals will implement 3pcc > and that > 3pcc would resolve everything. On the other side there are > people that > think that most terminals will not implement 3pcc (how many terminals > support it nowadays anyway?) and that a simpler mechanism > such a header > field would achieve a much wider deployment, even if it > requires support > from both the caller and the callee. > > Note that 3pcc do not address the cases where the original terminal > (i.e., the controller) leave the session because in 3pcc the session > cannot continue without the controller. [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). > > Regarding what is better, a complicated mechanism that can be > deployed > without support from the remote user agent or a simpler > mechanism that > requires support from all user agents, it depends on the deployment > scenario. In scenarios where there are enough incentives for > parties to > implement the mechanism, the latter option may be a good choice. Note > that every time we define a new header field in SIP we are using the > second option. [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. John > > Cheers, > > Gonzalo > > > Elwell, John wrote: > > I still don't buy the media session correlation part of > this in section > > 2. > > > > In 2.1, the statement "Two SIP dialogs will be established: > one between > > the desk phone and > > Bob's UA and one between the soft client and Bob's UA." is of > > concern. > > There is nothing in the prior description of the use case > to say that > > there must be two SIP dialogs. > > > > In 2.2, the statement "A SIP dialog between Bob's IP-TV device and > > Laura's UA needs to be > > established." is of concern. > > It does not necessarily follow from the prior description of the use > > case that a separate dialog needs to be established. > > > > In 2.3, the statement "A SIP dialog between Bob's PC and Laura's > > multimedia phone needs to > > be established." is of concern. > > It does not necessarily follow from the prior description of the use > > case that a separate dialog needs to be established. > > > > In 2.4, the statement "That is, Bob wants Laura to treat > both streams > > as if both had been established using a single SIP dialog." is of > > concern. > > There is nothing in the prior description of the use case > to state that > > it is not a single SIP dialog. > > > > In 2.5, the statement "A SIP dialog between Bob's webcam > > phone at this summer cottage and Laura's multimedia > phone needs to be > > established." is of concern. > > This does not necessarily follow from the prior description > of the use > > case. > > > > In 2.6, the statement "Two SIP dialogs need to be established: > > one between Bob's UA and Laura's desk phone and one > between Bob's UA > > and Laura's multimedia phone." is of concern. > > This does not follow from the prior description of the use case. > > > > Consequently I am not convinced that "REQ1 It must be possible to > > correlate an already existing dialog or > > dialogs with a new dialog or dialogs as relating to > the same media > > session." > > is requirement we need to address. > > > > I agree that handling different media within a session on different > > devices on the calling side and/or the called side is an interesting > > scenario. However, I believe one of the requirements is as follows: > > "REQx: It must be possible for a user participating in a multi-media > > session to use different devices for different media, > without requiring > > any special support at the peer UA, other than the need to support > > different remote IP addresses for different media." > > > > Otherwise users want to use different devices in this way would be > > dependent on special support at peer multimedia devices. > > > > John > > > > > > > > > > > >> -----Original Message----- > >> From: i-d-announce-bounces@xxxxxxxx > >> [mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of > >> Internet-Drafts@xxxxxxxx > >> Sent: 06 March 2009 07:15 > >> To: i-d-announce@xxxxxxxx > >> Subject: I-D > >> Action:draft-loreto-sipping-context-id-requirements-02.txt > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> Title : Requirements for Dialog Correlation > >> in the Session Initiation Protocol (SIP) > >> Author(s) : G. Camarillo, S. Loreto > >> Filename : > >> draft-loreto-sipping-context-id-requirements-02.txt > >> Pages : 10 > >> Date : 2009-03-05 > >> > >> This document justifies the need and lists the requirements for > >> correlating SIP (Session Initiation Protocol) dialogs. The > >> correlated dialogs may or may not be related to the same multimedia > >> session. Being able to logically correlate multiple SIP dialogs is > >> useful for applications that, for different reasons, need to > >> establish several SIP dialogs to provide a given service. The > >> logical correlation of two SIP dialogs is also useful, for > instance, > >> to correlate an incoming with an outgoing dialog at a B2BUA. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-loreto-sipping-conte > >> xt-id-requirements-02.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > > _______________________________________________ > > 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 > > > > _______________________________________________ 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
