Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-02.txt
Paul Kyzivat <pkyzivat@cisco.com> Tue, 10 June 2008 20:09 UTC
Return-Path: <bliss-bounces@ietf.org>
X-Original-To: bliss-archive@optimus.ietf.org
Delivered-To: ietfarch-bliss-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188EF3A6908; Tue, 10 Jun 2008 13:09:48 -0700 (PDT)
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330903A6908 for <bliss@core3.amsl.com>; Tue, 10 Jun 2008 13:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.589
X-Spam-Level:
X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHbOR67g7m9c for <bliss@core3.amsl.com>; Tue, 10 Jun 2008 13:09:46 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 77A333A68F0 for <bliss@ietf.org>; Tue, 10 Jun 2008 13:09:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,619,1204531200"; d="scan'208";a="40157745"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2008 13:09:56 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5AK9uQO025197; Tue, 10 Jun 2008 13:09:56 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5AK9oZ9003016; Tue, 10 Jun 2008 20:09:56 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 16:09:55 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 16:09:55 -0400
Message-ID: <484EDFC0.7080803@cisco.com>
Date: Tue, 10 Jun 2008 16:10:40 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
References: <20080524174501.EA40C3A6A5E@core3.amsl.com> <48386B2D.8070407@cisco.com> <1ECE0EB50388174790F9694F77522CCF1719E40B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1719E40B@zrc2hxm0.corp.nortel.com>
X-OriginalArrivalTime: 10 Jun 2008 20:09:55.0386 (UTC) FILETIME=[F33151A0:01C8CB35]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4595; t=1213128596; x=1213992596; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[BLISS]=20I-D=20Action=3Adraft-ietf-bli ss-ach-analysis-02.txt |Sender:=20; bh=2FJFf6y/2n5Bsulf4nstdR9kypR80VT9qLVB/cxtpH8=; b=mny8n7z/WfW3i0NPoUecgbUeBhOESHkO77slnMzrUF1LfH6XpGT444FcbN qgekMv8qTfPWFJcE+epo3NmfBDEsZfhW9KSNq780es00GZAoQEdonejAB4rL apGj8ArSYy;
Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: bliss@ietf.org
Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-02.txt
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: bliss-bounces@ietf.org
Errors-To: bliss-bounces@ietf.org
Sorry I haven't responded to this. More inline. Francois Audet wrote: > > >> -----Original Message----- >> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >> On Behalf Of Paul Kyzivat >> Sent: Saturday, May 24, 2008 12:23 >> To: bliss@ietf.org >> Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-02.txt >> >> This looks pretty good to me. I wish I had had time to >> participate in the work. I have just a few comments: >> >> - I have difficulty figuring out how to selectively deal with >> call waiting. If a UA could answer a call, even though it >> already has a call in progress, and would be willing to do so >> if needful, how can it defer to the proxy? Once it has >> rejected the call, it can't later answer it. >> And if the proxy, based on policy, later decides to present >> the call again, I don't see how the UA would know to answer >> it this time. > > I'm not sure I get your point. > I don't believe we intended this proxy stuff to apply to call waiting. Well, there seem to be places in the text that mention possible conflicts between the UAS and the proxy in handling of call waiting. For example: - section 3.1: For example, if a phone determines it is busy and returns a 302 response code to forward the call elsewhere or performs "call waiting" action, this might prevent the proxy taking whatever action it would have taken on receipt of a 486 response. - section 5.1: For a UA to defer to a proxy, it should report any conditions back to the proxy (e.g., by means of a suitable response to the INVITE request) rather than taking unilateral action such as redirecting or placing the call in a waiting state. In other words, it should be possible to turn off ACH at a UA. Consider a case where there are multiple UAs (extensions) to which an incoming call is parallel forked. And assume that each of them is capable of unilateral handling of multiple calls via a mechanism that is like call-waiting. If one extension has a call active and another is idle then it may be preferable to ring the idle one first, rather than have the first one pick up the second call. But to do so will require that the proxy have some control over this. How would the UA defer to the proxy, indicate that it is busy, and yet still indicate that it *could* take another call if need be? And if it could so indicate, how could the proxy later deliver the call to it again and indicate that it should this time take the call? >> - What does it mean to be busy? (This is related to prior >> point.) Being on one call does not necessarily mean inability >> to take another. Nor does *not* being on a call mean you are >> not busy. In some cases it is literally possible to manage >> two calls simultaneously. (E.g. when they are IM sessions.) >> In other cases it is a matter of time division multiplexing >> between two sessions, so that the callers will realize they >> don't have full attention of the callee. Sorting this all out >> wold seem to be a complex policy problem, requiring a lot of >> data that won't easily be available to a proxy. > > The point of the draft is not for the proxy to decide that you > are busy. > > It's for the UAS to indicate to the proxy that it's busy. > > Then it describes the subtleties of what busy means (600 vs > 486, one branch vs all branches, can it go to voicemail, etc.). > > Basically, it means the user declares to be busy. My question was intended to apply in the scenario I just spelled out above. The point being that "busy" isn't necessarily a binary attribute. Rather there can be degrees of busy-ness. 486 isn't currently capable of expressing the nuances. >> - rejection scope: It seems that there could be useful to >> have two different degrees of local rejection. As currently >> described in the draft it is proxy policy that determines if >> local rejection cancels delivery to other local UAs or not. >> But that could be something that might be desired as a per >> call option to the user on the UA. (The distinction between >> stopping only this extension from ringing, or stopping all >> extensions from ringing.) > > I think doing this on a per call basis could be quite error-prone > and complicated. > > And it would require new protocol. > > The reason the "degrees" are set on the proxy side in this draft > is exactly to avoid those problems. Whatever. I don't feel strongly about this. Paul _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss
- [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-… Internet-Drafts
- Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analy… Paul Kyzivat
- Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analy… Francois Audet
- Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analy… Elwell, John
- Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analy… Paul Kyzivat