Dale,
Let me illustrate:
Agent B2BUA Monitor
INVITE call-ID 1 INVITE call-ID 2
----------------> ---------------->
186 186
<---------------- <----------------
SUBSCRIBE call-ID 3 SUBSCRIBE call-ID 4
Event:...target-call-ID 1 Event:...target-call-ID 1
----------------> ---------------->
If the B2BUA does not also translate the referenced call-ID within the
SUBSCRIBE request (in the Event header, I believe), the monitor will
receive a target call-ID that it does not recognise. This assumes the
B2BUA is not CC-aware, and therefore does not translate the target
call-ID.
Even if the B2BUA is CC-aware, it would need to retain state concerning
the original call-IDs after the call has finished.
The problem is even worse if the INVITE request and the SUBSCRIBE
request traverse different B2BUAs.
John
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of [EMAIL PROTECTED]
> Sent: 05 March 2008 22:48
> To: [email protected]
> Subject: Re: [BLISS] Call-completion design question:
> End-to-end parameters
>
>
> 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
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
