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.

regards

Keith

> -----Original Message-----
> From: sipping-tispan-bounces@ietf.org
> [mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Paul Kyzivat
> Sent: 05 September 2005 22:29
> To: Miguel Garcia
> Cc: Tessa Silvia; sipping-tispan@ietf.org
> 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
> 
> _______________________________________________
> Sipping-tispan mailing list
> Sipping-tispan@ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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