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

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

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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tessa Silvia
> > Sent: Friday, September 02, 2005 7:20 AM
> > To: [email-masked]
> > 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: [email-masked] [mailto:sipping-tispan-
> > > [email-masked]] Im Auftrag von Miguel Garcia
> > > Gesendet: Donnerstag, 1. September 2005 11:19
> > > An: [email-masked]
> > > 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:+358-50-4804586
> > > sip:[email-masked]
> > > Nokia Research Center      Helsinki, Finland
> > >
> > >
> > > _______________________________________________
> > > Sipping-tispan mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > >
> > > _______________________________________________
> > > Sipping-tispan mailing list
> > > [email-masked]
> > > 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
> > [email-masked]. Thank you
> > ====================================================================
> >
> > _______________________________________________
> > Sipping-tispan mailing list
> > [email-masked]
> > 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
[email-masked]. Thank you
====================================================================

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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Sep 2005 11:55:11 +0100

As far as I can tell from the ISDN service descriptions, the situation at user A (i.e. the invoker of the CCBS/CCNR service) has not been explicitly covered.

At the B user, a user with a waiting call is regarded as busy, and I would expect the situation at the A user to be regarded in the same manner.

My view of this service has always been that from the viewpoint of the A user, it is an instruction to establish the call at the convenience of the B user and the network. If the A user has other priorities on establishing the call then CCBS/CCNR is not the service, and has to adopt other mechanisms. Therefore if the A user has a waiting call, the network priority is to get that waiting call, consuming bearer resources, dealt with rather than complete the CCBS/CCNR potential call.

regards

Keith

> [mailto:[email-masked]]On Behalf Of Paul Kyzivat
> Sent: 05 September 2005 22:29
> To: Miguel Garcia
> Cc: Tessa Silvia; [email-masked]
> Subject: Re: R: [Sipping-tispan] [CCBS/CCNR]
> 
> 
> 
> 
> Miguel Garcia wrote:
> > Tessa Silvia wrote:
> > 
> >> 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 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?
> 
> 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
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2005 13:49:08 +0100

Keith,

Just catching up on this mailing list, so sorry about delay. In-line.

John

> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: 06 September 2005 11:55
> To: 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: R: [Sipping-tispan] [CCBS/CCNR]
> 
> As far as I can tell from the ISDN service descriptions, the 
> situation at user A (i.e. the invoker of the CCBS/CCNR 
> service) has not been explicitly covered.
> 
> At the B user, a user with a waiting call is regarded as 
> busy, and I would expect the situation at the A user to be 
> regarded in the same manner.
> 
> My view of this service has always been that from the 
> viewpoint of the A user, it is an instruction to establish 
> the call at the convenience of the B user and the network. If 
> the A user has other priorities on establishing the call then 
> CCBS/CCNR is not the service, and has to adopt other 
> mechanisms. Therefore if the A user has a waiting call, the 
> network priority is to get that waiting call, consuming 
> bearer resources, dealt with rather than complete the 
> CCBS/CCNR potential call.
[JRE] All this talk about the network seems totally irrelevant to me in the
context of user A. It should be user A's decision whether to accept or defer
the opportunity to complete the call when he receives notification that call
completion is possible. This should be independent of whether A has other
ongoing or waiting communications at the UA concerned. Depending on UA
capabilities (outside the scope of SIP) the user may be able to interrupt
ongoing communications in order to complete the call, and he will do this
according to his own assessment of their relative importance.