Hi Dale,
thank for your comments,
however as Krishna has pointed out in his previous mail,
in the last version of the draft
(http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt),
the one I presented in Minneapolis, there are only three requirements.
In fact we have heavily rewritten the last version focusing only on the
problem space related to how
logically correlate multiple SIP dialogs that relate to the same
multimedia session,
without any assumption on the desired mechanism:
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.
REQ2 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.
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.
However during the discussion was clear that there are other drafts that
are looking for a similar
"correlation mechanism", but with slightly different requirements!
I am perfectly aware that the above requirements do not cover all the
use cases that different
people have in mind, and that the requirements need to be
expanded/rephrased etc. etc.
so I am keen for working with all of you to lists all the different
requirements and use cases, in order to figure out
the semantics of all possible use-cases and then analyse all of them in
order to understand how to proceed.
/Sal
Dale.Worley@xxxxxxxxxxx wrote:
People have been discussing alternatives to the concept of correlating
separate dialogs in order to present them as parts of one
(user-centered) communication session. The ideal solution seems to be
to use one dialog containing SDP that describes all the associated
media streams. SDP allows this, as each stream can have a separate c=
line. But in some cases, this won't work. E.g., if an IM
conversation has been progressing using MESSAGE requests. (And
MESSAGE seems to be how SIP-enabled IM clients send IM.) In that
case, there's no SDP to be revised to include an audio or video
session.
In regard to correlating simultaneous dialogs, there are complexities
that I don't think we've thought through. E.g., the draft proposes
that one UA decides to initiate a video stream, but must activate a
separate UA to start the stream. But what happens if there is an
incoming request to initiate a video stream? How is that routed to
the separate video UA, with proper correlation with the existing audio
UA? (And there are two flavors of this: (1) the request is a
separate-but-correlated INVITE, and (2) the request is part of the SDP
in a re-INVITE of the original dialog) I'd feel much more comfortable
knowing that the full consultative-transfer sequence had been worked
through, with various combinations of (1) integrated UAs that can
handle all the media at one time with (2) UA clusters that use the
correlation mechanism.
In regard to Reqs. 1 and 2:
The talk of "applications" seems to be incorrect here. A better
phrasing of Req. 1 would be "It MUST be possible to correlate a SIP
Request (e.g. MESSAGE) sent out outside of a dialog with a specific
other dialog." The SIP standard does not speak of applications, and
there is no necessary correlation between applications and dialogs.
If the correlated-to dialog may already have been terminated, this
needs to be noted explicitly, since most SIP correlation mechanisms
fail if the referred-to dialog no longer exists. Similarly, we need
to ask what happens if the correlated-to dialog does not yet exist (as
may happen in race conditions).
In regard to Req 4: "The Context ID shall be an End to End value."
First, this assumes that the correlation mechanism will be a Context
ID value, which is not stated explicitly as an assumption.
Second, this is not so much a constraint on the solution, as a
relaxation of requirements, because the real meaning is "We do not
require the mechanism work with dialogs that pass through B2BUAs
unless the B2BUA passes the Context ID without change." But as
Hadriel's draft shows, there are perceived security/privacy questions
regarding such values, and we can assume as a default that B2BUAs
*will* delete such values. This makes an explicit Context ID
mechanism less likely to work in initial uses.
There is also the question of whether we can create the initial dialog
without knowing in advance whether another dialog will want to
correlate with it. 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.
In regard to Reqs. 5 and 7, a better phrasing is "The correlation
mechanism shall not be required to operate between dialogs that are
separated by more than a certain Time To Live, which shall be
controllable by the UAs." But it's not clear why a TTL is needed. Of
course, context IDs that are old enough will probably be unusable due
to application limitations, but I see no reason to *require* their
expiration.
Req. 6 is entirely a restriction on applications, not the protocol,
and so is not a matter for standardization.
Req. 8 would be better phrased "The correlation mechanism shall be
such that if a UA does not implement the correlation mechanism, or if
it fails to discern a correlation specified by another UA, the
resulting operation shall be a reasonable fall-back behavior." But
that is just requiring reasonable upward-compatibility, which is
implicit in all IETF standards.
In regard to identifying conversation spaces, we need to pay attention
to what we mean. Presumably, if dialog A is "in the same conversation
space" as dialog B, then dialog B is also "in the same conversation
space" as dialog A. More subtly, is this relationship transitive?
That is, if we correlate A and B, and we correlate B and C, have we
automatically correlated A and C?
More treacherously, do these relationships change with time? Since
the correlation mechanism is expected to operate not just at a single
moment, but backward and forward in time (Req. 3), the natural
assumption is that two dialogs are "in the same conversation space"
through all time. But with a little work, we can construct sequences
of interactions that cause a UA to create dialogs A and B to different
endpoints, and then only later, the UA is forced to conclude that A
and B are in the same communication space. But since the UA didn't
know that fact at the time it created A and B, it may not have been
able to tag them as "in the same communication space".
One way to get out of that mess is to make the "in the same space"
relationship abstract, and the UA never needs to actually know it.
(The "References" header uses this escape; "related" is only truly
known by an omniscient observer, and a UA never needs to know whether
two dialogs are "related", it only needs to indicate to the omniscient
observer that it knows at this moment that two dialogs are "related".)
Another escape is to make "in the same communication space" entirely
operational, to reduce it to "when initiating a dialog, the INVITE may
indicate that this dialog is intended to be rendered 'in the same
communication space' as one or more other specified dialogs". This is
what the Join header does.
Indeed, it seems that a workable solution to these problems is to
create a header much like Join, say "With", which specifies the dialog
identifiers of some other dialog which this dialog should be "rendered
in the same communication space". This has the advantage that B2BUAs
could mangle this header with exactly the same logic as they now use
on Join and Replaces (simplifying deployment and eliminating the
security issues). But disadvantage is that With might reference a
dialog that has long since ended (e.g., 24 hours), in which case
B2BUAs are unlikely to map it correctly.
Dale
_______________________________________________
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
_______________________________________________
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
