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

[Paul Kyzivat <[e-mail]>]

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

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

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