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

[Miguel Garcia <[e-mail]>]

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