Subject: [Sipping] Correlate sip sessions/dialogs

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Jan 2009 18:53:01 +0200

Hi there,

at the last IETF sipping wg meeting  people appeared interested to spend 
some cycles on standardize a mechanism to
*correlate sip sessions*.

However, at present we have three drafts that talk of this issue

- *Requirement for Dialog Correlation in SIP* [1] : this draft 
explicitly list in Section 4 the requirements for correlating SIP 
dialogs that relate to the same multimedia session:
- *The Reference Header for SIP* [2]: it defines a SIP extension header, 
Reference, to be used within SIP messages to signify that the message is
related to one or more other dialogs.
- *A Session Identifier for the SIP* [3]: it identifies several reasons 
for having a globally unique session identifier for the same SIP 
session, which can be
maintained across B2BUA's and other SIP middle-boxes. Moreover it 
identify requirements and a new SIP extension header, Session-ID, to be 
used to carry an
unique session identifier

The need to correlate Dialogs is also under discussion discussing in the 
*shared appearances draft* [4] in BLISS wg.

Now, as I am trying, with the help of the other authors and other 
people, to merge and converge the three draft in one document,
I'd like have comments and opinion on the following:

The semantics of al the use cases and then the requirements for this 
mechanism, as described in the drafts [1][2][3], are slightly  different.

The first and main difference is that the requirements in draft [1] are 
looking for an identifier that relate to the same media session:

   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.

where the requirements in draft [3] are looking for an identifier that 
has nothing to do with media even if the separate dialogs happen to
relate to the same media session:

   REQ1: It must be possible to identify a set of dialogs which have a 
   direct correlation with each other such that they represent the same 
   SIP session, with as high a probability as possible.

So we have to analyse  and standardize different mechanisms that solve 
each specific scenario or one general mechanism:
in fact it can happen that the mechanism to solve the requirements of 
[3] solve also the requirements in [1] and vice versa,
without adding complexity. But it is not clear yet.

My proposal here is to keep, in the merged document, distinct this two 
requirements as they seems to be semantically different.
I propose to have a set of requirements for "media session correlation" 
and a set of requirements for "dialog correlation".
Please comment!

One second issue, that it is IMO common, is to discuss and decide 
whether we can create the initial dialog without knowing
in advance whether another dialog will want to correlate with it (as I 
think we should)//

    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.

or not

    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.

As Dale pointed out in one previous mail /"In the call-completion work, 
we took as an //assumption that call originators
would not be willing to tag each call with a special value just so that 
a small minority of calls could //later have
call-completion applied to them."/

Please comment!

Then we have a set of requirements that can be considered common:

from draft [1]:

   REQ[1].2 The state information associated to the correlation among a set
      of SIP dialogs must expire (i.e., can be discarded) when the last
      of the SIP dialogs is terminated.

   REQ[1].3 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.

from draft [3]:

   REQ[3].3: It must be possible to pass the identifier through B2BUA's, 
   with as high a probability as possible.  This requirement drives the 
   following requirements: 

   REQ[3].3a: The identifier must not reveal any information related to any 
   SIP device or domain identity, including IP Address, port, hostname, 
   domain name, username, Address-of-Record, MAC address, IP address 
   family, transport type, etc. 
    
   REQ[3].3b: The identifier must not reveal to the receiver of it that the 
   Call-ID, tags, or any other SIP header or body portion have been 
   changed by middle-boxes, with as high a probability as possible. 

Please comment, if you think this requirement can be considered in 
common or not.

then draft [3] there is a requirement related to out-of-dialog request, 
that I don't know (I don't have a strong
opinion on it) if we can be consider in common or not:

   REQ[3].2: It must be possible for a SIP device to use the identifier in 
   out-of-dialog requests, to match existing dialogs at B2BUA's and/or 
   UAS's, if the Call-ID and tags the device believes are correct do 
   not in fact match, with as high a probability as possible. 

Finally, as we are still in an early stage of the sipping process I 
don't think we should talk in the draft
about any mechanism/solution, but just of Use-Cases and Requirements.

thanks in advance for all the comments you will provide

cheers
Sal

REF.
[1] 
http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt 

[2] http://tools.ietf.org/html/draft-worley-references-01
[3] http://tools.ietf.org/id/draft-kaplan-sip-session-id-01.txt
[4] http://tools.ietf.org/html/draft-ietf-bliss-shared-appearances
_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Sun, 25 Jan 2009 20:48:16 +0200

Hi,

> and a set of requirements for "dialog correlation".

yes, they are two different things. Let's keep them separate for the 
time being. We should not assume at this point that we will have a 
single mechanism to meet both.

> in advance whether another dialog will want to correlate with it (as I 

we should not assume that users can predict the future when they start a 
dialog. Therefore, it should be possible to correlate a dialog with a 
previous one that did not specify anything special to that extent.

> Please comment, if you think this requirement can be considered in 

yes, they seem to be common requirements.

>   REQ[3].2: It must be possible for a SIP device to use the identifier 
> in   out-of-dialog requests, to match existing dialogs at B2BUA's and/or 

if the scope is dialog correlation, out-of-dialog requests should be out 
of scope. If we want to include them, we need to revise the scope of the 
requirements.

> about any mechanism/solution, but just of Use-Cases and Requirements.

yes, we should stick to use cases and requirements at this stage. Some 
of the requirements above use solution type of language. They should be 
rephrased so that they are more general.

Cheers,

Gonzalo