Hi John, do you think of something like in the flows provided under
- First flow http://www.bliss-ietf.org/drafts/misc/ccbs_flow3.bmp - Second flow http://www.bliss-ietf.org/drafts/misc/ccbs_flow4.bmp - Third flow http://www.bliss-ietf.org/drafts/misc/ccbs_flow5.bmp ? Here the cookie consists of a specific CCBS ID, caller ID and callee ID. For a pure internet call the CCBS ID will be call specific, for the interworking case the CCBS ID will be something which is known to all MGCs of a network. So in every case the cookie can be assembled from the information available at the interworking case. BR, Martin > -----Ursprüngliche Nachricht----- > Von: Elwell, John [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 18. Januar 2008 14:42 > An: Hülsemann, Martin; [email protected] > Betreff: RE: [BLISS] call-completion interworking problem > > > 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
