Martin,
>From a SIP point of view there should not be a need to specify the
content of a cookie - it is an internal matter for the queueing entity.
My understanding of how PSTN gets by without a cookie is because it
allows only one candidate callback request between a given caller ID and
callee ID, so the combination of caller ID and callee ID is sufficient
to identify the request uniquely. Such a restriction seems either
inappropriate or not feasible in a SIP environment.
- Inappropriate because I might make one request from device A1 to
device B, and then, having moved to another room or wanting to use my
mobile device, I make a second request from device A2. If I don't
respond to the callback on A1, I get a callback on A2. Both devices have
registered using the same AoR, so caller ID will be the same in each.
- Not feasible because of privacy concerns, particular when crossing
trust domain boundaries - thus caller ID might not be available at the
queueing server.
The feature in the PSTN is not impacted by privacy - IDs are exchanged
between network entities even though they might not be disclosed to user
devices.
So perhaps we could have a rule for constructing a cookie from the
caller and callee IDs only in the PSTN interworking case. Obviously
there would need to be some means of determining when to use such a
deterministic cookie. Also canonical forms of identifiers would need to
be defined for constructing such a cookie.
John
________________________________
From: Huelsemann, Martin [mailto:[EMAIL PROTECTED]
Sent: 18 January 2008 09:53
To: [email protected]
Subject: [BLISS] call-completion interworking problem
Hi everyone,
welcome to the this years call-completion discussion.
As I understood from the results of Vancouver people prefer a
solution using a cookie. In the case there is a queue at the callee the
callee's monitor adds a cookie to the 486, this cookie is a specific
call-completion reference and indicates that call completion is possible
in general.
The caller's agent then can subscribe to his call-completion
state at the callee's monitor, but only if he sends the cookie with the
SUBSCRIBE.
Also when the caller starts the call-completion call after he
has received the notification that he is on top of the queue he has to
add the cookie in the INVITE in order to prioritize the call-completion
call.
Is this correct so far? It would basically look like the flow
available under
http://www.bliss-ietf.org/drafts/misc/ccbs_flow1.gif
<http://www.bliss-ietf.org/drafts/misc/ccbs_flow1.gif> .
If this is in principal correct, the question then is how does
this cookie look like. Probably there will be something specific for a
particular call-completion case, e.g. CCBS ID, a callee ID and a caller
ID. As the concept of a CCBS cookie doesn't exist in the PSTN, this
causes problems at the interworking, especially when a PSTN caller wants
to activate CCBS on an Internet callee.
The problem is that for this interworking with the PSTN it is
possible that the 3 dialogs (busy call, supscription and call-completion
call) are handled by 3 different MGCs, but only the MGC which
interworked the busy call dialog knows about this cookie. So in many
cases neither the subscription for the call-completion event package nor
the call-completion call will work.
http://www.bliss-ietf.org/drafts/misc/ccbs_flow2.gif
<http://www.bliss-ietf.org/drafts/misc/ccbs_flow2.gif> illustrates this
problem.
Are there any suggestions from you how this problem can be
solved? I was thinking of some kind of default cookie when it can be
detected that a call came in from the PSTN.
BR, Martin
_______________________________________________
BLISS mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/bliss
