Subject: [Sipping] New draft submitted: draft-loreto-sipping-context-id-requirements-00

From: Salvatore Loreto <[email-masked]>
Date: Mon, 16 Jun 2008 17:05:22 +0300

Hi there,

I have just submitted a draft that show the needs (through 4 use cases)
and list the requirement to logically correlate an existing SIP dialog,
or even multiple SIP transaction sent outside of a dialog, with new SIP 
dialog/s.

The idea is to start a discussion within the sipping wg to design a 
mechanism like a cookie  "id"
that can be used to implement applications using multiple SIP sessions, 
even across the time.

for the time being the draft will appear on the IETF web site, you can 
find here:
http://www.sloreto.com/tmp/draft-loreto-sipping-context-id-requirements-00.txt

cheers
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: Mon, 16 Jun 2008 11:36:46 -0400

I seem to recall a proposal similar to this quite some time ago. Am I 
only imagining that?

I have a variety of concerns about this proposal:

- it seems to conflate multiple concepts
- some of its features are redundant with other mechanisms
- it may encourage behavior we have strived to discourage

Yet I do see the germ of a significant new feature in here, that I will 
describe after some comments on particular parts of the draft.

> 3.1.  Enhance messaging conversation
> 
>       Alice and Bob are two participants in a communication space
>       exchanging SIP MESSAGE methods sent outside a SIP dialog[RFC3428]:
>       The application shows the text sent and received on the screen.
> 
>       Alice later wants to add voice to the same application.

There was an extended battle about message sessions long ago. It was 
concluded that MESSAGE was not intended for message sessions, and MSRP 
was devised as an alternative for that purpose.

This use case starts out with the assumption that there is a message 
session using MESSAGE, and introducing the context-id to this will 
formalize it and give the session an identifier. This is a bad thing.

> 3.2.  Including an external UA in a conversation
> 
>       Alice establishes a voice session with Bob.
>       Alice wants to add video to the session using her SIP-enabled
>       camera.
> 
>       Alice sends a REFER to her camera, which has a SIP user agent on
>       it, so that her camera sends an INVITE request to Bob in order to
>       establish a video stream.
> 
>       Alice wants Bob to treat the video stream from her camera and the
>       voice stream from her voice-only user agent as part of the same
>       communication space.  That is, Alice wants Bob to treat both
>       streams as if both had been established using a single SIP dialog.

I recognize this use case from somewhere. I could swear it has been 
discussed before, though perhaps only in email rather than in a draft.

The Join header works perfectly for this use case - it does *exactly* 
the right thing. Adding a new mechanism to do this differently is IMO a 
mistake.

> 3.3.  Correlate the new conversation with a previous one
> 
>       Alice and Bob are in communication with each other using SIP
>       MESSAGE [RFC3428] methods sent outside a SIP dialog or MSRP
>       Sessions [RFC4975].
> 
>       Alice left the conversation and close down the messaging
>       application.
> 
>       After a while Alice wants to continue the conversation she was
>       previously having with Bob. Alice wants Bob to treat the new
>       conversation as a continuation of the previous one.  That is,
>       Alice wants Bob to show the new messages below the ones they have
>       previously exchanged.

(Ignoring MESSAGE, and assuming the earlier session used MSRP...)

This seems to imply a different notion of session than the earlier 
cases, and than anything I have seen mentioned with sip. This is a 
memory of *past* sessions after they have completed. In this particular 
use case it also implies a class of data that is expected to be retained 
for such a session - a log of the conversation held during that session.

This is something new. It could be an important new capability. 
(Certainly maintaining call logs and logs of IM sessions is common and 
desired functionality.) But for it to be so it will need to be specified 
much more fully, in terms of the data that is expected to be retained, 
where that data should be retained, how it should be accessed, and what 
the lifetime is expected to be. And this would presumably be an optional 
capability that not all UAs will be expected to have.

> 3.4.  Correlate the original INVITE, SUBSCRIBE request and recall INVITE
>       in SIP Call Completion scenario

This seems to tie in closely with the historical session notion that 
emerges in 3.3. It suggests additional properties of these "historical 
sessions".

I'd like to see the focus be on this "historical session" concept, which 
is new and doesn't conflict with other mechanisms.

	Thanks,
	Paul

Salvatore Loreto wrote:
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 16 Jun 2008 19:43:37 +0300

Hi Paul,

thanks for the comments, see my answers inline

Sal

> I seem to recall a proposal similar to this quite some time ago. Am I 
no, you are not imaging :-)
two years ago I submitted a similar proposal:
http://www.sloreto.com/drafts/draft-loreto-sipping-dialog-correlation-01.txt

However this time the proposal is more general, in some sense what I 
have in mind is exactly what you have called
the *"historical session" concept*, that in my mind should be something 
similar but not equal to the http cookie.

> Yet I do see the germ of a significant new feature in here, that I 
> will describe after some comments on particular parts of the draft.
>
the use case I tried to describe was not based on a message session 
using MESSAGE,
but in one or more MESSAGEs *sent outside a session* and then link them 
to an MSRP session.
Something like
Alice sends a MESSAGE to Bob
Bob answers immediately with another MESSAGE
Alice then thinks that is better continue the discussion establishing a 
session, so she starts an MSRP session, but she want in some way signal 
that the *chat* she want start is linked to the previous MESSAGE
> discussed before, though perhaps only in email rather than in a draft.
we discussed via email, during the discussion related to the correlation 
draft!!!
> the right thing. Adding a new mechanism to do this differently is IMO 
> a mistake.
I am not completely convinced that the Join header works perfectly for 
this use case.
In this, I am supported by the fact that also in Section 5.4.3 of draft 
http://tools.ietf.org/id/draft-shacham-sipping-session-mobility-05.txt
it is clearly stated that

   "there is currently no standard
   way to associate multiple sessions as part of a single call in SIP."

and in my opinion the there isn't any difference between my use case and 
the scenario showed in  the session-mobility draft.
> memory of *past* sessions after they have completed. In this 
> particular use case it also implies a class of data that is expected 
> to be retained for such a session - a log of the conversation held 
> during that session.
>
I am happy to read it!
> desired functionality.) But for it to be so it will need to be 
> specified much more fully, in terms of the data that is expected to be 
> retained, where that data should be retained, how it should be 
> accessed, and what the lifetime is expected to be.
I completely agree. There is a lot of things that need to be discussed 
and studied more in deep.
As I have said above it could be something similar to the http cookie 
data structure defining the lifetime, the access right...
About where the data should be retained, one possibility is that each UA 
should retain its own data: that means if I use a different UA I can not 
take advantages of it.

> And this would presumably be an optional capability that not all UAs 
> will be expected to have.
exactly, I don't think that all the UA will support it.
so it should be optional.

> I'd like to see the focus be on this "historical session" concept, 
> which is new and doesn't conflict with other mechanisms.
>
>     Thanks,
>     Paul
>
> Salvatore Loreto wrote:
>> Hi there,
>>
>> or even multiple SIP transaction sent outside of a dialog, with new 
>> SIP dialog/s.
>>
>> that can be used to implement applications using multiple SIP 
>> sessions, even across the time.
>>
>> for the time being the draft will appear on the IETF web site, you 
>> can find here:

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jun 2008 13:26:48 -0400

> http://www.sloreto.com/drafts/draft-loreto-sipping-dialog-correlation-01.txt 

Oh, good. Then my mind isn't *entirely* failing me. :-)

> similar but not equal to the http cookie.

Well, if it is to be anything like the cookie then it will no doubt be 
very controversial.

> that the *chat* she want start is linked to the previous MESSAGE

OK. *If* the assumption is that there is indeed no *session* tying the 
two MESSAGEs together - only some historical context, such as might be 
kept for a call log, then *maybe* I can buy in a bit. (More later.)

> I am not completely convinced that the Join header works perfectly for 

IMO it works fine in *this* case. There are indeed limitations to that 
solution.

>   way to associate multiple sessions as part of a single call in SIP."

I guess I should have taken issue with that statement in the draft. In 
the topology being used in the draft there would be issues with using 
Join to achieve the intended objective, but tying the two into a single 
call isn't one of them. The main problem in that case is that the other 
party (the CN) would have to handle the Join, and it isn't something 
that is widely supported.

The end that wants to combine separate audio and video devices and use 
them in a single call is the end that ought to deal with the issues that 
brings, rather than depending on the other party to do it.

> the scenario showed in  the session-mobility draft.

Regardless of the statement, the solutions proposed by Shacham are more 
complete than a simple Join. And they don't require any context-id.

> should retain its own data: that means if I use a different UA I can not 

When I look at what is deployed, I see these kinds of historical logs 
already. They all seem to be tied to an AOR, without any kind of context 
id. Certainly that is the case with IM logs.

So it might be sufficient to have have historical logs for sip tied to 
the perceived AOR of the other party (doesn't work well for anonymous 
calls). Where necessary for disambiguation, individual sessions could be 
identified by their callid. I am not yet seeing a need for a separate 
context id to identify historical sessions. Having yet another id might 
just make it that much more difficult to organize and present in a UA.

For the CC case, the AOR (tied directly to a monitor) and the callid of 
the failed call (queued by the monitor) would work.

What does the context id add?

IMO the starting point would be a list of requirements for a historical 
record of sip requests and/or sessions. And then move on to defining a 
mechanism for managing and accessing such a db. I'm actually not sure 
how CC fits into that, since it requires a much shorter duration db than 
some of the other applications do, and implementors of cc aren't likely 
to be willing to implement a much longer term db. Certainly PSTN GWs 
won't be.

	Thanks,
	Paul

---

From: [email-masked]
Date: Mon, 16 Jun 2008 14:41:56 -0400

From: Paul Kyzivat <[email-masked]>

Speaking as someone who once contemplated a dialog in which multiple
MESSAGE requests were exchanged, but who was convinced of the error of
his ways:

This use case is even higher-overhead than a dialog containing
multiple MESSAGE requests, in that it envisions that each MESSAGE
request is sent out-of-dialog, and thus goes through the full route
resolution process.  If it is a bad thing to use Call-Id to correlate
a series of MESSAGEs, it is a worse thing to use another identifier.

Unfortunately, Join doesn't do quite the right thing, as Join presumes
that the Join recipient will function as a conference mixer.

The difficulty with this new concept is that it is not definitive as
to the semantics of the identifier.  The identifier says that the two
dialogs are related, somehow, but it doesn't specify *how* they are
related.  This is fine for a diagnostic tool, or for data that will be
heavily processed by a human before being acted on, but is treacherous
for a protocol.  (Witness the "five uses of REFER" problem, where the
recipient of a REFER has to distinguish a number of different contexts
before deciding how to act on the REFER.)

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 16 Jun 2008 23:47:10 -0500

> I seem to recall a proposal similar to this quite some time ago. Am I

Maybe:

http://www.softarmor.com/wgdb/docs/draft-willis-sip-cookies-00.txt

There was a -01 of this draft, but I seem to have misplaced it.

--
Dean