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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
