Hi Dale,
see my comments in line
/Sal
Dale Worley wrote:
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.
The following questions remain:
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.
[Sal] yes I agree that we have to discuss "when correlation happens",
I do not have a strong opinion on this point, I think the correlation
could happen at any point during
the dialog establishment phase.
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.
[Sal] the relation is for sure "reflexive" if dialog A is correlate with
dialog B, then dialog B is correlate with 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?
[Sal] I am tempted to say yes, the relationship is transitive!
however I can also imagine a scenario where there are different kind of
correlation:
so if A and B are correlate with a correlation type X and B and C are
correlate with a correlation type Y,
where the correlation type X is different from the correlation type Y,
then A and C are not automatically correlate.
But maybe this is something to complicate to implement and I don't know
it is useful at all.
More treacherously, do these relationships change with time? [...deleted...]
[Sal] I have never thought of a similar possibility
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".)
[Sal] here you are already talking about a solution, where I think we
should still continue to discuss the requirements
and the use case related to the requirements.
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.
[Sal] yes Join header does but with a different and specific semantic.
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
