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

[Tessa Silvia <[e-mail]>]

Hi Mike and all,
comments inline.

> Why does Italy limit the queue to 1?  Is this some silly regulation? 
Eh eh, I do not know the exact reason, but I guess it went like this:
CCBS has a distinctive ringing, only 1, PSTN phones had no display. You hear that ringing, you know who you were calling. If you had more contemporary CCBS request, you would not know who's on the line (Italian latin lovers could get into troubles... ) 

Sorry, back to the point: the limit must be locally configurable.
	
>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.

Exactly, I believe the requirement is for the network to control the limit.
For the user to control the limit would be an enhancement, appreciable enhancement, but not a requirement on the first base, am I right ?
 
> 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.

You are definitely right, but in PSTN all the queue information was in the network only, so, if a user wants to know how is queue was, he picked up the phone and asked the network.... old times, I know :( 

In order to consider this, requirement 4 should be slightly changed and splitted into two different requirements:

   	+ There must be a mechanism whereby CCBS/CCNR request initiators can check and cancel their CCBS/CCNR subscription.
	+ There must be a mechanism whereby "the network" can suspend, resume and cancel CCBS/CCNR subscription .

I know it's not exactly what you were saying: being notified of a ccbs subscription cancelled by the network is not a requirement in the PSTN and NGN specification, but again, an appreciable enhancement. 

I'm getting in trouble here : how are we supposed to proceed ? Do this kind of enhancements need to be written as requirements or will they come up through common sense while dealing with the solution ?  
Personally I would write in the document only the strict TISPAN requirements, then, while elaborating a solution, it will get more advanced and general purpose, but what do the other ones here say ?

Silvia



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


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