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

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

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:[e-mail]] 
> Sent: Tuesday, September 27, 2005 7:37 AM
> To: Michael Hammer (mhammer)
> Cc: Schmidt, Christian; Tessa Silvia; [e-mail]
> Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Mike, see inline comments.
> 
> [e-mail] 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:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 

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