Hi Laura,
Hadriel's Session-ID describes and propose a solution (moreover that
draft does not have an explicit requirement similar to
the one you are proposing, it provides a solution that fulfil your
requirement);
in the Context-Id we do not describe or propose any solution
because we want before people agree on the need of a such new mechanism
and commit to work together to a solution.
In the Context-ID draft there is any requirement that states that the
mechanism has to be started by a UA,
in 4.3 Common requirement we only say:
REQ1 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.
we do not mandate that it has to be done in UA, it can happen in the
B2BUA or in a Proxy.
Then Req 3 of the same section we say that the mechanism should word
also fo non-compliant end device:
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.
So I think that the requirement are enough general to cover also your
scenario
thanks
/Sal
L.Liess@xxxxxxxxxx wrote:
Hi Sal,
What I want is that the dialog correlation method also also works
without end devices contribution (for non-compliant end devices).
Hadriel's Session-ID ( 5.5.1) fulfills this requirement.
REQ3 doesn't cover this issue.
Laura
_______________________________________________
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
