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

Paul,

I have been trying to avoid making a distinction between whether the
feature is implemented in the client or in some network element acting
on behalf of the client.  Rather, I was trying to discern what element
belong to the originating versus terminating "halves" of the "call
model" as there could be billing implications to which direction the
INVITE is being sent. Both originating and terminating sides have roles
to play.

Also, whereas in the PSTN some of the indications are embedded in call
control messages and others are sent via TCAP transactions, I am
wondering whether in the IP domain, this "scheduling of both parties
free" can be done prior to the INVITE transaction being launched.  I'm
thinking that avoiding getting the heavier INVITE train moving (media,
QoS, and accounting load), until you know a call is likely to go through
might save the voice hosts wasted work.

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Friday, September 02, 2005 11:27 AM
> To: Michael Hammer (mhammer)
> Cc: Tessa Silvia; Miguel Garcia; sipping-tispan@ietf.org
> Subject: Re: [Sipping-tispan] [CCBS/CCNR]
> 
> 
> 
> Michael Hammer (mhammer) wrote:
> 
> >>The requirement is not strictly for the caller to be 
> notified of the 
> >>callee status, nor for him to setup the call, in my opinion 
> it  should 
> >>just be:
> >>
> >>  The CCBS/CCNR simulation service should be able to deliver a 
> >>communication to the caller, when the service-specific condition 
> >>related to user state is met. Any communication performed 
> as a result 
> >>of a CCBS/CCNR should be distinguishable from regular calls.
> > 
> > Similar to above, I don't see this as the network or the 
> called party 
> > initiating the communication.
> 
> I believe the tispan assumption is that there is a network 
> entity acting on behalf of the caller, and another acting on 
> behalf of the callee.
> If you believe that the feature can result in any registered 
> caller phone ending up connected to any registered callee 
> phone, then you probably do need a mechanism of this sort to 
> achieve that. (Possibly you could get rid of the caller 
> network entity, but if so then the caller would have no state 
> remembering that it has invoked the service.)
> 
> > I think the essence is for the two
> > parties to share information about the:
> > 
> > 1) desire of calling party to be queued
> > 2) willingness of called party to queue caller,
> > 3) ability of calling party to notify called party of temporary 
> > inability to call (suspend),
> > 4) ability of calling party to notify called party of return to 
> > ability to call (resume),
> > 5) called party ability to select and notify "your turn" to a 
> > specified caller from the queue,
> > 6) called party ability to revoke caller "turn" and select 
> new caller,
> > 7) ability of calling party to request removal from queue,
> > 8) ability of called party to remove caller from queue and notify 
> > caller.
> > 
> > Bottom line, get both to the point where they know the 
> other is ready 
> > to communicate.
> 
> The above seems like a pretty good list.
> 
> 	Paul
> 
> 

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