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

["Michael Hammer \(mhammer\)" <[e-mail]>]

Why does Italy limit the queue to 1?  Is this some silly regulation?  This should be a matter of local policy, i.e. settable by the user from 0 - some large number, if client-based, and likewise only limited by the network policy if network-based service.

Also, it is not a good user experience to possibly have a GUI indicator saying he is waiting in a queue, when in fact the network or the called party cleared the queue, but didn't provide that feedback to the caller.  If there is not such a requirement, there should be.

Mike


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Tessa Silvia
> Sent: Friday, September 02, 2005 7:20 AM
> To: [e-mail]
> Subject: R: [Sipping-tispan] [CCBS/CCNR]
> 
> Hi everybody,
> some answers / comments inline.
> > 
> > Some additional questions / comments:
> > - Are CCBS / CCNR related to a terminal or an AOR of caller/callee?
> AOR
> 
> > - A more precise definition of state change is needed (e.g. 
> using BYE 
> > or INVITE for a call, avoiding busy/idle expression)
> can't we refer to a user dialog state changes ?
> 
> > - What is the meaning of "the callee showed activity"? 
> Could this be 
> > WWW search as well?
> 
> A www activity would be "new stuff" therefore really good in 
> my opinion, But I don't know if the requirements agree ... 
> Otherwise, if the activity must  be related to INVITE 
> sessions only, we could rephrase with "the callee starts an 
> outgoing communication or accepts an incoming communication".
> 
> > - A message toward the caller about state change of the callee is 
> > missing
> What about:
> 
> The CCBS/CCNR simulation service should be able to deliver a 
> communication to the caller, when the callee becomes free.
> 
> > - Are multiple request possible for CCNR as with CCBS?
> Yes, so the introduction could simply change into:
> 
> It is possible for the caller to request several 
> communications to be under the CCBS/CCNR requested status. 
> Also the callee can be subject to several CCBS/CCNRS 
> communications from different callers. Additionally, the 
> service provides queue management to arbitrate several 
> CCBS/CCNR requests to the same callee.
> 
> > - Is it possible for a caller to have simultaneous CCBS and 
> CCNR requests?
> It is technically possible, towards different callees 
> obviously. There's a limit on the total number of outstanding 
> CCBS and CCNR request. In  some country (Italy for instance) 
> this limit is 1, but in other it can be higher: so if the 
> limit is 3, you can have 2 CCBS and a CCNR, just to give an 
> example. Probably, this should be added in the service description.
> 
> > - If a CCBS / CCNR request is cancelled from the network, 
> should the 
> > caller be informed?
> 
> Actually that's not a requirement: in PSTN/ISDN there was not 
> such requirement (possibility?) here I believe we are free to choose.
> 
> Regards
> Silvia
> > -----Ursprüngliche Nachricht-----
> > Von: [e-mail] [mailto:sipping-tispan- 
> > [e-mail]] Im Auftrag von Miguel Garcia
> > Gesendet: Donnerstag, 1. September 2005 11:19
> > An: [e-mail]
> > Betreff: [Sipping-tispan] [CCBS/CCNR]
> > 
> > 
> > Hi:
> > 
> > with respect the added CCBS/CCNR requirements, I think something is 
> > still missing.
> > 
> > - 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 
> somethign like that.
> > - 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".
> > - Perhaps and explanation that the queue manager must be able to 
> > distinguish between "call in return to CCBS/CCNR free 
> indication" from 
> > regular calls. This is related to the "timeslot" concept as well.
> > 
> > Anyone with further information of the requirements, please comment.
> > 
> > /Miguel
> > 
> > --
> > Miguel A. Garcia           tel:[phone]
> > sip:[e-mail]
> > Nokia Research Center      Helsinki, Finland
> > 
> > 
> > _______________________________________________
> > Sipping-tispan mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> > _______________________________________________
> > Sipping-tispan mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 
> 
> 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 
> [e-mail]. Thank you 
> ====================================================================
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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