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

[Paul Kyzivat <[e-mail]>]

I agree with mike.

In the end, to the callee there is little difference between somebody 
queued for CCBS and somebody ringing or queued on call waiting. If you 
have a phone with a good enough UI, it would probably be best to see a 
list of everyone waiting to talk to you, and to pick among them, whether 
that means they need to be rung back or not. That of course demands a 
better UI than a black phone. If you have a black phone, then you need 
some other plan.

It seems that when designing the call waiting service, somebody decided 
that you could only deal with two calls at a time. But for CCBS somebody 
decided otherwise. Seems pretty braindead to me.

	Paul

Michael Hammer (mhammer) wrote:
> Miguel,
> 
> Even with the stacking limit of 5, I still don't want to have to answer
> and hangup on 5 telemarketers to get to answer my friends phone call.  I
> accept that TISPAN can propose something bad, just don't expect it to
> stand in the final analysis.  I don't buy the argument that because the
> caller paid more, it is in the interest of the callee to listen to him.
> I think there is room for improvement on the experience of the
> terminating callee, and that there needs to be balance here between the
> interests of the caller and callee.
> 
> Mike
>  
> 
> 
>>-----Original Message-----
>>From: Miguel Garcia [mailto:[e-mail]] 
>>Sent: Wednesday, September 28, 2005 5:31 AM
>>To: Michael Hammer (mhammer)
>>Cc: Schmidt, Christian; Tessa Silvia; [e-mail]
>>Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>
>>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
> 

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