Martin, Sorry for the delay in responding.
In the second flow, the cookie does not serve any useful purpose, since the 3 dialog-initiating requests (INVITE, SUBSCRIBE, INVITE) go to three different gateways. By providing a sort of contact URI, as proposed by Dale today in the form of a CC: header, you can ensure that all three requests go via the same gateway and can take advantage of the cookie. In fact the URI in Dale's proposal would fit this bill. The URI could also incorporate cookie-like information to enable the monitor or gateway to identify a particular failed call request. So basically I like Dale's proposal, which for the pure SIP case provides greater functionality in forwarding / forking situations. I will respond on the list to that. Concerning the third flow, this of course is the really difficult one and we will have to accept some reduced functionality, because of the limitations of PSTN. So the gateway and monitor would each have to operate on the information available, i.e., the calling and original called addresses. Regards, John > -----Original Message----- > From: Huelsemann, Martin [mailto:[EMAIL PROTECTED] > Sent: 29 January 2008 02:15 > To: Elwell, John; [email protected] > Subject: AW: [BLISS] call-completion interworking problem > > 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] http://www.ietf.org/mailman/listinfo/bliss
