[Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

Jonathan Rosenberg <jdrosen@cisco.com> Thu, 02 November 2006 00:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQCt-0004Fm-ID; Wed, 01 Nov 2006 19:13:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQCr-0004B2-Bi for sipping@ietf.org; Wed, 01 Nov 2006 19:13:17 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfQ0H-0000Iq-FL for sipping@ietf.org; Wed, 01 Nov 2006 19:00:21 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2006 16:00:14 -0800
X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="349452976:sNHT8019287164"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA200Dr7007308 for <sipping@ietf.org>; Wed, 1 Nov 2006 16:00:13 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA200Din021418 for <sipping@ietf.org>; Wed, 1 Nov 2006 16:00:13 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:00:13 -0800
Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:00:12 -0800
Message-ID: <4549350B.1080905@cisco.com>
Date: Wed, 01 Nov 2006 19:00:11 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF Sipping List <sipping@ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Nov 2006 00:00:12.0974 (UTC) FILETIME=[DEA2ACE0:01C6FE11]
DKIM-Signature: a=rsa-sha1; q=dns; l=2356; t=1162425613; x=1163289613; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:comments=20on=20draft-roach-sipping-callcomp-bfcp-00; X=v=3Dcisco.com=3B=20h=3DybzQviRjgwurG77z09lLjHhAX3A=3D; b=Oy3MDu1FPQ0W/rWH9MOEfUpUA/KX3o46rvxCqKLdd7+PTwPzhbr76+kLQhpr+MAoSqdvG+Q1 nUX/uOgVObxGIe49T85TC2WDwwJgbJQjVrj9JNBn+vWxSTpIvmojBs5u;
Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Subject: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org

This is a very interesting draft. Neat idea to use BFCP to manage the 
queue.

Its not clear to me that this mechanism works well in the face of 
forking. Seems like you could end up with disparate queues for each of 
my phones. What you are really after is the state of the user (i.e., 
AOR) and not their devices. This seems to make it problematic to 
implement this in the UA at all. I understand your intention is that 
this be in a server in the network; but if it only works in that case it 
needs to be called out.

Similar issues arise when the originating user has multiple devices. So 
if I call you from phone 1, and later you are available, does the 
ringback happen only at phone 1 or all of my phones? Seems like the 
latter is much more desirable. That too implies that a UA-based solution 
on the originating side has some problems.

There is clearly a relationship between all of this and presence; I 
think you need to call that out.

On whether BFCP is the right thing or not for this problem, I'm not 
sure. In one sense, you could characterize this as really a problem with 
RFC3265 in general; that for certain event packages, notification of an 
event to all watchers can cause them to take actions that result in a 
further change to that same state. This is a race condition.

An alternative way to model the queueing discipline to fix the race is 
through a generic capability in RFC 3265, which sends out notifications 
gradually. You need to be careful to not end up embedding queue control 
commands in SUBSCRIBE as you have pointed out previously. However, 
nothing stops a notifier from sending out notifications one at a time. 
That would not permit you to do things like pause your position in queue 
or similar features, but 3265 sometimes feels to be more on-target for 
this service.

I share John's concerns as to whether this really interoperates with the 
PSTN. Perhaps if you had some call flows demonstrating it, this would help.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP