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

["Schmidt, Christian" <[e-mail]>]

CCBS/CCNR are features of the caller only, so the callee never 
have to pay for this.

Priority of CCBS/CCNR call does not mean, that normal calls are not
offered to the callee at all, only with lower priority. What this
mean in practice is implementation choice.

But on one thing I agree, the callee should have the choice, to
allow / disallow CCBS/CCNR calls with him as callee in general.
Would this help?

Christian



-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Paul Kyzivat
Gesendet: Dienstag, 27. September 2005 23:28
An: Michael Hammer (mhammer)
Cc: Tessa Silvia; [e-mail]
Betreff: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f


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

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