Hi Paul, John and all,
I agree that party A could use 3pcc to making transparent for party B
the fact that it is using separate devices for different media, and
then making everything into one dialog for B;
however there could be situation, and indeed there are use cases where
it would be preferable not using a centralized and heavy mechanism as
3pcc but instead having something more distributed and lighter.
About your concern on what happens if party B wants to transfer the
"call", in the case where party A asked party B to establish a correlation
between two dialogs, my first answer is that yes it should be expected
to do *two* transfer - one for each dialog, and I don't see any
problem in this. Of course I can be wrong in this, and probably I am, as
usual.
Thanks
Sal
Paul Kyzivat wrote:
I still remain unconvinced that it is needful or reasonable for party
A to expect it can ask party B to establish a correlation between two
dialogs.
It becomes a very slippery slope. For instance once that has happened,
if party B wants to transfer the "call", should it be expected to do
*two* transfers - one for each dialog?
IMO this is a problem to be solved by the UA that wants the
correlation. E.g. if A wants to have separate audio and video devices
at *its* end of a dialog with B, then it is responsible for making
that into one dialog for B. Then if B wants to transfer the call to C,
it can do so using normal means. A will be responsible for dealing
with the implications of that, not B or C.
In this case there clearly is some element that knows about the
correlation. But it is the same element that made the initial decision
that a correlation is desirable.
Thanks,
Paul
Dale Worley wrote:
On Wed, 2008-12-10 at 15:57 +0200, salvatore loreto wrote:
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.
The question is, that is, it might or might not be a requirement: Does
a dialog have to be specially marked during its establishment in order
for another, later, dialog to correlate with it?
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.
Actually, I'm talking about another potential requirement: If dialogs A
and B are established, with no indication of correlation between them,
does it need to be possible for a dialog C to establish a correlation
with *both* A and B? (Which will presumably place all 3 dialogs in the
same communication space.)
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
