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

> -----Original Message-----
> From: Tessa Silvia [mailto:Silvia.Tessa@TILAB.COM] 
> Sent: Monday, September 05, 2005 7:27 AM
> To: Michael Hammer (mhammer); Miguel Garcia; sipping-tispan@ietf.org
> Subject: R: [Sipping-tispan] [CCBS/CCNR]
> 
> Inline.
> > >
> > > Any time a user does not accept a session returned by 
> CCBS within a 
> > > given timeslot his place in queue is removed, unless he is busy.
> > 
> > First, I think the intent is still to have the CCBS 
> requestor initiate 
> > the call, since there may be costs associated with doing so.
> 
> There's no cost issue related to who is initiating the call 
> because the network is able to bill the caller regardless if 
> it is a first-party or a third-party call.

I'm not entirely convinced of this.  For argument's sake, let us assume
that the service is implemented using Subscribe/Notify and does not use
INVITEs.  Later, when the INVITE is transmitted from the original callee
to the caller (I know that sounds backwards but that is what is
proposed), the service provider(s) only see a call being originated in
that direction, and calling party pays, no?

I also get the sense, when you refer to "the network" in the singular,
that you are thinking that this works only in a single service provider
domain.  I think this should work when there are both originating and
terminating service providers.

> > 
> > Second, you suggestion may run into race conditions with the CCBS 
> > requestor attempting to send a suspend request, because 
> perhaps he had 
> > to answer another incoming call.
> 
> A CCBS subscription can be suspended if and only if the 
> caller is busy:
> the caller can not say "I'm going out for 5 minutes, I'll 
> suspend my ccbs subscription, and resume it when I get back". 
> The CCBS requestor can not suspend and resume a request: he 
> can only cancel it.

The caller goes busy in the originating SP.  How does the terminating SP
discover that?  Some indication is sent forward and the callee service
suspends that request.

> Does this exclude the race condition you mentioned ? If not, 
> could you explain a bit further? 

Simultaneously, the caller goes busy and sends indication forward, while
the callee becomes no longer busy and generates call back to the caller,
who then refuses it.  Not insurmountable, but seems cleaner to me if the
callee sends the free indication, waits for call or suspend, then moves
on accordingly.

> 
> > 
> > > Any time a user is busy when a session returned by CCBS is 
> > > delivered, he keeps his place in queue. Other users in queue, if 
> > > any, can be served.
> > > (this last scenario is known as "suspension")
> > >
> > > Would that be ok ?
> > 
> > How does the called queue manager know whether the caller 
> is busy or 
> > not?  I'm afraid these requirements are delving into the solution 
> > discussion, but I'm not sure if that is avoidable.
> 
> 
> I'm afraid as well, but I'll try to answer by rephrasing 
> requirement 1:
> Req 1 declares the need to monitor the callee, actually 
> there's also a need to monitor the caller....
> 
> 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 can't tell if UA is the correct term, what I want to say is 
> that it applies for both callee and caller.

UA is both.  UAC and UAS distinguish the caller and callee,
respectively, for the initial INVITE.

Mike

> 
> Regards
> Silvia
> 
> 
> 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 
> MailAdmin@tilab.com. Thank you 
> ====================================================================
> 

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