Re: Comments ondraft-loreto-sipping-context-id-requirements-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dale,
 
There is a new version of the draft. http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt
This has only 3 requirements :) . Not sure your intention is to comment on the old one or you didn't notice the new one.
Some of the comments you mentioned are not applicable in 01 version.
 
Some folks in this mailing list mentioned about 3pcc to achieve the behavior. As you mentioned in your first Para probably it works only if the sip body is SDP. In this case actually SIP is not providing the mechanism. Its the SDP which is providing the mechanism.
 
The problem statement in this draft needs to be stated as a SIP mechanism to correlate the dialogs as apposed to other mechanisms like SDP.
 
Regards
Krishna

________________________________

Från: sipping-bounces@xxxxxxxx genom Dale.Worley@xxxxxxxxxxx
Skickat: må 2008-12-08 17:35
Till: sipping@xxxxxxxx
Ämne: Re:  Comments ondraft-loreto-sipping-context-id-requirements-00



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


[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux