Subject: Re: [Sipping] Comments on draft-loreto-sipping-context-id-requirements-00

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Jan 2009 14:08:59 +0200

Hi Paul,

thanks for you answer, as always your comments are food for thoughts.

If 3pcc is an heavy weight mechanism or not could be a long and 
controversial issue and different people will have
different opinion on it I am sure,
on the other hand I agree with you that correlation will introduce some 
extra weight as well but not
comparable with the one introduced by 3pcc mechanism at least in my 
opinion.

It is true that  "if the 3pcc mechanism is used, only the device that 
wants to exploit another device to extend its call need implement it.
Neither the subordinate device nor the other party need do anything 
special."
but is the 3pcc mechanism largely implemented and used in the existing  
UA at the present?
which probability we have that at least one device, among the ones used 
by an user, will support it?

I agree that "the burden of the correlation falls on UA that has no need 
for correlation. This also makes adoption more difficult."
but it will depend from how difficult to implement will be the solution 
that will be able to propose.
So here at least we have at least the possibility that if the solution 
won't be difficult to support, it will be largely adopt.

Having said that, I'd like to check with you what happen if the UAs are 
behind a NAT and they use ICE to check
connectivity and negotiate candidates.
To be more clear on what I mean,
let consider for example one of the use cases described in the current 
draft

  2.1.  Using Two Separate UAs to Start a Conversation

        Laura is at her office.  On her desk, she has a PC with a soft 
client
        and a desk phone.  The PC has a low-quality built-in microphone and
        is connected to high-quality speakers.

        Laura wants to establish a voice session with Bob using the desk
        phone as the microphone and the soft client as the speaker.

and consider the scenario where all the Alice different UAs are in a 
network behind a NAT.

Now if we could use a correlation mechanism, each of the Alice UAs will 
perform,
independently, its ICE negotiation with the BOB UA.

       +-------------+              |
       |  Alice      |              |
       |  UA WebCam  |              |
       |             |              |
       +-------------+              |
              |                     |
              |                     |
              |                     |
        +-------------+      +------\           +-------------+
        | Alice       |      |      |           |             |
        | UA Audio    :::::::| NAT  |:::::::::::.  BOB  UA    |
        |   +3pcc     |      |      |           |             |
        +-------------'      +------/           +-------------+
                                    |
                                    |

On the other hand, if we want to use 3ppc, as showed on the picture above,
for sure the usage of 3pcc make transparent for the Bob UA the fact that 
Alice is using
separate devices for different media,
but the Alice UA performing the 3pcc has to be involved also in the ICE 
connectivity
check for the other Alice UA (the Alice UA WebCam in the picture) and 
this fact
could complicate somehow the already not easy and light ICE negotiation 
phase.

thanks
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: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jan 2009 08:14:04 -0500

Comment at end

> independently, its ICE negotiation with the BOB UA.

I believe ICE will work just fine in the 3pcc case.

Note that the SDP passed to Bob will have two m-lines - one for each of 
Alice's devices. Because Alice has decomposed things, the Alice UA Audio 
device will do the ICE on its audio device, and its Webcam will do the 
ICE for the video. Bob's UA will do the ICE for both media. The picture 
above is not quite right, because there will be media through the NAT 
for both devices.

You ask how many UAs implement 3pcc. Maybe that is small. But its also 
true that few devices support session correlation. It will take new 
implementation to offer such a feature. Its just a matter of the most 
viable way to do it. If I were building such a device/feature, I would 
want to do it in a way that would maximize the possibility of interop 
with any device supporting the same combination of media. Only 
interoperating with devices that implement a new feature that is no 
benefit to them seems like quite a limitation.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Jan 2009 12:22:02 +0200

Hi Dale,

sorry to be late on this answer, I agree that have a clear understanding 
of the capabilities
we want for the mechanism is necessary to clearly write down the 
requirement.

In my mind I have an Idea equal on what you expressed in Req A

Req A:  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.

However, the requirements need to be discussed and agreed by all the wg
and also Req B , that is a little more restrictive  could be  from my  
point of view an acceptable compromise.

/Sal

Dale Worley wrote:
> On Fri, 2008-12-19 at 16:45 +0200, salvatore loreto wrote:
>   
>> Do you think we should be more explicit on this point?
>>     
>
> The first question is to come to a clearer understanding in our own
> minds what capabilities we want the mechanism to have.  After that, we
> can write clearly what the requirements are.
>
> In this case, the following two requirements may be quite different in
> regard to the solutions that they admit:
>
> Req A:  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.
>
> Req B:  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, may be required to have
> specified that they might be correlated with in the future.
>
> Dale
>
>
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Jan 2009 13:17:43 +0200

John,

Elwell, John wrote:
> Sal, 
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of salvatore loreto
>> Sent: 19 December 2008 15:58
>> To: Paul Kyzivat
>> Cc: SIPPING
>> Subject: Re: [Sipping] Comments 
>> ondraft-loreto-sipping-context-id-requirements-00
>>
>> Hi Paul, John and all,
>>
>> I agree that party A could use 3pcc to making transparent for party B 
>> the fact that it is using separate devices for different media, and
>> then making everything into one dialog for B;
>> however there could be situation, and indeed there are use 
>> cases where 
>> it would be preferable not using a centralized and heavy mechanism as
>> 3pcc but instead having something more distributed and lighter.
>>     
> [JRE] 3PCC would be one possibility. Non-SIP communication between the
> two devices might be another (depending on whether rendez-vous
> capability of SIP is necessary or not for this purpose).
>   
[SAL] I see that there could be non-SIP communication, however here we 
are trying to standardize
a SIP mechanism.
>   
>> About your concern on what happens if party B wants to transfer the 
>> "call", in the case where party A asked party B to establish 
>> a correlation
>> between two dialogs, my first answer is that yes it should be 
>> expected 
>> to do *two* transfer - one for each dialog, and I don't see any
>> problem in this. Of course I can be wrong in this, and 
>> probably I am, as 
>> usual.
>>     
> [JRE] I see this as a huge problem, expecting the remote endpoint to
> undertake complex procedures for something that benefits the other end.
>   
[SAL] I don see that procedures so complex to be a huge problem, but 
that is a matter of opinion
> John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Jan 2009 07:23:44 +0000

> From: Salvatore Loreto [mailto:[email-masked]] 
> Sent: 25 January 2009 11:18
> To: Elwell, John
> Cc: Paul Kyzivat; SIPPING
> Subject: Re: [Sipping] 
> Commentsondraft-loreto-sipping-context-id-requirements-00
> 
> John,
> 
> Elwell, John wrote:
> > Sal, 
> >
> >   
[JRE] We are trying to standardise a SIP mechanism to party B. That does
not necessarily limit us to SIP between the two devices of party A. For
example, MGCP or MEGACO might be suitable.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Jan 2009 09:48:15 +0000

> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: 25 January 2009 10:22
> To: Dale Worley
> Cc: SIPPING
[JRE] I don't think this is a valid requirement, because it has a
particular class of solutions in mind. In my opinion the basic
requirement should be something along the lines of "It must be possible
to establish, modify and clear down a multimedia session between two
parties, one or both of which use different devices for different
media."

John