From: "Elwell, John" <[EMAIL PROTECTED]>
I am not sure I understand your proposal. I had assumed that the B2BUAs
concerned would not be CC-aware, so would simply use there own internal
algorithms for generating call-IDs.
What I had in mind for solving the problem is that the call-ID (or some
other value unique to the monitor) be returned in the response to the
initial INVITE request, e.g., as part of the URI in Call-Info. We would
then be completely independent of any unwanted treatment of Call-IDs by
intervening B2BUAs.
Perhaps I'm not understanding the situation that you are operating in.
You wrote:
I still don't get this call-ID stuff. If there is an intermediate B2BUA
that maps call-IDs between the upstream side and the downstream side and
it is not CC-stateful, how can it ensure that it performs the same
mapping on a call-ID in the Event header field of a SUBSCRIBE request
that it carried out on the original INVITE request? Without such
mapping, the callee's monitor will receive a different call-ID and will
be unable to match.
Even with a CC-stateful B2BUA there, what if the SUBSCRIBE request gets
routed differently and passes through a different B2BUA?
I think the question is how to arrange for the original call, the
SUBSCRIBE (CC activation), and the CC recall to be correlated. The
restriction is that the original call goes through a B2BUA that cannot
carry state to the later two operations.
It seems to me that a solution is that when the B2BUA generates the
downstream call, it carries the 'id' of the upstream call, or the
Call-Id if the 'id' is missing, into the 'id' of the downstream call.
(The Call-Id could be chosen by any method.)
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
