Subject: Re: [Sipping] I-D Action:draft-loreto-sipping-context-id-requirements-02.txt

From: "Elwell, John" <[email-masked]>
Date: Fri, 06 Mar 2009 11:20:46 +0000

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 06 March 2009 07:15
> To: [email-masked]
> 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.
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 06 Mar 2009 14:56:50 +0200

Hi John,

thanks for your comments,

Elwell, John wrote:
> <snip>
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-mobility-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. 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.
> 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
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 06 Mar 2009 15:15:44 +0000

> From: Salvatore Loreto [mailto:[email-masked]] 
> Sent: 06 March 2009 12:57
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] 
> I-DAction:draft-loreto-sipping-context-id-requirements-02.txt
> 
> Hi John,
> 
> 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 
[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

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 17:07:35 +0100

Sal,

I would like to see a second requirement for the dialog correlation,
which ensures that upgrading network elements is enough to enable dialog
correlation also for end devices which were not ungraded. E.g. "Dialog
correlation must be possible also if end devices were not upgraded."  

Regards
Laura

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 10 Mar 2009 14:42:18 +0200

Hi John,

see in line my answers

thanks
/Sal

Elwell, John wrote:
>>> session to use different devices for different media, 
>>>       
>> without requiring
>>     
[Sal] I agree on the fact the the mechanism should have a "minimum" 
impact on the remote UA.
Maybe we can say something about it in the requirements.
> This seems to require special communication between the two devices.
[Sal] that is a matter of solution.
However the required special communication
could be as simple as send a REFER triggering a BYE from your mobile to 
your PC.

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 10 Mar 2009 14:58:53 +0200

Hi Laura,

the draft already contains in the section "4.3 Common requirements" the 
following one:

   REQ3  UAs that do not implement the correlation mechanism and, thus,
      do not understand the correlation information they received should
      be able to handle the individual SIP dialogs that were supposed to
      be correlated as well as possible.  That is, the correlation
      mechanism should not keep them from trying to handle the SIP
      dialogs.

I don't know if it enough for your case, please let me know if this 
requirement fulfils yours or not.

best regards
Sal

[email-masked] wrote:
>>>> logical correlation of two SIP dialogs is also useful, for 
>>>>         
>> instance,
>>

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 10:53:53 +0100

Hi Sal,
 
What I want is that the dialog correlation method also also works
without end devices contribution (for non-compliant end devices).
Hadriel's Session-ID ( 5.5.1) fulfills this requirement.  
 
REQ3 doesn't cover this issue. 

Laura  

> Sent: Tuesday, March 10, 2009 1:59 PM
> To: Liess, Laura
> Cc: [email-masked]
> Subject: Re: [Sipping]I-D 
> >>> Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Mar 2009 13:29:54 +0200

Hi Laura,

Hadriel's Session-ID describes and propose a solution (moreover that 
draft does not have an explicit requirement similar to
the one you are proposing, it provides a solution that fulfil your 
requirement);

in the Context-Id we do not describe or propose any solution
because we want before people agree on the need of a such new mechanism 
and commit to work together to a solution.

In the Context-ID draft there is any requirement that states that the 
mechanism has to be started by a UA,
in 4.3 Common requirement we only say:

   REQ1  It must be possible, when establishing a dialog, to specify
      that it be correlated with one or more already existing dialogs,
      which dialogs, at the time they were created, did not need to
      specify that they might be correlated with in the future.

we do not mandate that it has to be done in UA, it can happen in the 
B2BUA or in a Proxy.
Then Req 3 of the same section we say that the mechanism should word 
also fo non-compliant end device:

So I think that the requirement are enough general to cover also your 
scenario

thanks
/Sal

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 12:39:10 +0100

Sal,
It's fine for me.
Laura

> Sent: Thursday, March 12, 2009 12:30 PM
> To: Liess, Laura
> Cc: [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Mar 2009 14:57:41 +0200

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.

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.

Cheers,

Gonzalo

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Mar 2009 13:23:49 +0000

Gonzalo, 

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 12 March 2009 12:58
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] 
[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).

> that every time we define a new header field in SIP we are using the 
[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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Mar 2009 15:32:41 +0200

Hi,

> 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.

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Mar 2009 13:42:07 +0000

> Sent: 12 March 2009 13:33
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] 
[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?

> excellent solution in some deployment scenarios but a poor 
[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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Mar 2009 16:31:19 +0200

Hi,

> terminal vendors be motivated to do this?

You just need to play/show both streams... the fact that they are 
handled by different dialogs is not important for the media libraries. 
In fact, some user agents use different media libraries for different 
media types even if both streams are handled by the same dialog.

> solution space unnecessarily.

As it has been pointed out, you can already do that by using 3pcc plus a 
few already existing session transfer mechanisms... it works, although 
it is complex. If we want to do something new, it will involve several 
dialogs. Otherwise, there is nothing to do.

Cheers,

Gonzalo