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

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

Silvia,

A few cautions here:

First, I tried to not write a requirement that depended on whether the feature was implemented in the end-user terminal or in some voice intermediary host provided by the service provider.  It should be possible to design a solution that can be done either way.  And thus the local policy gets implemented wherever the feature is implemented, i.e. may be done in the terminal or the SP node.

Second, I was trying to distill out of the existing PSTN-based feature the essence of what was needed.  While I think it should be backward compatible, that doesn't mean that it should not improve upon the former in the IP domain.

Third, I would avoid the term "network".  As I have been told by the IP router guys, and has been brought up on other IETF mail lists, most view network as meaning the data transport network only, and I don't think that is where you were intending voice features to operate.

Cheers,
Mike


> -----Original Message-----
> From: Tessa Silvia [mailto:[e-mail]] 
> Sent: Monday, September 05, 2005 7:26 AM
> To: Michael Hammer (mhammer); [e-mail]
> Subject: R: [Sipping-tispan] [CCBS/CCNR]
> 
> 
> 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