Dale, 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. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: 03 March 2008 22:01 > To: [email protected] > Subject: Re: [BLISS] Call-completion design question: > End-to-end parameters > > > From: "Elwell, John" <[EMAIL PROTECTED]> > > 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 haven't given it much thought, but one choice would be to hash the > incoming call-ID with a 64-bit key (shared among the constellation of > B2BUAs/gateways) to generate the outgoing 'identifier'. (As the > protocol is defined now, the B2BUA can choose the Call-Id freely, and > apply the generated 'identifier'.) > > Dale > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
