RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

["Michael Hammer \(mhammer\)" <[e-mail]>]

Miguel,

Even with the stacking limit of 5, I still don't want to have to answer
and hangup on 5 telemarketers to get to answer my friends phone call.  I
accept that TISPAN can propose something bad, just don't expect it to
stand in the final analysis.  I don't buy the argument that because the
caller paid more, it is in the interest of the callee to listen to him.
I think there is room for improvement on the experience of the
terminating callee, and that there needs to be balance here between the
interests of the caller and callee.

Mike
 

> -----Original Message-----
> From: Miguel Garcia [mailto:[e-mail]] 
> Sent: Wednesday, September 28, 2005 5:31 AM
> To: Michael Hammer (mhammer)
> Cc: Schmidt, Christian; Tessa Silvia; [e-mail]
> Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Hi Mike:
> 
> Inline discussion.
> 
> Michael Hammer (mhammer) wrote:
> 
> > Miguel,
> > 
> > I think there is still a little bit of schizophrenia in the 
> > requirements.  I assume that a server is acting on behalf of either 
> > the caller or the callee, but not both because each could 
> be served by 
> > a different host, domain, or organization.  The first requirement 
> > seems to assume that the CCBS is a terminating service of 
> the callee.  
> > Other requirements seem to assume that the CCBS is a 
> service of the caller.
> > Which is it?
> 
> Both. It has been demonstrated that CCBS is a service that 
> requires cooperation of both the originating and terminatine 
> service providers. 
> This cooperation is mostly required to manage queues of both 
> the caller and callee, and to manage susped/resume states.
> 
> > 
> > This can be modeled as a feature of the caller only, the 
> callee, or a 
> > feature interaction between two services of the caller and callee.
> > Note, that once you involve a service that serves a callee into the 
> > picture, then that server better keep straight what master 
> it serves.
> > 
> > I find it problematic that it is suggested that as a callee 
> I should 
> > be paying for a service, yet constrained by some other 
> caller that I 
> > perhaps have no relation to, or worse is belligerant 
> towards me.  What 
> > stops some collusion of callers from stacking up CCBS 
> requests to the 
> > point where I can not receive any incoming calls?
> 
> With respect the charging aspects, I don't know much about 
> it, and they are mostly outside the scope of the 
> specification. It may happen that you pay only for 
> successfully completed calls. Or, as I have noticed in some 
> countries, the service is offered for free, since it is the 
> interest of the operator that you complete the call, and at 
> that time, you are charged.
> 
> The other aspect you are discussing relatest to the security 
> aspects of the service, or, in other words, a malicious 
> usage. I believe the PSTN/ISDN CCBS service provides for a 
> maximum number of stacked CCBS requests for a given user (it 
> sounds to me that the number is 5), so that if the limit is 
> reached, CCBS requests are rejected. In any case, there is no 
> protocol impact, just an implementation of a policy to avoid 
> misuse of the service.
> 
> 
> > 
> > I think that this whole mechanism may come down to whether a callee 
> > accepts or rejects subscriptions to their dialog state.  To 
> say that a 
> > callee can not reject the CCBS request is akin to saying 
> that he can 
> > not reject a Subscription request to dialog state.  I don't 
> think that 
> > holds water.
> 
> No, no, I didn't say that the callee cannot reject a 
> subscription request to the dialog state. I said that TISPAN 
> does not have such requirement. It does not mean that, if the 
> protocol allows it, the request can be rejected if the callee 
> desires it. But TISPAN does not have that requirement, so it 
> shouldn't be included in the TISPAN requirements document.
> 
> > 
> > Arguments to the effect that ETSI ETS XXX didn't think of this are 
> > unpersuasive.  The logic of the requirements should stand alone.
> 
> But as I said, these are the TISPAN requirements. Other 
> individual or organizations may have similar, complementary, 
> and hopefully non-contradictory requirements. I don't see a 
> problem with that approach.
> 
> > 
> > I may be unclear about how many actors are involved here 
> (2, 3, 4?), 
> > but hopefully this will be sorted out.
> > 
> > Cheers,
> > Mike
> > 
> > 
> 
> BR,
> 
>          Miguel
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan