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

["GARCIN Sebastien RD-CORE-ISS" <[e-mail]>]

Mike,

I fully agree that this is an issue we need to consider. However, the scenario you are describing is already taken care of by existing CCBS service logic. In the PSTN, upon determination that the callee has become free, the destination exchange starts a timer in order for the callee to have a chance of passing calls before being "CCBS-recalled". 

This timer is known as the "Destination B Idle Guard Timer" and should last between 0 and 15 seconds (see Q.733)

This behavior will of course be simulated in case of SIP.   

Regards
sebastien

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Michael Hammer (mhammer)
Envoyé : mercredi 28 septembre 2005 16:15
À : Miguel Garcia
Cc : Tessa Silvia; [e-mail]
Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

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