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

["Drage, Keith (Keith)" <[e-mail]>]

Joining in this thread at the point where I think it started going wrong.

As far as the called user is concerned there are two points where decision points can exist:

-	when the service is invoked, and the call is stacked at the B user
-	when the B user becomes free, the A user is recalled, and the resultant call is presented to B.

If you look at the ISDN stage 3 requirements for network B accepting the request, which I believe reflect the stage 1 requirements, we have the following:

"A request to activate CCBS to a given destination shall be accepted by network B and queued if:
- user B has subscribed to the given basic service; and,
- the limit on the number of CCBS requests to the given destination has not been exceeded (this limit is a network
provider option with a maximum value of 5); and,
- user B has not invoked a supplementary service which prohibits the activation of the CCBS supplementary
service against that destination; and,
- user B compatibility requirements are met."

The supplementary services that prevent invocation are not specified, and can be implementation specific. 

When the call completes, it appears to user B as any other call request, i.e. not specifically a CCBS call, although this information is known to the network of B because it has to be removed from queues and so on if it is successful.

I believe we should consider the issue as follows, following the precedent set by the ISDN service designers. If the CCBS call should fail because the called user does not require this type of call to be a CCBS request, then that should be performed at time of CCBS request, e.g. if the calling user is on a black list of telemarketeers or has not provided an identity, or whatever.

If the call should fail for the same reason as any other incoming call, e.g. the user no longer has a terminal registered with a compatible set of media capabilities, then that obviously takes place additionally at the time the CCBS call is made.

As Sebastien has already correctly stated, queued CCBS requests do not block any other incoming call, except at for the time that the B user has insufficient resources to deal with the incoming call. These are normal things like some terminals not being able to handle two incoming calls at once.

regards

Keith



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Paul Kyzivat
> Sent: 28 September 2005 15:36
> To: Michael Hammer (mhammer)
> Cc: Tessa Silvia; [e-mail]
> Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> 
> 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
> 

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