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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 27 Sep 2005 15:44:56 -0400

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?

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?

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.

Arguments to the effect that ETSI ETS XXX didn't think of this are
unpersuasive.  The logic of the requirements should stand alone.

I may be unclear about how many actors are involved here (2, 3, 4?), but
hopefully this will be sorted out.

Cheers,
Mike

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Tuesday, September 27, 2005 7:37 AM
> To: Michael Hammer (mhammer)
> Cc: Schmidt, Christian; Tessa Silvia; [email-masked]
> Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Mike, see inline comments.
> 
> [email-masked] wrote:
> 
> 
> > 
> > The behavior of the terminating caller should be based on 
> the operation and policy of the terminating user, who should 
> have the option to reject such a request.  The current 
> wording seems vague on this point.  How about:
> 
> I am afraid that TISPAN does not have a requirement to give 
> the possibility of the callee to reject a CCBS request. By 
> reading ETSI ETS 300 357 I didn't find such requirement.
> 
> Since this document covers the Input requirements from 
> TISPAN, I am afraid we cannot write that requirement on the document.
> 
> > 
> > REQ-CCBS/CCNR-yy: If the callee accepts invocation of a 
> CCBS service, 
> > other terminating calls to this callee should be treated as 
> though the callee was already busy.
> 
> More or less... the text is fine if it is worded with respect 
> the caller:
> 
> "If the caller accepts a CCBS recall, other terminating calls 
> towards the callee should be treated as if the callee were 
> already busy".
> 
> Note that this requires to add a definition of the "CCBS 
> recall", which dependes on "CCBS call":
> 
> CCBS call: a communnication generated by the network 
> connecting the caller to the callee resulting from the 
> callers' acceptance of a CCBS recall.
> 
> CCBS recall: an indication informing the caller that the 
> network is ready to initiate a CCBS call to the callee and 
> that the network is awaiting a response to this indication.
> 
> How about that?
> 
> > 
> > Note, there are a number of depedencies (feature 
> interactions) here.  Callee could be capable of receiving 
> multiple calls, may have forwarding on busy set, etc.
> 
> True... for all services. We don't discuss service 
> interaction in the draft, unless we see a need for protocol 
> development.
> 
> /Miguel
> 
> > 
> > Mike
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Sep 2005 17:27:45 -0400

I agree with mike. Especially, I think it is important to be clear about 
  what is the responsibility of a service operating for the caller and 
what is the responsibility of a service operating for the callee. It 
might be best to model this as two services.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 28 Sep 2005 12:30:32 +0300

Hi Mike:

Inline discussion.

> requirements seem to assume that the CCBS is a service of the caller.

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.

> 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.

> reject a Subscription request to dialog state.  I don't think that holds

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.

> 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.

> hopefully this will be sorted out.

BR,

         Miguel