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

Miguel Garcia <Miguel.An.Garcia@nokia.com> Tue, 27 September 2005 11:47 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDvl-0000oh-VE; Tue, 27 Sep 2005 07:47:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDvj-0000ma-VF for sipping-tispan@megatron.ietf.org; Tue, 27 Sep 2005 07:47:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01542 for <sipping-tispan@ietf.org>; Tue, 27 Sep 2005 07:47:27 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKE2y-0002Oc-3b for sipping-tispan@ietf.org; Tue, 27 Sep 2005 07:54:57 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8RBjtg1004050; Tue, 27 Sep 2005 14:45:58 +0300
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 14:36:37 +0300
Received: from [127.0.0.1] ([172.21.35.84]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Sep 2005 14:36:36 +0300
Message-ID: <43392EC4.7060202@nokia.com>
Date: Tue, 27 Sep 2005 14:36:36 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: "mhammer@cisco.com" <mhammer@cisco.com>
Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
References: <072C5B76F7CEAB488172C6F64B30B5E395B7C0@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E395B7C0@xmb-rtp-20b.amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Sep 2005 11:36:36.0137 (UTC) FILETIME=[B7B1A190:01C5C357]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Cc: Tessa Silvia <Silvia.Tessa@TILAB.COM>, sipping-tispan@ietf.org
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Mike, see inline comments.

mhammer@cisco.com 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:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan