RE: [Sipping-tispan] [CCBS/CCNR]

> -----Original Message-----
> From: Tessa Silvia [mailto:Silvia.Tessa@TILAB.COM] 
> Sent: Friday, September 02, 2005 7:30 AM
> To: Michael Hammer (mhammer); Miguel Garcia; sipping-tispan@ietf.org
> Subject: R: [Sipping-tispan] [CCBS/CCNR]
> 
> > > - A bit more elaboration on the queue management, precisely, what 
> > > are the implications for the service (I think there is 
> the concept 
> > > of a "timeslot" in which a user can return a call, and if 
> it doesn't 
> > > happen, the user misses his turn in the queue ... or 
> something like 
> > > that.
> > 
> > How about:
> > 
> > The submission of a CCBS/CCNR queue request must include a 
> time limit.
> > 
> > The CCBS/CCNR queue service may adjust the request time limits based
> on
> > local policy.
> 
> 
> Actually, I've interpreted Miguel's "timeslot" as follows :
> 
> 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.

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.

> 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.

> > > - A definition of a "CCBS/CCNR request", which at the moment, 
> > > misleads me in the interpretation of the service. It can mean two 
> > > different
> > > things: "Please add me to the CCBS/CCNR queue of the callee", or 
> > > "this is a session returned as a result of an indication from 
> > > CCBS/CCNR".
> 
> 
> The "CCBS/CCNR request" as I read it in the draft, is used as 
> "Please add me to the CCBS/CCNR queue of the callee": it's a 
> request to monitor a user status changes, not a call. If it's 
> not clear enough, we could replace it in the requirements 
> with "CCBS/CCNR subscription": would that be easier or is it 
> even more confusing?

Subscription is very close to the mechanisms likely to be used.

> > and:
> > 
> > The CCBS/CCNR callee must have the means to inform a queued caller
> that
> > the callee is free along with the means for the caller to originate
> the
> > subsequent session setup such that it can be distinguished by the
> callee
> > from other possible session setups.
> 
> The requirement is not strictly for the caller to be notified 
> of the callee status, nor for him to setup the call, in my 
> opinion it  should just be:
> 
>   The CCBS/CCNR simulation service should be able to deliver 
> a communication to the caller, when the service-specific 
> condition related to user state is met. Any communication 
> performed as a result of a CCBS/CCNR should be 
> distinguishable from regular calls.

Similar to above, I don't see this as the network or the called party
initiating the communication.  I think the essence is for the two
parties to share information about the:

1) desire of calling party to be queued
2) willingness of called party to queue caller,
3) ability of calling party to notify called party of temporary
inability to call (suspend),
4) ability of calling party to notify called party of return to ability
to call (resume),
5) called party ability to select and notify "your turn" to a specified
caller from the queue,
6) called party ability to revoke caller "turn" and select new caller,
7) ability of calling party to request removal from queue,
8) ability of called party to remove caller from queue and notify
caller. 

Bottom line, get both to the point where they know the other is ready to
communicate.

Mike

> 
> 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 
> MailAdmin@tilab.com. Thank you 
> ====================================================================
> 

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan