Subject: [BLISS] call-completion interworking problem

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 18 Jan 2008 10:53:19 +0100

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.

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 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-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jan 2008 13:41:56 +0000

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-masked]] 
	Sent: 18 January 2008 09:53
	To: [email-masked]
	Subject: [BLISS] call-completion interworking problem

	Hi everyone, 

	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

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 29 Jan 2008 03:14:54 +0100

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-masked]] 
> Gesendet: Freitag, 18. Januar 2008 14:42
> An: Hülsemann, Martin; [email-masked]
> Betreff: RE: [BLISS] call-completion interworking problem
> 
> 
> Martin,
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 01 Feb 2008 07:51:52 +0000

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-----
> Sent: 29 January 2008 02:15
> To: Elwell, John; [email-masked]
> Subject: AW: [BLISS] call-completion interworking problem
> 
> Hi John,
> 
> 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
> 
> 
> 
> 
> 
_______________________________________________
BLISS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bliss