> -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@xxxxxxxxxxxx] > Sent: 06 March 2009 12:57 > To: Elwell, John > Cc: sipping@xxxxxxxx > Subject: Re: > I-DAction:draft-loreto-sipping-context-id-requirements-02.txt > > Hi John, > > thanks for your comments, > > Elwell, John wrote: > > <snip> > > > > 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." > > > yes, you can use 3pcc mechanism to solve all the use cases > that is a fact. > Also the session mobility draft, in section 5.4.3 "Transfer > to multiple > devices" > http://tools.ietf.org/html/draft-shacham-sipping-session-mobil > ity-05#page-22 > suggests the usage of 3pcc mechanism "/to overcame this problem/" that > "/there is currently no standard way to associate multiple > sessions as > part of a single call in SIP./" > > And yes the 3pcc hides everything you do on your side to the peer UA. > > Of course, using 3pcc make users want to use different device > "independent" from what you call "special support" > at the peer multimedia devices. > However there is the implicit requirement that the user has to have > among his device, at least one that support > 3pcc and is able to behave as controller. [JRE] Some special capabilities are required on both devices (e.g., the audio device and the video device) to get them to collaborate including, for example, sharing a common session ID. If you don't use 3PCC, you need some other mechanism. Whatever mechanism we use between the two devices, it should have minimum impact on the remote UA. > Moreover there is > an even more > strict requirement, the controller > must not leave the call for all the session time. > > so lets say you are at your office and join a call using your mobile > phone for the audio, and your computer > for the video and the messaging part. > You can do that because the SIP UA on your computer probably > support the > 3pcc, and then act as controller. > However if the call lasts too long and you have to go home, > but you want > continue to be involved in the call > only with the audio you cannot turn off your computer because > if you do > you will automatically thrown out > from the call; and if you leave the computer on, I am not > sure you will > then be able to hang up completely the > call using only your mobile phone and not the controller. [JRE] Then you should transfer the call to your mobile before leaving the office. We already have mechanisms for call transfer. The result of transfer would be that all media that the mobile can support are transferred to the mobile. If you have two dialogs, as you propose, how would you deal with such situations? For example, I am using audio on my mobile and from my mobile I want to turn off video on my PC because I no longer require it? This seems to require special communication between the two devices. John > > Otherwise users want to use different devices in this way would be > > dependent on special support at peer multimedia devices. > > > no question that you have to relay on "special support" at > the peer, and > so maybe legacy phone won't be able to support it; > but special support does not necessarily means complicate to > implement. > > regards > Sal > > 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
