> > Very much related to that, ccbs has an effect of 
> introducing work in one 
> > domain (the one of the callee) that primarily (if not exclusively) 
> > benefits the other (the one of the caller). This provides 
> an unfortunate 
> >  negative incentive for implementing this in a callee 
> domain. I think we 
> > need to take care to minimize the amount of work required on the 
> > callee's side to support this. So for example, I am reluctant to 
> > introduce requirements to do things like suspend/resume, as these 
> > introduce additional work and state on behalf of the callee's agent.
> 
> While I agree that it is important to consider what the 
> incentives are 
> for implementing this stuff, I don't think this should be viewed as 
> primarily benefiting the caller at the expense of the callee. 
> At least 
> not if this is considered an *optional* feature at the callee.
> 
> A callee will offer this capability if he considers it advantageous - 
> namely if he considers the incoming calls to his benefit, and missing 
> them to be a loss. If the callee doesn't view incoming calls 
> that way he 
> is free to omit the feature.
> 
> To the caller who wants to get through, there are various potential 
> solutions. One is to simply repeatedly reattempt the call. 
> This can be 
> done manually by the UAC user, but it can also be implemented 
> in the UAC 
> itself.
> 



I agree that at the end of the day there is a interest of the caller as well as 
of the callee to get a failed call completed as soon as possible. Especially 
business users set a high value on reducing the average waiting time for their 
customers when they are busy. They don't want many redials to be started, which 
could mean their most important customer is the unlucky one who has to wait the 
longest until his redial succeeds.

And if a callee decides that CC is offered to the caller (I think regarding 
policies we are much more flexible than it was/is in the PSTN), he will also be 
interested that CC runs in the most effective way. The effectiveness of course 
is increased if busy callers don't have to be considered for CC recall 
processing, for which they have to be suspended.


Because of this I still think sus/res is an important feature for CC. The 
question is, is it important enough to describe it in the basic CC draft? Or, 
like we have talked about in Dublin, is it better to have it in a seperate 
draft, describing enhanced CC features (needed e.g. for 3GPP)?


BR, Martin





_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss

Reply via email to