Re: [Sipping-tispan] [CCBS/CCNR]

Paul Kyzivat <pkyzivat@cisco.com> Fri, 02 September 2005 15:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDRd-0008Re-MR; Fri, 02 Sep 2005 11:27:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDRc-0008RW-OC for sipping-tispan@megatron.ietf.org; Fri, 02 Sep 2005 11:27:09 -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 LAA13633 for <sipping-tispan@ietf.org>; Fri, 2 Sep 2005 11:27:06 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDTn-0007KT-Sh for sipping-tispan@ietf.org; Fri, 02 Sep 2005 11:29:24 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Sep 2005 08:27:00 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j82FPxR0005499; Fri, 2 Sep 2005 08:26:51 -0700 (PDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 11:26:54 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 11:26:54 -0400
Message-ID: <43186F3E.2060904@cisco.com>
Date: Fri, 02 Sep 2005 11:26:54 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>
Subject: Re: [Sipping-tispan] [CCBS/CCNR]
References: <072C5B76F7CEAB488172C6F64B30B5E382E315@xmb-rtp-20b.amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Sep 2005 15:26:54.0394 (UTC) FILETIME=[BFB091A0:01C5AFD2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
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


Michael Hammer (mhammer) wrote:

>>The requirement is not strictly for the caller to be notified 
>>of the callee status, nor for him to setup the call, in my 
>>opinion it  should just be:
>>
>>  The CCBS/CCNR simulation service should be able to deliver 
>>a communication to the caller, when the service-specific 
>>condition related to user state is met. Any communication 
>>performed as a result of a CCBS/CCNR should be 
>>distinguishable from regular calls.
> 
> Similar to above, I don't see this as the network or the called party
> initiating the communication. 

I believe the tispan assumption is that there is a network entity acting 
on behalf of the caller, and another acting on behalf of the callee.
If you believe that the feature can result in any registered caller 
phone ending up connected to any registered callee phone, then you 
probably do need a mechanism of this sort to achieve that. (Possibly you 
could get rid of the caller network entity, but if so then the caller 
would have no state remembering that it has invoked the service.)

> I think the essence is for the two
> parties to share information about the:
> 
> 1) desire of calling party to be queued
> 2) willingness of called party to queue caller,
> 3) ability of calling party to notify called party of temporary
> inability to call (suspend),
> 4) ability of calling party to notify called party of return to ability
> to call (resume),
> 5) called party ability to select and notify "your turn" to a specified
> caller from the queue,
> 6) called party ability to revoke caller "turn" and select new caller,
> 7) ability of calling party to request removal from queue,
> 8) ability of called party to remove caller from queue and notify
> caller. 
> 
> Bottom line, get both to the point where they know the other is ready to
> communicate.

The above seems like a pretty good list.

	Paul

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