Subject: R: [Sipping-tispan] [CCBS/CCNR]

From: Tessa Silvia <[email-masked]>
Date: Mon, 05 Sep 2005 13:26:47 +0200

Inline.
> >
> > Any time a user does not accept a session returned by CCBS
> > within a given timeslot his place in queue is removed, unless
> > he is busy.
> 
> First, I think the intent is still to have the CCBS requestor initiate
> the call, since there may be costs associated with doing so.

There's no cost issue related to who is initiating the call because the
network is able to bill the caller regardless if it is a first-party or
a third-party call.

> 
> Second, you suggestion may run into race conditions with the CCBS
> requestor attempting to send a suspend request, because perhaps he had
> to answer another incoming call.

A CCBS subscription can be suspended if and only if the caller is busy:
the caller can not say "I'm going out for 5 minutes, I'll suspend my
ccbs subscription, and resume it when I get back". The CCBS requestor
can not suspend and resume a request: he can only cancel it.

Does this exclude the race condition you mentioned ? If not, could you
explain a bit further? 

> 
> > Any time a user is busy when a session returned by CCBS is
> > delivered, he keeps his place in queue. Other users in queue,
> > if any, can be served.
> > (this last scenario is known as "suspension")
> >
> > Would that be ok ?
> 
> How does the called queue manager know whether the caller is busy or
> not?  I'm afraid these requirements are delving into the solution
> discussion, but I'm not sure if that is avoidable.

I'm afraid as well, but I'll try to answer by rephrasing requirement 1:
Req 1 declares the need to monitor the callee, actually there's also a
need to monitor the caller....

REQ-1:
The entity providing the CCBS/CCNR service needs to know the change of
the status of a UA (e.g., in CCBS a transition from busy to idle or in
CCNR a transition from idle to another state) and it should have the
ability to recognize if the UA is able to provide such indication.

I can't tell if UA is the correct term, what I want to say is that it
applies for both callee and caller.

Regards
Silvia

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 05 Sep 2005 14:39:09 +0300

> ability to recognize if the UA is able to provide such indication.

I think we need to split this into two requirements, one to monitor the 
callee (the status is dependent on whether CCBS or CCNR is used); the 
other is to monitor the caller, to check that he is not busy.

REQ-1:
   The entity providing the CCBS/CCNR service needs to know the change of
   the status of the callee (e.g., in CCBS a transition from busy to idle
   or in CCNR a transition from idle to another state) and it should
   have the ability to recognize if the UA is able to provide such
   indication.

REQ-1bis:
   The entity providing the CCBS/CCNR service needs to know the status
   of the caller at the time of allocating a timeslot to execute a
   pending CCBS/CCNR pending request. Should the caller be busy at that
   time, the CCBS/CCNR service will (check the action) de-queue the
   caller and send him a notification.

How about that?

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Sep 2005 17:29:26 -0400

>   caller and send him a notification.

I think it is really hard to get good accuracy. This goes to the basic 
question of what constitutes "busy". If I am on a call but have call 
waiting, am I busy? I may have been trying really hard to get through to 
this person, which is why I was using CCBS. I may have gotten another 
call, but if my turn comes up for CCBS I will gladly accept the prompt 
for it. (I guess this is a case of feature interaction that may already 
been settled in the PSTN. Can somebody explain how it works there?)

Also, if multiple devices have registered, the fact that one is busy on 
a call is not much of an indicator of whether another will answer or 
not. If there is only one user and two devices then being busy on one 
probably means you can't use the other. But if there are two users (e.g. 
a family) that isn't the case.

Without knowing a great deal about the capabilities of individual 
devices, and maybe the user as well, it would be very difficult for 
something in the network to guess whether the caller's AOR is "busy" 
enough that it won't be able to take its turn.

Defining the simulation service may be relatively straightforward in the 
case where there is a single device registered

	Paul