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

From: [email-masked]
Date: Mon, 26 Sep 2005 09:52:54 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Schmidt, Christian
> Sent: Monday, September 26, 2005 8:17 AM
> To: Tessa Silvia; Miguel Garcia
> Cc: [email-masked]
> Subject: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Hi
> comments inline
> Regards, Christian
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Tessa Silvia [mailto:[email-masked]] 
> Gesendet: Montag, 26. September 2005 13:20
> An: Miguel Garcia; Schmidt, Christian
> Cc: [email-masked]
> Betreff: R: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> 
> Hi,
> Comments inline.
> 
> > > REQ-CCBS/CCNR-xx: The caller must be able to invoke CCBS / CCNR
> service.
> > 
> > Yes, sure... I think this is an obvious requirement for 
> each service,
> > isn't it. Do you think we need to state it explicitly?
>  
> I agree, we probably don't need to state it esplicitely.
>  
> Christian: The requirement document should list all 
> requirements, especially
> the requirements with potential influence to SIP. Because, 
> this is valid
> for REQ-CCBS/CCNR-xx, I would include it in the spec.
> 
> 
> > 
> > >
> > > REQ-CCBS/CCNR-yy: If a CCBS service is invoked for a callee, other
> > > terminating calls should not be offered to this callee.
> > 
> > Is this a true behaviour of the service? If someone invokes CCBS on
> me,
> > he will block automatically all my other calls to me? This 
> sounds like
> a
> >   policy that certain network might have, but sounds a bit weird to
> > write this as a requirement. Can anyone else comment?
> 
> We have already have REQ 12 stating that
> 	 Any communication performed as a result of the execution of a
> CCBS/CCNR request should be distinguishable from regular 
> communications.
> 
> So,  all terminating call are "distinguishable" and any 
> policy a network
> might have could be easily based on this, without further 
> requirements.
> Other views ?
> 
> Christian: I see, perhaps you can add a short explanation for 
> this purpose:
> 	 Any communication performed as a result of the execution of a
> CCBS/CCNR request should be distinguishable from regular 
> communications.
> This can be used to priorize CCBS/CCNR calls towards the callee.
> What do you think?

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:

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.

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.

Mike

> 
> Regards
> Silvia
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> 
> ====================================================================
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please send an e_mail to 
> [email-masked]. Thank you
> ====================================================================
> 
> _______________________________________________
> 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: Miguel Garcia <[email-masked]>
Date: Tue, 27 Sep 2005 14:36:36 +0300

Mike, see inline comments.

> 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…

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.

> 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

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland