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

["Elwell, John" <[e-mail]>]

Keith,

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

John

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[e-mail]] 
> Sent: 06 September 2005 11:55
> To: 'Paul Kyzivat'
> Cc: [e-mail]
> 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.

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