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

From: "Jesske, R" <[email-masked]>
Date: Thu, 29 Sep 2005 06:18:34 +0200

Dear Miguel and Mike,
The ETSI specification is based on Q.733.3. Within this specification it is described how a CCBS call can be rejected by the user B. 

...For example if the destination local exchange knows that the CCBS is forbidden on the destination B user, then the diagnostic field shall be set to "CCBS not possible". Otherwise the diagnostic field shall be set to "CCBS possible"....

So this describes if user be does not allows a CCBS call. This is a little hidden within the spec. But it is stated. So we can write  such a requirement. So either we need such an indication  "CCBS possible" or the CCBS request shall be rejected by the AS of the callee.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Miguel Garcia
> Gesendet: Dienstag, 27. September 2005 13:37
> An: [email-masked]
> Cc: Tessa Silvia; [email-masked]
> Betreff: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> 
> Mike, see inline comments.
> 
> [email-masked] 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:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Sep 2005 08:53:26 -0400

> So this describes if user be does not allows a CCBS call. This is a little hidden within the spec. But it is stated. So we can write  such a requirement. So either we need such an indication  "CCBS…

I can't quite tell from this description, but it sounds like this covers 
the case where CCBS is universally forbidden at destination B. Does it 
also cover the case where user B decides on a case by case basis not to 
accept a CCBS from a particular caller, at a particular point in time?

(This would require user B to be made aware of the CCBS when it is 
queued, rather than only when user B is alerted for the resulting call. 
Its not something that would easily be done on a black phone, but might 
be considered similar to call waiting.)

	Paul