From bliss-bounces@ietf.org Mon Jul 02 18:31:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5UQy-0001SP-6c; Mon, 02 Jul 2007 18:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5UQw-0001SD-Dv for bliss@ietf.org; Mon, 02 Jul 2007 18:31:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5UQP-0007mp-AH for bliss@ietf.org; Mon, 02 Jul 2007 18:31:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jul 2007 18:31:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABwYiUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,489,1175486400"; d="scan'208"; a="64215373:sNHT26210698" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62MVGvR022493 for ; Mon, 2 Jul 2007 18:31:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l62MV46i017601 for ; Mon, 2 Jul 2007 22:31:16 GMT 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.1830); Mon, 2 Jul 2007 18:31:12 -0400 Received: from [10.86.241.79] ([10.86.241.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 18:31:12 -0400 Message-ID: <46897CB3.9050609@cisco.com> Date: Mon, 02 Jul 2007 18:31:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2007 22:31:12.0273 (UTC) FILETIME=[B1B5A010:01C7BCF8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1167; t=1183415477; x=1184279477; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20bliss@ietf.org; bh=4ZnVY9DTEcyotuifgT91SQz0uZKJltnWk8H2IKpe3fo=; b=lgPSAJfmfpznq9Plg3yVakZjGZ/HJ1edYu8zliuONWnrRH4tufcMzIsef2t+QQDgSE0G9xLP pwK1/srLvHPRX7Z/jV8eBgjP5SO3k7zox56LapSPAn51+XShUVF3QyNI; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [BLISS] BLISS problem statement draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I've submitted a draft that provides a problem statement around what BLISS is trying to solve, and defines a framework for solving it. It uses concrete examples the whole way through so we can be clear on what we are talking about. Until it appears in the archives, you can pick it up here: http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-statement-00.txt This is something I should have gotten out a month or so back, so that we could have used it as a context for discussion and draft writing in the remaining time. I apologize for getting this in just before the deadline - too late to be useful for anyone elses drafts. I think its really important that we discuss this draft and get agreement on it. Its really trying to define the process by which we will be doing our work. 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 03 18:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qSu-0003iI-3b; Tue, 03 Jul 2007 18:03:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qSt-0003i4-1o for bliss@ietf.org; Tue, 03 Jul 2007 18:03:19 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5qSs-0002wi-Ki for bliss@ietf.org; Tue, 03 Jul 2007 18:03:18 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l63M2AK18580; Tue, 3 Jul 2007 22:02:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Tue, 3 Jul 2007 17:01:24 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371155981A6@zrc2hxm2.corp.nortel.com> In-Reply-To: <46897CB3.9050609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft thread-index: Ace8+Mz1MY/YDrFeQ3eKpMHDSnrI4wAtPK6w References: <46897CB3.9050609@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Jonathan, Thanks for putting this together. A few comments though: A few comments on the CFNA example approaches. I know that you aren't trying to write a document to address CFNA, but since this document describes a template approach to for documenting features within BLISS I think it's important that the examples here reflect the type of discussion that we are looking for in the eventual BLISS RFCs. Section 3-3.1.3: - Although approach I could be used for CFNA, the fact that UA Y returned a 302 means that this could also be used to implement CFU as well (especially from the proxy's point of view). Essentially, you could have approach I and II or I and IV running concurrently for the same or different purposes where the text makes it sound like these are always discrete cases. - Figure 3 and 4 are the same but the scenarios are not. Figure 4 needs to be updated to reflect the text in section 3.1.3. - Section 3.1.4 seems more like a refinement on section 3.1.2 than a different approach from the standpoint of the CFNA behavior when the call is placed by UA X. Configuration of elements would seem to be out of scope would it not? Otherwise why would we not also consider variants of how UA Y came to know to forward the INVITE via 302 or proxy mode (approach I and III respectively)...it seems like it could be endless without a clear constraint. Another point to consider is that the web page in approach II could have configured the proxy via CPL as well, or the CPL in approach IV could have been delivered via SOAP to a web interface that dumped it into a common database with the proxy. Even though message 1 in approach IV is SIP, it's not limited to SIP, etc., and perhaps we should leave configuration out of scope initially, etc. Hopefully you see where I'm going with this: we need some sort of constraint here to limit discussion to something reasonable.=20 - Section 3.1.5.1 I'm not sure that assume is the best word here. People assume things, not machines. The user for UA Y should clearly not expect their calls to be forwarded to anywhere if they (or an administrator) never instructed any component of the system to take some sort of action on their behalf. If nobody implements a feature there can be no interoperability, and without interoperability there can be no failure to interoperate. Right? - Section 3.1.5.2 Again, I think we would need to show the cases where this isn't user error. If the user went off and told the proxy to forward their calls after X rings, and then told their UA to do the same then this is clearly (to me) out of scope for a BLISS feature discussion. The protocol is working fine, the features are working fine, nothing is failing here except the user's understanding of the system or their memory as to what they have told the system to do.=20 In a general, I believe you are going to commonly find systems that (again using CFNA as the example here) offer a feature both at the network and at the device to ensure that the feature is available for all users. I don't think race conditions that arise due to duplicated features is de facto an issue that should be in scope (i.e. user behavior cannot be specified) unless they interact with each other in such a way that neither implmentation will work correctly if only one source for the feature is active at any given point in time. I know you talk about this more in section 5, but it sounds like we're looking to find the "best" way of implementing a feature where that widely results in one way. When a feature such as CFNA is "single-ended", meaning that there are no requirements on one of the two users involved in the feature, then having more than one way of doing something is likely to not cause an issue. If the feature is "double-ended", meaning that there are requirements placed not only on the device invoking the feature but the devices that the feature is managing as a result then you run into issues with having many ways to do the same thing. I believe this is a nuance that should be captured. - Section 3.1.5.3 This is a better argument for why some configuration may matter except that CPL could be delivered to the proxy by some other source. Essentially it's not the specific mechanism that's being used to configure the feature, but that there does not exist a means to enable the feature due to an implied interoperability requirement.=20 In general, I would expect most feature vendors to supply you with an alternative way to configure their features without requiring action on the client, but perhaps this needs to be stated more directly somewhere. Maybe include this implied configurability problem in section 5 somehow? - Section 4 "Allow Variability in Implementation" / "Support a Multiplicity - I know you probably meant it in the text, but I'd like to include it explicitly: wireless. The reason I believe this needs to be stated directly is because it's an environment where the links to the clients are much more unreliable than in most other environments, therefore, relying upon the client to take actions may not be feasible in all cases and more than one approach needs to be accounted for in the 'decision making process' within the Allow Variability in Implementation section. For instance, approach I does not work reliably in an environment where the client is not always-on and always-reachable. - I know ICE solves a number of issues, but you might want to update your XML template if you should create a -01 version of this document. :) Thanks again for putting a document together to review. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, July 02, 2007 5:31 PM > To: bliss@ietf.org > Subject: [BLISS] BLISS problem statement draft >=20 > I've submitted a draft that provides a problem statement=20 > around what BLISS is trying to solve, and defines a framework=20 > for solving it. It uses concrete examples the whole way=20 > through so we can be clear on what we are talking about.=20 > Until it appears in the archives, you can pick it up here: >=20 > http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-st atement-00.txt >=20 > This is something I should have gotten out a month or so=20 > back, so that we could have used it as a context for=20 > discussion and draft writing in the remaining time. I=20 > apologize for getting this in just before the deadline - too=20 > late to be useful for anyone elses drafts. >=20 > I think its really important that we discuss this draft and=20 > get agreement on it. Its really trying to define the process=20 > by which we will be doing our work. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jul 05 08:45:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Qhz-0003JP-A9; Thu, 05 Jul 2007 08:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Qhu-0003JK-VP for bliss@ietf.org; Thu, 05 Jul 2007 08:45:15 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Qhq-0004oq-DQ for bliss@ietf.org; Thu, 05 Jul 2007 08:45:14 -0400 Received: from gauravk (unknown [221.134.154.130]) (Authenticated sender: gkheterpal@ismartpanache.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 9A2D3758059; Thu, 5 Jul 2007 07:45:08 -0500 (CDT) From: "Gaurav Kheterpal" To: "'Jonathan Rosenberg'" , Subject: RE: [BLISS] BLISS problem statement draft Date: Thu, 5 Jul 2007 18:16:32 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <46897CB3.9050609@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace8+MqUYuhe2diGRGmTQmWOLTLooQCBGvVg Message-Id: <20070705124508.9A2D3758059@smtpauth00.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan, My comments below:- ================ Typos/ Grammar ================ * Section 2, 1st Paragraph - should probably include the phrase (consisting of/comprising of/having) SIP is typically deployed in environments CONSISTING OF/COMPRISING OF/ HAVING a large number of user agents and some number of servers, such as proxy servers, registrars, feature servers, and so on * Section 2, 1st Paragraph - 'unpredicable' was probably meant to be 'unpredictable' * 3.1.2 - Replace 'arives' with "arrives" & 'ansers' with "answers" * 5.2 - Replace 'THis' with "This" * 5.4 - Replace 'interopreability' with "interoperability" & 'neccesary' with "necessary" ============== Functional ============== * 3.1.1 - First Paragraph - You might want to add information to indicate that the call forward timeout is user configurable/ dependent on the UA & is not mandated by the protocol itself. * 3.1.2 - Same comment as above (configurable/dependent on proxy) * 3.1.3 - Figure 4 is incorrect (probably a copy-paste error from Figure 3) & needs to be updated. My 2 cents, Gaurav > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, July 03, 2007 4:01 AM > To: bliss@ietf.org > Subject: [BLISS] BLISS problem statement draft > > I've submitted a draft that provides a problem statement around what > BLISS is trying to solve, and defines a framework for solving it. It > uses concrete examples the whole way through so we can be clear on what > we are talking about. Until it appears in the archives, you can pick it > up here: > > http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-statement- > 00.txt > > This is something I should have gotten out a month or so back, so that > we could have used it as a context for discussion and draft writing in > the remaining time. I apologize for getting this in just before the > deadline - too late to be useful for anyone elses drafts. > > I think its really important that we discuss this draft and get > agreement on it. Its really trying to define the process by which we > will be doing our work. > > 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 > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jul 05 09:52:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6RlN-0000Q5-I8; Thu, 05 Jul 2007 09:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6RlL-0000Pq-K3 for bliss@ietf.org; Thu, 05 Jul 2007 09:52:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6RlB-0007hq-Vg for bliss@ietf.org; Thu, 05 Jul 2007 09:52:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 09:52:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACKUjEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175486400"; d="scan'208"; a="125270236:sNHT2950194632" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65Dqdk8023714; Thu, 5 Jul 2007 09:52:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65DqY6a003516; Thu, 5 Jul 2007 13:52:38 GMT 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.1830); Thu, 5 Jul 2007 09:52:34 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:52:33 -0400 Message-ID: <468CF7A5.8080605@cisco.com> Date: Thu, 05 Jul 2007 09:52:37 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371155981A6@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371155981A6@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 13:52:33.0889 (UTC) FILETIME=[BCF24D10:01C7BF0B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11217; t=1183643559; x=1184507559; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Brian=20Stucker=20; bh=Nbhs4EYwhvt5TppEoqOocnry3NP3eh30ARhgxHCJmP8=; b=eRoAUfXJD+o/oGVclig0n0x9UHWW/bQA8jCRkTccscY5wPLMqcHBplRa2eMCZWtldc2ZgpEa XA0blSbv1me4H3rGobPpZE9XxVF3U62PgXTyAotrOoWdtC0WstMX9E+m; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org inline. Brian Stucker wrote: > Hi Jonathan, > > Thanks for putting this together. A few comments though: > > A few comments on the CFNA example approaches. I know that you aren't > trying to write a document to address CFNA, but since this document > describes a template approach to for documenting features within BLISS I > think it's important that the examples here reflect the type of > discussion that we are looking for in the eventual BLISS RFCs. > > Section 3-3.1.3: > > - Although approach I could be used for CFNA, the fact that UA Y > returned a 302 means that this could also be used to implement CFU as > well (especially from the proxy's point of view). Essentially, you could > have approach I and II or I and IV running concurrently for the same or > different purposes where the text makes it sound like these are always > discrete cases. I thought it important to try and articulate what the problem is that we are trying to solve. Thus, it makes sense to take even the simplest feature, and demonstrate that, just for CFNA, look how there are multiple ways you can implement this, and so there are still interop problems. The discussion wasn't meant to imply that, if you chose one approach for one feature, you had to implement that approach for other features. Can you point to specific text that led you to this conclusion? > > - Figure 3 and 4 are the same but the scenarios are not. Figure 4 needs > to be updated to reflect the text in section 3.1.3. Yes, fixed. > > - Section 3.1.4 seems more like a refinement on section 3.1.2 than a > different approach from the standpoint of the CFNA behavior when the > call is placed by UA X. Actually its quite different from an interop point of view. I was taking the view of "I buy phone from vendor A, proxy from vendor B. Plug them together. DOes it work?". In 3.1.4, the failure is due to failure to support CPL on one side or another. > Configuration of elements would seem to be out > of scope would it not? Generally yes; but its part of the overall interop story. This is particularly true for things like CPL which blend protocol and config. Also true for cases where people want to change configurations of features on their UA, without web interfaces. For example, hit the DND button on my phone. If DND is executed in the proxy, there needs to be signaling from the phone to the proxy to convey that. This kind of 'feature activation' is kind-of configuration, but is very much in scope of our activity. The reason is, if one side does some particular approach for it (e.g., XCAP) and the proxy does a different one (HTTP POST with some special URI format, or INFO (blech), or whatever...), we have an interop failure. Otherwise why would we not also consider variants > of how UA Y came to know to forward the INVITE via 302 or proxy mode > (approach I and III respectively). In cases where the configuration is by administrator or user through a web page or some tool, and that tool is part of the server that implements the feature, I think we don't need to say anything about it. But when configuration is to take place on one component, and needs to be conveyed in an automated way to another, where the feature is implemented, I think we need to talk about it. ..it seems like it could be endless > without a clear constraint. I think our scope covers whatever it needs to cover in order to achieve interoperability. > Another point to consider is that the web > page in approach II could have configured the proxy via CPL as well, or > the CPL in approach IV could have been delivered via SOAP to a web > interface that dumped it into a common database with the proxy. Even > though message 1 in approach IV is SIP, it's not limited to SIP, etc., > and perhaps we should leave configuration out of scope initially, etc. See above. > > Hopefully you see where I'm going with this: we need some sort of > constraint here to limit discussion to something reasonable. > > - Section 3.1.5.1 I'm not sure that assume is the best word here. People > assume things, not machines. The user for UA Y should clearly not expect > their calls to be forwarded to anywhere if they (or an administrator) > never instructed any component of the system to take some sort of action > on their behalf. If nobody implements a feature there can be no > interoperability, and without interoperability there can be no failure > to interoperate. Right? I'm not sure I see your point. THe problem is that when an administrator buys a proxy from vendor 1 and a UA from vendor 2, when he puts those together, CFNA (as an example) will not work. Do you disagree? > > - Section 3.1.5.2 Again, I think we would need to show the cases where > this isn't user error. If the user went off and told the proxy to > forward their calls after X rings, and then told their UA to do the same > then this is clearly (to me) out of scope for a BLISS feature > discussion. The protocol is working fine, the features are working fine, > nothing is failing here except the user's understanding of the system or > their memory as to what they have told the system to do. I think this is a case where user error is easily possible. But I agree this scenario here is one of user error, whereas in 3.1.5.1, it is not. > > In a general, I believe you are going to commonly find systems that > (again using CFNA as the example here) offer a feature both at the > network and at the device to ensure that the feature is available for > all users. I don't think race conditions that arise due to duplicated > features is de facto an issue that should be in scope (i.e. user > behavior cannot be specified) unless they interact with each other in > such a way that neither implmentation will work correctly if only one > source for the feature is active at any given point in time. I very much want to enable multiple places where a feature can be implemented. However I want to make sure that, (1) no matter what vendors you bring together, there is a configuration that works, and (2) in cases where things can happen in multiple places, we've worked through it and taken care of any race conditions or inconsistencies that would otherwise happen. In some cases, for example, I can imagine needing some kind of capability discovery so that, for example, a proxy can know, "hey, that UA can do call forwarding, so I should not bother running the timer". For our analysis of the problems (phase III in the BLISS process) I think we should look at everything and then have the discussion we are having right now - to determine whether there is a problem here to address, or not. That is the whole point of this exercise. I know you > talk about this more in section 5, but it sounds like we're looking to > find the "best" way of implementing a feature where that widely results > in one way. When a feature such as CFNA is "single-ended", meaning that > there are no requirements on one of the two users involved in the > feature, then having more than one way of doing something is likely to > not cause an issue. Usually yes. Single-ended features are great for this case. But even then you can have problems. If the feature is "double-ended", meaning that there > are requirements placed not only on the device invoking the feature but > the devices that the feature is managing as a result then you run into > issues with having many ways to do the same thing. I believe this is a > nuance that should be captured. Yes, this is a good point. I'll try to capture that. Per above, "single ended" needs to take into consideration the configuration of those features. Since if a feature is configured in place X but executed in place Y, well its not really single-ended anymore. > > - Section 3.1.5.3 This is a better argument for why some configuration > may matter except that CPL could be delivered to the proxy by some other > source. Sure. But in this case if it comes from the phone the system doesn't work. This is exactly my point about why configuration can matter. > Essentially it's not the specific mechanism that's being used to > configure the feature, but that there does not exist a means to enable > the feature due to an implied interoperability requirement. Well the problem today is that people in practice, I think, are using a lot of different ways to convey feature configuration from UA to proxies (when proxies implement the feature). XCAP, CPL, INFO, SOAP, POST, SERVICE, etc. Mostly all proprietary. That in itself indicates a problem. > > In general, I would expect most feature vendors to supply you with an > alternative way to configure their features without requiring action on > the client, but perhaps this needs to be stated more directly somewhere. > Maybe include this implied configurability problem in section 5 somehow? Configuration can be single or double ended also. A single-ended config is where the user interacts directly with the component in which the configuration needs to reside. Examples: a web page on a proxy for configuring call forward, where the call forwarding happens in the proxy. In such a case, there is clearly no need to define what the interface looks like, in any way. However, a double-ended config are things like: * user enables DND on their phone but this executes in the proxy * user utilizes a UI on their phone to set up a call-forward based on time of day, and uploads result to the proxy via CPL * user configures a custom ringtone from a web page on their proxy, and ringtone gets downloaded to phone and executed there > > - Section 4 "Allow Variability in Implementation" / "Support a > Multiplicity - I know you probably meant it in the text, but I'd like to > include it explicitly: wireless. The reason I believe this needs to be > stated directly is because it's an environment where the links to the > clients are much more unreliable than in most other environments, > therefore, relying upon the client to take actions may not be feasible > in all cases and more than one approach needs to be accounted for in the > 'decision making process' within the Allow Variability in Implementation > section. For instance, approach I does not work reliably in an > environment where the client is not always-on and always-reachable. OK, I will add. > > - I know ICE solves a number of issues, but you might want to update > your XML template if you should create a -01 version of this document. > :) I've gotten half dozen private mails on this one already. Copy-paste error on XML templates. 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sun Jul 08 18:56:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7fgE-0001JL-V2; Sun, 08 Jul 2007 18:56:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SlP-0007p9-8V for bliss@ietf.org; Sun, 08 Jul 2007 05:09:07 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7SlK-0006Mk-Ex for bliss@ietf.org; Sun, 08 Jul 2007 05:09:07 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l6898VN1023895; Sun, 8 Jul 2007 11:08:31 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6898Y7R020453; Sun, 8 Jul 2007 11:08:34 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Jul 2007 11:08:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 8 Jul 2007 11:08:22 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DFC@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review draft-procter-bliss-call-park-extension-00 Thread-Index: AcfBP4jsCxNsmQiGTXaEJoVeuzMrOg== From: "Willekens, Marc" To: X-OriginalArrivalTime: 08 Jul 2007 09:08:31.0484 (UTC) FILETIME=[8E1EEBC0:01C7C13F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-Mailman-Approved-At: Sun, 08 Jul 2007 18:56:37 -0400 Cc: bliss@ietf.org Subject: [BLISS] Review draft-procter-bliss-call-park-extension-00 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0216742946==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============0216742946== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C13F.8D3D253B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C13F.8D3D253B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael; =20 My first impression of your idea was: it's good to provide some backwards compatibility with some legacy equipment, and give the end-user an already known kind of interface. But the main question is: is this the way to go? Is this good or bad for the further evolution of SIP?=20 =20 The draft directly proposes a certain solution without considering the different possible use cases and the different new capabilities offered by SIP phones. It only gives a proposal based on the traditional implementation of this feature. In this draft, first the method is given for the "orbit number" allocated by the user who wants to park the call. However, later in the document the disadvantage of this method is indicated and a proposal is given to have the allocation of the orbit number done by the park server. Further, the draft only considers the case of a REFER method passed to the park server. In the BLISS at IETF.68 however, the problem space for interoperability with call park was indicated as different possible choices in implementing this feature related to the chosen methods such as: - use of REFER to the caller - use of REFER to the Park server - use of KPML (keypad markup language) approach It was already indicated that the end-device should be able to handle the REFER method for the park feature to allow the interworking between the equipment of different vendors. The draft only proposes a solution towards the traditional closed PABX model and as such does not fullfil the goal of the BLISS and the evolutional approach of the SIP. Further, the document does not handle the situation for a parked call which is not retrieved: will the call be destroyed, returned to the original party who did the park, .... If we really want to solve the interoperability between SIP UA and servers, then the handling of the feature should be clearly defined from the SIP paradigma without being based too much on the classical PABX paradigm. Else, we will always be locked to different kind of proprietary solutions.=20 Some questions to think about: 1. Why should an end-user be bothered with these park or orbit short numbers? Is it not better to have a system which supports the end-user in a much better way? When you have calls parked to your identity and waiting in a queue, why do we then need short numbers? Is it not enough to pick-up any SIP phone and enter your PIN code to inform the system where you are and then the system can indicate the parked calls in another more appropriate way. 2. There is certainly a need for the call park/retrieve feature. Many customers are still requesting it for reasons of cost reduction in their telephony systems. E.g. workers in a logistic environment with a high mobile profile but without mobile end devices (for cost reductions) and a low called profile can benefit from the call park feature. The amount of end devices can be limited, and any end-device can be used to retrieve a parked call for and by a certain employee. When the amount of end-devices is limited, why not offereing more flexibility in that end-device related to the traditional PABX phones? 3. In other business environments, when users have mobile end devices, the need for the call park/retrieve feature can disappear. E.g. this is the case in business environments which first had fixed phones and when an employee wanted to handle a call at his desk further at another location. With a mobile device, the call park feature no longer makes sense. 4. The handling of parked calls can also be different in IP networks as for TDM networks. In a TDM network, there was always the cost for the setup of a call and for the duration of a call. For an IP network, the amount of parked calls and the duration of the parking can be much higher. This requires another kind of user interface. With best regards, Marc. =20 ------_=_NextPart_001_01C7C13F.8D3D253B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Michael;
 
My first impression = of your=20 idea was: it's good to provide some backwards compatibility with some = legacy=20 equipment, and give the end-user an already known kind of interface. But = the=20 main question is: is this the way to go? Is this good or bad for the = further=20 evolution of SIP?
 
The draft directly = proposes a=20 certain solution without considering the different possible use cases = and the=20 different new capabilities offered by SIP phones. It only gives a = proposal based=20 on the traditional implementation of this feature.

In this draft, first the method is given for the = "orbit number"=20 allocated by the user who wants to park the call. However, later in the = document=20 the disadvantage of this method is indicated and a proposal is given to = have the=20 allocation of the orbit number done by the park server.

Further, the draft only considers the case of a REFER = method=20 passed to the park server. In the BLISS at IETF.68 however, the problem = space=20 for interoperability with call park was indicated as different possible = choices=20 in implementing this feature related to the chosen methods such = as:

- use of REFER to the caller
- use of=20 REFER to the Park server
- use of KPML (keypad = markup=20 language) approach

It was already indicated that the end-device should be = able to=20 handle the REFER method for the park feature to allow the interworking = between=20 the equipment of different vendors.

The draft only proposes a solution towards the = traditional=20 closed PABX model and as such does not fullfil the goal of the BLISS and = the=20 evolutional approach of the=20 SIP.

Further, the document does not handle the situation = for a parked=20 call which is not retrieved: will the call be destroyed, returned to the = original party who did the park, ....

If we really want to solve the interoperability = between SIP UA=20 and servers, then the handling of the feature should be clearly defined = from the=20 SIP paradigma without being based too much on the classical PABX = paradigm. Else,=20 we will always be locked to different kind of proprietary = solutions.

Some questions to think about:

1. Why should an end-user be bothered with these park = or orbit=20 short numbers? Is it not better to have a system which supports the = end-user in=20 a much better way? When you have calls parked to your identity and = waiting in a=20 queue, why do we then need short numbers? Is it not enough to pick-up = any SIP=20 phone and enter your PIN code to inform the system where you are and = then the=20 system can indicate the parked calls in another more appropriate = way.

2. There is certainly a need for the call = park/retrieve feature.=20 Many customers are still requesting it for reasons of cost reduction in = their=20 telephony systems. E.g. workers in a logistic environment with a high = mobile=20 profile but without mobile end devices (for cost reductions) and a low = called=20 profile can benefit from the call park feature. The amount of end = devices can be=20 limited, and any end-device can be used to retrieve a parked call for = and by a=20 certain employee. When the amount of end-devices is limited, why not = offereing=20 more flexibility in that end-device related to the traditional PABX=20 phones?

3. In other business environments, when users have = mobile end=20 devices, the need for the call park/retrieve feature can disappear. E.g. = this is=20 the case in business environments which first had fixed phones and when = an=20 employee wanted to handle a call at his desk further at another = location. With a=20 mobile device, the call park feature no longer makes sense.

4. The handling of parked calls can also be different = in IP=20 networks as for TDM networks. In a TDM network, there was always the = cost for=20 the setup of a call and for the duration of a call. For an IP network, = the=20 amount of parked calls and the duration of the parking can be much = higher. This=20 requires another kind of user interface.

With best=20 regards,
Marc.

 

= ------_=_NextPart_001_01C7C13F.8D3D253B-- --===============0216742946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============0216742946==-- From bliss-bounces@ietf.org Mon Jul 09 07:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rqb-0006lj-7b; Mon, 09 Jul 2007 07:56:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rqP-0006l3-NH; Mon, 09 Jul 2007 07:55:57 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7rqP-00051x-6a; Mon, 09 Jul 2007 07:55:57 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Mon, 9 Jul 2007 13:52:18 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jul 2007 13:52:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Jul 2007 13:52:16 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: latest call-completion draft Thread-Index: AcfCH5f9WpKZRVbYTdmlHQJ6AnUcsw== From: "Huelsemann, Martin" To: , X-OriginalArrivalTime: 09 Jul 2007 11:52:17.0209 (UTC) FILETIME=[991F5290:01C7C21F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: adam@nostrum.com, mhammer@cisco.com, dean.willis@softarmor.com, "Alexeitsev, D" Subject: [BLISS] latest call-completion draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282198814==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============1282198814== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C21F.98CB54DE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C21F.98CB54DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, the latest call-completion draft has been uploaded, as agreed = call-completion was shifted to BLISS, so you can find the result under = http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00= .txt. The main issue of the discussion on the mailing list was the usage of = SUBSCRIBE bodies for queue manipulation actions (e.g. add, suspend, = resume), which is not in accordance with RFC 3265. The solution discussed was the scenario, where not answered calls = (because of busy or no reply) are getting queued at the callee, and the = caller is informed that he can receive call-completion information, = which would inform him that he is either still queued, or that he can = start the recall. So what is described now is a proposal for a pure call-completion event = package with the values 'queued' and 'ready-for-call-completion' (and an = additional value for service retention), so no more queue manipulation = parameters in the SUBSCRIBE body, and the proposed usage of the = Allow-events in 180 and 486.=20 Suspending and resuming would be done by un-subscribing and subscribing = again to the call-completion event package. Comments and questions are welcome. Regards, Martin ------_=_NextPart_001_01C7C21F.98CB54DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable latest call-completion draft

Hi all,

the latest call-completion draft has = been uploaded, as agreed call-completion was shifted to BLISS, so you = can find the result under http://www.ietf.org/internet-drafts/draft-poetzl-bliss-cal= l-completion-00.txt.

The main issue of the discussion on the = mailing list was the usage of SUBSCRIBE bodies for queue manipulation = actions (e.g. add, suspend, resume), which is not in accordance with RFC = 3265.

The solution discussed was the = scenario, where not answered calls (because of busy or no reply) are = getting queued at the callee, and the caller is informed that he can = receive call-completion information, which would inform him that he is = either still queued, or that he can start the recall.

So what is described now is a proposal for a pure = call-completion event package with the values 'queued' and = 'ready-for-call-completion' (and an = additional value for service retention), so no more queue manipulation = parameters in the SUBSCRIBE body, and the proposed usage of the Allow-events in 180 and 486.

Suspending and resuming would be done = by un-subscribing and subscribing again to the call-completion event = package.


Comments and questions are = welcome.



Regards, Martin



------_=_NextPart_001_01C7C21F.98CB54DE-- --===============1282198814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1282198814==-- From bliss-bounces@ietf.org Mon Jul 09 16:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zZN-0006Iz-9x; Mon, 09 Jul 2007 16:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zZM-0006Ig-Ek for bliss@ietf.org; Mon, 09 Jul 2007 16:10:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zZI-0004p4-Po for bliss@ietf.org; Mon, 09 Jul 2007 16:10:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l69KAfk21483; Mon, 9 Jul 2007 20:10:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Mon, 9 Jul 2007 15:10:37 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371156F627F@zrc2hxm2.corp.nortel.com> In-Reply-To: <468CF7A5.8080605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: Ace/C8wGgwmk3fzTR1SDCqXZOljIuwDVB4gQ References: <46897CB3.9050609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371155981A6@zrc2hxm2.corp.nortel.com> <468CF7A5.8080605@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Inline.=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, July 05, 2007 8:53 AM > To: Stucker, Brian (RICH1:AR00) > Cc: bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 [snip] > > Thanks for putting this together. A few comments though: > >=20 > > A few comments on the CFNA example approaches. I know that=20 > you aren't=20 > > trying to write a document to address CFNA, but since this document=20 > > describes a template approach to for documenting features=20 > within BLISS=20 > > I think it's important that the examples here reflect the type of=20 > > discussion that we are looking for in the eventual BLISS RFCs. > >=20 > > Section 3-3.1.3: > >=20 > > - Although approach I could be used for CFNA, the fact that UA Y=20 > > returned a 302 means that this could also be used to=20 > implement CFU as=20 > > well (especially from the proxy's point of view). Essentially, you=20 > > could have approach I and II or I and IV running=20 > concurrently for the=20 > > same or different purposes where the text makes it sound like these=20 > > are always discrete cases. >=20 > I thought it important to try and articulate what the problem=20 > is that we are trying to solve. Thus, it makes sense to take=20 > even the simplest feature, and demonstrate that, just for=20 > CFNA, look how there are multiple ways you can implement=20 > this, and so there are still interop problems. >=20 Agree. > The discussion wasn't meant to imply that, if you chose one=20 > approach for one feature, you had to implement that approach=20 > for other features. Can you point to specific text that led=20 > you to this conclusion? =20 The last paragraph of section 2 makes it sound like this is the case: If we consider a particular feature, the protocol machinery for accomplishing the feature requires logic on each node involved in the feature. Let us say that feature X can be implemented using two different techniques - X.1 and X.2. Each technique is composed of a series of message exchanges and associated state machine processing in each affected node. If all affected nodes implement the same logic - say the logic for X.1 - the feature works. Similarly, if all implement the logic for X.2, the feature works. However, if some of the nodes implement the logic for X.1, and others have implemented the logic for X.2, the outcome is unpredicable and the feature may not interoperate. I understand what you're trying to say here is within the context of a single state-machine, and is very likely to be true the more complex the state machine. However, the example you use in section 3, CFNA, has several possible implementations that require no synchronization between nodes to work properly (i.e. it's a single-ended feature). The text from section 2 relates better to features such as call pickup where you might be using a dialog event package to know what the state of a call somewhere else is, etc. The use of the term "approach" and some of the related text also may not be clear that what you're trying to show are usecases, and not necessarily discrete implementations of call forwarding. Also, not to be nit-picky, but you might say "may be unpredictable" instead of saying it's always unpredictable. Depending upon the nature of the interop failure the feature may still work partially or in specific, enumerable, circumstances. Also, total failure (nothing happens) is undesirable, but very predictable. > >=20 > > - Figure 3 and 4 are the same but the scenarios are not. Figure 4=20 > > needs to be updated to reflect the text in section 3.1.3. >=20 > Yes, fixed. >=20 > >=20 > > - Section 3.1.4 seems more like a refinement on section=20 > 3.1.2 than a=20 > > different approach from the standpoint of the CFNA behavior=20 > when the=20 > > call is placed by UA X. >=20 > Actually its quite different from an interop point of view. I=20 > was taking the view of "I buy phone from vendor A, proxy from=20 > vendor B. Plug them together. DOes it work?". In 3.1.4, the=20 > failure is due to failure to support CPL on one side or another. I would agree if configuration is in scope, which you seem to be arguing for. However, from a "what happens when the INVITE comes in at a protocol level" there's no difference. This brings up another potential question that I'm not sure is fully answered in the charter: are the nodes in these diagrams considered to be black-box, grey-box, or white-box? I'm taking the black-box view with my statement here, but perhaps you are intending to make these white-boxes in the specifications? This could become very contentious later on as people try to reconcile implementations so we should probably state this explicitly somewhere what the expectation is. >=20 > > Configuration of elements would seem to be out of scope=20 > would it not? >=20 > Generally yes; but its part of the overall interop story.=20 > This is particularly true for things like CPL which blend=20 > protocol and config.=20 > Also true for cases where people want to change=20 > configurations of features on their UA, without web=20 > interfaces. For example, hit the DND button on my phone. If=20 > DND is executed in the proxy, there needs to be signaling=20 > from the phone to the proxy to convey that. This kind of=20 > 'feature activation' is kind-of configuration, but is very=20 > much in scope of our activity. The reason is, if one side=20 > does some particular approach for it (e.g., XCAP) and the=20 > proxy does a different one (HTTP POST with some special URI=20 > format, or INFO (blech), or whatever...), we have an interop failure. Understand, but I think it would be good to limit ourselves to one protocol at a time if possible so we can focus discussion. Do we really want to be in the business of telling people that we expect them to use XYZ to configure their services? This is an area of wide divergence for the various implementors, and existing mechanisms tend to be tightly coupled with internal mechanics of their devices. Is it possible to agree to keep this type of material out of scope unless we find no other reasonable way around having to describe it in the specifications to get things to work? >=20 >=20 >=20 > Otherwise why would we not also consider variants > > of how UA Y came to know to forward the INVITE via 302 or=20 > proxy mode=20 > > (approach I and III respectively). >=20 > In cases where the configuration is by administrator or user=20 > through a web page or some tool, and that tool is part of the=20 > server that implements the feature, I think we don't need to=20 > say anything about it.=20 > But when configuration is to take place on one component, and=20 > needs to be conveyed in an automated way to another, where=20 > the feature is implemented, I think we need to talk about it. Fair enough. I think this is reasonable. >=20 >=20 > ..it seems like it could be endless > > without a clear constraint.=20 >=20 > I think our scope covers whatever it needs to cover in order=20 > to achieve interoperability. Mmm... Really? That seems extremely ambitious. How does BLISS then differ from SPEERMINT?=20 > >=20 > > Hopefully you see where I'm going with this: we need some sort of=20 > > constraint here to limit discussion to something reasonable. > >=20 > > - Section 3.1.5.1 I'm not sure that assume is the best word here.=20 > > People assume things, not machines. The user for UA Y=20 > should clearly=20 > > not expect their calls to be forwarded to anywhere if they (or an=20 > > administrator) never instructed any component of the system to take=20 > > some sort of action on their behalf. If nobody implements a feature=20 > > there can be no interoperability, and without=20 > interoperability there=20 > > can be no failure to interoperate. Right? >=20 > I'm not sure I see your point. THe problem is that when an=20 > administrator buys a proxy from vendor 1 and a UA from vendor=20 > 2, when he puts those together, CFNA (as an example) will not=20 > work. Do you disagree? I do. I don't think it's an IETF WG's job to ensure that customers ask appropriate questions of vendors to ensure the existance of a particular feature. I believe it's onerous of them to have to specify detailed call flows to make sure everything will work in RFIs, but asking both vendor 1 and vendor 2, "Do you offer feature X?" is not unreasonable at all. Again, I think CFNA is a bad example, because it really does not require more than one node in the network to implement it in order for it to work. You could argue that configuration flows, such as CPL, may require some coordination, but there are plenty of other approaches that work without requiring CPL (and for a basic level of interoperability you might argue against CPL implementations for this very reason). This somewhat relates to my earlier concern about how these specifications will be written: if CPL is simply desirable, but not necessary for a *basic level of interoperability* what does that mean for CPL based implementations as far as BLISS is concerned? >=20 > >=20 > > - Section 3.1.5.2 Again, I think we would need to show the=20 > cases where=20 > > this isn't user error. If the user went off and told the proxy to=20 > > forward their calls after X rings, and then told their UA to do the=20 > > same then this is clearly (to me) out of scope for a BLISS feature=20 > > discussion. The protocol is working fine, the features are working=20 > > fine, nothing is failing here except the user's=20 > understanding of the=20 > > system or their memory as to what they have told the system to do. >=20 > I think this is a case where user error is easily possible.=20 > But I agree this scenario here is one of user error, whereas=20 > in 3.1.5.1, it is not. User error is always easily possible. :) >=20 > >=20 > > In a general, I believe you are going to commonly find systems that=20 > > (again using CFNA as the example here) offer a feature both at the=20 > > network and at the device to ensure that the feature is=20 > available for=20 > > all users. I don't think race conditions that arise due to=20 > duplicated=20 > > features is de facto an issue that should be in scope (i.e. user=20 > > behavior cannot be specified) unless they interact with=20 > each other in=20 > > such a way that neither implmentation will work correctly=20 > if only one=20 > > source for the feature is active at any given point in time. >=20 > I very much want to enable multiple places where a feature=20 > can be implemented. However I want to make sure that, (1) no=20 > matter what vendors you bring together, there is a=20 > configuration that works, and (2) in cases where things can=20 > happen in multiple places, we've worked through it and taken=20 > care of any race conditions or inconsistencies that would=20 > otherwise happen. In some cases, for example, I can imagine=20 > needing some kind of capability discovery so that, for=20 > example, a proxy can know, "hey, that UA can do call=20 > forwarding, so I should not bother running the timer". =20 Except if the proxy uses such a detection mechanism, the user may suddenly have inconsistient behavors across multiple devices. The user may not be aware that their UA can do call forwarding. Their other devices can't, and now when that UA is the only one logged in CFNA breaks (because the proxy assumes the UA can do it, and the user is unaware), whereas it works correctly when devices that cannot do CFNA are logged in because the proxy takes over the responsibilies at that time. Again, we really need to be careful that by trying to simplify the complexities we have now, we don't toss aside mechanisms that are put there for a reason. That's why I think it's important to avoid sweeping language in any sort of baseline material where possible. > For our analysis of the problems (phase III in the BLISS=20 > process) I think we should look at everything and then have=20 > the discussion we are having right now - to determine whether=20 > there is a problem here to address, or not. That is the whole=20 > point of this exercise. In general I agree with you, I just want to make sure we're not opening up such a huge can of worms that we can't get any of them back into the can within a reasonable amount of time. Timeliness of advice is important otherwise our output risks being irrelevant to the people who need it most. [snip] >=20 > >=20 > > - Section 3.1.5.3 This is a better argument for why some=20 > configuration=20 > > may matter except that CPL could be delivered to the proxy by some=20 > > other source. >=20 > Sure. But in this case if it comes from the phone the system=20 > doesn't work. This is exactly my point about why=20 > configuration can matter. >=20 >=20 > > Essentially it's not the specific mechanism that's being used to > > configure the feature, but that there does not exist a=20 > means to enable > > the feature due to an implied interoperability requirement.=20 >=20 > Well the problem today is that people in practice, I think,=20 > are using a=20 > lot of different ways to convey feature configuration from UA=20 > to proxies=20 > (when proxies implement the feature). XCAP, CPL, INFO, SOAP, POST,=20 > SERVICE, etc. Mostly all proprietary. That in itself=20 > indicates a problem. Yes, it is a problem. I don't think you're going to be able to fix this anytime soon though because configuration tends to be so closely embedded to the idiosyncracies of how a particular node is designed overall (perhaps leveraging hardware) that you're unlikely to reach a meaningful consensus within a reasonable timespan. People are used to fixing and tweaking SIP call flows, so I think the door is much more open for recommendations than it is in the OA&M arena, for better or worse. >=20 > >=20 > > In general, I would expect most feature vendors to supply=20 > you with an > > alternative way to configure their features without=20 > requiring action on > > the client, but perhaps this needs to be stated more=20 > directly somewhere. > > Maybe include this implied configurability problem in=20 > section 5 somehow? >=20 > Configuration can be single or double ended also. A=20 > single-ended config=20 > is where the user interacts directly with the component in which the=20 > configuration needs to reside. Examples: a web page on a proxy for=20 > configuring call forward, where the call forwarding happens in the=20 > proxy. In such a case, there is clearly no need to define what the=20 > interface looks like, in any way. >=20 > However, a double-ended config are things like: >=20 > * user enables DND on their phone but this executes in the proxy > * user utilizes a UI on their phone to set up a=20 > call-forward based on=20 > time of day, and uploads result to the proxy via CPL > * user configures a custom ringtone from a web page on their proxy,=20 > and ringtone gets downloaded to phone and executed there >=20 Yup, these make more sense to discuss. >=20 > >=20 > > - Section 4 "Allow Variability in Implementation" / "Support a > > Multiplicity - I know you probably meant it in the text,=20 > but I'd like to > > include it explicitly: wireless. The reason I believe this=20 > needs to be > > stated directly is because it's an environment where the=20 > links to the > > clients are much more unreliable than in most other environments, > > therefore, relying upon the client to take actions may not=20 > be feasible > > in all cases and more than one approach needs to be=20 > accounted for in the > > 'decision making process' within the Allow Variability in=20 > Implementation > > section. For instance, approach I does not work reliably in an > > environment where the client is not always-on and always-reachable. >=20 > OK, I will add. >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 09 18:17:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81YC-000276-GC; Mon, 09 Jul 2007 18:17:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81YA-000271-TM for bliss@ietf.org; Mon, 09 Jul 2007 18:17:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I81YA-0003iY-El for bliss@ietf.org; Mon, 09 Jul 2007 18:17:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2007 18:17:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADJRkkZAZnmf/2dsb2JhbACIU511 X-IronPort-AV: i="4.16,519,1175486400"; d="scan'208"; a="64739959:sNHT64632784" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l69MHk2N025167 for ; Mon, 9 Jul 2007 18:17:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69MHFsY021067 for ; Mon, 9 Jul 2007 22:17:45 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); Mon, 9 Jul 2007 18:17:45 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 18:17:45 -0400 Message-ID: <4692B40B.6070609@cisco.com> Date: Mon, 09 Jul 2007 18:17:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> In-Reply-To: <46897CB3.9050609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 22:17:45.0822 (UTC) FILETIME=[F9EB37E0:01C7C276] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6728; t=1184019466; x=1184883466; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=cTawaHviJGMSEoTX2LNBiy0cy+4bbW6XtK3/b3Zi9k8=; b=iwW8pcg4riN3s6pKHuQcqQSjNy4jCp5R+j+iTTO9mbfHzK9LPpAo4pDxLAXW3sDDzp5O3DM0 ovWgGjSQFrFZdOCXSdYkpZn8+b5UNGIooObLOxjpvf3xQqKptwp+LNbY; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Section 1: > The SIP specification itself includes primitives to support some of > these features. For example, RFC 3264 [2] defines SDP signaling > parameters for placing a call on hold... (This is little more than a nit.) RFC 3264 probably says more than it should about this. It is difficult to argue that those features (sendonly/recvonly) are *for* placing a call on hold. Rather they may *be useful when placing a call on hold*. The recipient of a reINVITE with a=sendonly in general cannot and should not conclude that it has been "put on hold". I put some words about using offer/answer for hold in the offeranswer draft. But I think we could make a good case that this should be a subject for BLISS to pursue. Section 2: > If we consider a particular feature, the protocol machinery for > accomplishing the feature requires logic on each node involved in the > feature. Let us say that feature X can be implemented using two > different techniques - X.1 and X.2. Each technique is composed of a > series of message exchanges and associated state machine processing > in each affected node. If all affected nodes implement the same > logic - say the logic for X.1 - the feature works. Similarly, if all > implement the logic for X.2, the feature works. However, if some of > the nodes implement the logic for X.1, and others have implemented > the logic for X.2, the outcome is unpredicable and the feature may > not interoperate. Agree, but there is more to it. Incompatibilities such as the above can result from two distinct properties of the feature implementations: - the two techniques X.1 and X.2 are compatible, in the sense that a node *could* implement both techniques. But in this case both nodes have only implemented one technique, and not the same one. A solution in this case is for nodes to implement both techniques. When there is an option about which to use, a node could choose what it prefers, but it goes along when another node has already made a choice. - Which action to take in a particular circumstance is indeterminate. Among the options consistent with a particular node's current state is one that is consistent with what the other node expects. But other actions equally plausible actions are inconsistent with the expectations of the other node. This can arise because each node has only limited information about the combined state of all the participants. It often doesn't know who all the participants are, or what feature is intended. To resolve this problem, it is necessary to ensure that the basic mechanisms of sip (used to construct features) are unambiguous wrt what each participant must do each time some event occurs. And then it is necessary to ensure that features are assembled from mechanisms in such a way that each node, at each event, consistently determines what it must do next in a way that is consistent with a reasonable outcome for the intended service. Note that problems here are quite likely not confusion between different implementations of the same feature. Rather they are likely to be confusions about what *mechanism* should be triggered by a particular event. The candidate mechanisms need not support the same feature. Some cases where this sort of thing can be a problem are: - confusion about sendonly and hold. Some b2buas conclude that an invite with sendonly means hold. Based on local config they may reinvite the other end to a MoH server. It may however be the case that this wasn't intended as hold at all. Sendonly may have been offered because there is currently no ability to process received media, and there is a true desire to send media. - Uses of REFER often seem to have an aura of black magic. Receiving a REFER request gives information that one is requested to send a particular type of request to a specific destination. It doesn't explicitly say anything about: . if an offer should be included (if allowed for the request) . which media sources and sinks managed by the device should be included in the request. . what media types should be included in a request . what media formats should be offered . How resources should be shared with other existing sessions . ... Most published call flows for features involving REFER just show what happens, not how a decision is made about that. Note that even enumerating call flows for all features does not solve this problem, though in that case the problem will hopefully be discovered by developers trying to implement the features. The problem is that you cannot implement your role in a feature by following the call flow. Following the call flow requires knowing the state of the rest of the system at all times. Instead, the implementor of a particular node must build up a state machine based on information available based on the messages has received and sent. And then based on this state and new incoming messages it must decide what to do. It must consolidate the possibilities from all the call flows it might be participating in to achieve this. There is then a problem if there is some state and incoming event is consistent with two different call flows, which require different actions. There is currently no formal process to check if specifications have this property. Section 3.1.3, Figure 4: The figure is a copy of figure 3, and isn't consistent with the text. Looks like an editing error. That's all. Otherwise I think this is spot on. THanks, Paul Jonathan Rosenberg wrote: > I've submitted a draft that provides a problem statement around what > BLISS is trying to solve, and defines a framework for solving it. It > uses concrete examples the whole way through so we can be clear on what > we are talking about. Until it appears in the archives, you can pick it > up here: > > http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-statement-00.txt > > > This is something I should have gotten out a month or so back, so that > we could have used it as a context for discussion and draft writing in > the remaining time. I apologize for getting this in just before the > deadline - too late to be useful for anyone elses drafts. > > I think its really important that we discuss this draft and get > agreement on it. Its really trying to define the process by which we > will be doing our work. > > Thanks, > Jonathan R. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 09 23:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86HV-0003V5-SK; Mon, 09 Jul 2007 23:20:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86HU-0003Ux-HX for bliss@ietf.org; Mon, 09 Jul 2007 23:20:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I86HF-0000G3-5k for bliss@ietf.org; Mon, 09 Jul 2007 23:20:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6A3JX024732; Tue, 10 Jul 2007 03:19:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Mon, 9 Jul 2007 22:19:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> In-Reply-To: <4692B40B.6070609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfCdwBtUc0Fx07rQOePmGu3FK8zTAAJ0feg References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Comments within. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, July 09, 2007 5:18 PM > To: Jonathan Rosenberg > Cc: bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 > Section 1 >=20 > > The SIP specification itself includes primitives to=20 > support some of > > these features. For example, RFC 3264 [2] defines SDP signaling > > parameters for placing a call on hold... >=20 > (This is little more than a nit.) >=20 > RFC 3264 probably says more than it should about this. It is=20 > difficult to argue that those features (sendonly/recvonly)=20 > are *for* placing a call on hold. Rather they may *be useful=20 > when placing a call on hold*.=20 > The recipient of a reINVITE with a=3Dsendonly in general cannot=20 > and should not conclude that it has been "put on hold". Although I agree with you technically, in reality I have yet to see a widely available device that will not appear to go "on hold" if sent a=3Dsendonly. Indeed, even your own equipment does this if you look at = the Cisco IOS documentation available online (you thoughtfully allow people to select between the bad-old way of 0.0.0.0 or a=3Dsendonly). Are we looking for best-possible implementation or basic level of interoperability? These are two very different things. >=20 > I put some words about using offer/answer for hold in the=20 > offeranswer draft. But I think we could make a good case that=20 > this should be a subject for BLISS to pursue. >=20 [snip] >=20 > Some cases where this sort of thing can be a problem are: >=20 > - confusion about sendonly and hold. Some b2buas conclude that > an invite with sendonly means hold. Based on local config > they may reinvite the other end to a MoH server. >=20 > It may however be the case that this wasn't intended as hold > at all. Sendonly may have been offered because there is currently > no ability to process received media, and there is a true desire > to send media. Plausible but not very commmon for audio streams. Definitely more likely with video streams. You left out one important detail about the way most BBUAs handle MoH though, it's not that the media stream was set to sendonly... It's that the media stream TRANSITIONED to a=3Dsendonly from a=3Dsendrecv. You'll get all sorts of weird, yet avoidable, usecases if you don't implement this tracking behavior. If everyone is happy with using a=3Dsendonly to denote hold (based on what we see that they've implemented) no matter how wrong it may be, wouldn't this indicate a successful level of interoperability? Again, trying to plumb where people's thoughts are: solve world hunger, fix only the really bad stuff and leave the rest, or just find a way to make everything work and call it a day. >=20 > - Uses of REFER often seem to have an aura of black magic. > Receiving a REFER request gives information that one is requested > to send a particular type of request to a specific destination. > It doesn't explicitly say anything about: > . if an offer should be included (if allowed for the request) > . which media sources and sinks managed by the device should > be included in the request. > . what media types should be included in a request > . what media formats should be offered > . How resources should be shared with other existing sessions > . ... >=20 > Most published call flows for features involving REFER just show > what happens, not how a decision is made about that. >=20 > Note that even enumerating call flows for all features does=20 > not solve this problem, though in that case the problem will=20 > hopefully be discovered by developers trying to implement the=20 > features. >=20 > The problem is that you cannot implement your role in a=20 > feature by following the call flow. Following the call flow=20 > requires knowing the state of the rest of the system at all times. >=20 > Instead, the implementor of a particular node must build up a=20 > state machine based on information available based on the=20 > messages has received and sent. And then based on this state=20 > and new incoming messages it must decide what to do. It must=20 > consolidate the possibilities from all the call flows it=20 > might be participating in to achieve this. There is then a=20 > problem if there is some state and incoming event is=20 > consistent with two different call flows, which require=20 > different actions. There is currently no formal process to=20 > check if specifications have this property. Agree whole-heartedly. Call flow diagrams are tools of the devil. They fool developers into thinking they have a complete implementation based on their ability to reproduce a limited number of message flow diagrams instead of understanding what the heck is really going on. They're useful for purposes of discussion but somewhat evil for purposes of specification (unless you want to spend a really large chunk of time enumerating and managing them). State-machine diagrams are much simpler to verify and still get you the a-picture-is-worth-a-thousand-words benefits you can get with a call flow diagram. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 10 05:26:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BzO-000860-NG; Tue, 10 Jul 2007 05:26:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BzN-00085Y-I9 for bliss@ietf.org; Tue, 10 Jul 2007 05:26:33 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Bz7-000807-Sy for bliss@ietf.org; Tue, 10 Jul 2007 05:26:33 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1I8ByN-0003Zs-E4; Tue, 10 Jul 2007 02:25:31 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Jul 2007 02:25:27 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C572CCB@sea02-mxc01.citel.com> In-reply-to: <67043E463DDBFD4A8087ED940BFF756B01822DFC@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review draft-procter-bliss-call-park-extension-00 Thread-index: AcfBP4jsCxNsmQiGTXaEJoVeuzMrOgBiG50g References: <67043E463DDBFD4A8087ED940BFF756B01822DFC@BRU0038A.ww018.siemens.net> From: "Michael Procter" To: "Willekens, Marc" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: bliss@ietf.org Subject: [BLISS] RE: Review draft-procter-bliss-call-park-extension-00 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Marc, Thanks for taking the time to read my draft and comment on it. Before I respond to each point, I think it might be helpful to provide a little background. This draft was first written over three years ago, and only recently re-issued under BLISS, with minimal changes. The key aim of the draft is not to try to standardise the parking service - that would have been a step too far three years ago, and even now we steer away from phrases such as 'standardising a feature'. Instead, the draft sought to highlight an area of interoperability that has already led to multiple incompatible implementations. The problem basically boils down to one of identification. How should you identify parked calls? The IETF example flow (draft-ietf-sipping-service-examples-12, sec 2.15) relies on the dialog identifier of the parked call, to subsequently identify the call for retrieval. This is an excellent approach, except when you need to pass the identifier by non-electronic means, such as passing a written note. My draft describes a simple change to support this common way of working, by allowing a human-friendly label to be attached to a parked call. > My first impression of your idea was: it's good to provide some backwards > compatibility with some legacy equipment, and give the end-user an already > known kind of interface. But the main question is: is this the way to go? > Is this good or bad for the further evolution of SIP?=20 I'm not sure exactly what you are referring to here. If you are asking whether call park is something that SIP should support (as some of your later comments seem to suggest), then I think the answer is clearly yes. If you are asking whether a human-usable identifier for parked calls is a good or bad thing, then I believe that the answer is that it is a good thing. Existing users expect a model of this sort. Even if more sophisticated models might exist in the future, users want to be able to park (and retrieve) calls today. > The draft directly proposes a certain solution without considering the > different possible use cases and the different new capabilities offered by > SIP phones. It only gives a proposal based on the traditional > implementation of this feature. Yes. The motivation for this is described in the Overview. It seeks to address a specific collection of use cases. These are relevant both to legacy phones and to the many already deployed SIP phones that share a similar form factor. Not everyone is using fancy videophones with touch-sensitive screens, or PC-based soft-phones with multi-tabbed user interfaces! > In this draft, first the method is given for the "orbit number" allocated > by the user who wants to park the call. However, later in the document the > disadvantage of this method is indicated and a proposal is given to have > the allocation of the orbit number done by the park server. Yes. I should spend some time clarifying that. Each approach has advantages and disadvantages. Supporting both simultaneously is not tricky, and permits multiple ways of working with only policy changes. > Further, the draft only considers the case of a REFER method passed to the > park server. In the BLISS at IETF.68 however, the problem space for > interoperability with call park was indicated as different possible > choices in implementing this feature related to the chosen methods such > as: > - use of REFER to the caller > - use of REFER to the Park server > - use of KPML (keypad markup language) approach > It was already indicated that the end-device should be able to handle the > REFER method for the park feature to allow the interworking between the > equipment of different vendors. This draft predates BLISS and IETF68 by some time! > The draft only proposes a solution towards the traditional closed PABX > model and as such does not fullfil the goal of the BLISS and the > evolutional approach of the SIP. Again, this is unsurprising given the history. This draft is simply one part of the total solution. > Further, the document does not handle the situation for a parked call > which is not retrieved: will the call be destroyed, returned to the > original party who did the park, .... These scenarios should all be considered (along with several others) when designing a parking service. Some of them may even need some level of standardisation. None of them are within the scope of this draft. > If we really want to solve the interoperability between SIP UA and > servers, then the handling of the feature should be clearly defined from > the SIP paradigma without being based too much on the classical PABX > paradigm. Else, we will always be locked to different kind of proprietary > solutions.=20 I disagree. Clearly defining the handling of the feature is an approach that is more likely to stifle innovation. Instead, we should take the approach selected for BLISS. From the BLISS charter: The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on=20 documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA=20 and servers(minimum set of primitives etc.), defining minimum levels=20 of functionality and functional primitives required to realize a broad=20 class of related features, and on interoperating with other elements=20 which might implement one of those features in different ways. > Some questions to think about: > 1. Why should an end-user be bothered with these park or orbit short > numbers? Is it not better to have a system which supports the end-user in > a much better way? When you have calls parked to your identity and waiting > in a queue, why do we then need short numbers? Is it not enough to pick-up > any SIP phone and enter your PIN code to inform the system where you are > and then the system can indicate the parked calls in another more > appropriate way. Your last sentence describes one of several traditional parking implementations, and can be achieved by using the technique proposed in my draft. The significance of the orbit is defined by policy not protocol, which means you can design systems such as the one you outline as well as several other variations without changing the equipment used (apart from configuring the policy in your park server, presumably). I am not suggesting that the approach outlined in my draft is the best approach, or indeed the only approach. The draft describes what strikes me as the simplest approach consistent with catering to the variations I had in mind. > 2. There is certainly a need for the call park/retrieve feature. Many > customers are still requesting it for reasons of cost reduction in their > telephony systems. E.g. workers in a logistic environment with a high > mobile profile but without mobile end devices (for cost reductions) and a > low called profile can benefit from the call park feature. The amount of > end devices can be limited, and any end-device can be used to retrieve a > parked call for and by a certain employee. When the amount of end-devices > is limited, why not offereing more flexibility in that end-device related > to the traditional PABX phones? I'm not sure what your question means. Can you clarify please? > 3. In other business environments, when users have mobile end devices, the > need for the call park/retrieve feature can disappear. E.g. this is the > case in business environments which first had fixed phones and when an > employee wanted to handle a call at his desk further at another location. > With a mobile device, the call park feature no longer makes sense. I disagree. Parking is still a useful feature with mobile devices - sometimes even more so (although then it can start to merge with other advanced call handling features such as line sharing). > 4. The handling of parked calls can also be different in IP networks as > for TDM networks. In a TDM network, there was always the cost for the > setup of a call and for the duration of a call. For an IP network, the > amount of parked calls and the duration of the parking can be much higher. > This requires another kind of user interface. I am not sure what you are suggesting here. If you are suggesting that different underlying technologies (TDM and SIP) require different user interfaces, then I disagree. If instead, you are suggesting that different underlying technologies may promote different usage patterns, which in turn may lead to more useful user interfaces being developed, then I agree. Nothing in my draft precludes such developments. If I decide to reissue this draft, then I will certainly bear your comments in mind during the rewrite. There is clearly much more that I can say to explain what I am trying to achieve. Regards, Michael _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 10 08:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Emz-0007XV-B2; Tue, 10 Jul 2007 08:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Emy-0007XD-4c for bliss@ietf.org; Tue, 10 Jul 2007 08:25:56 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Emx-0002jm-NK for bliss@ietf.org; Tue, 10 Jul 2007 08:25:56 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2007 08:25:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHYXk0ZAZnmf/2dsb2JhbACIUZ5Y X-IronPort-AV: i="4.16,522,1175486400"; d="scan'208"; a="125654099:sNHT34064390" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6ACPte7007206; Tue, 10 Jul 2007 08:25:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6ACPps0015968; Tue, 10 Jul 2007 12:25:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 08:25:50 -0400 Received: from [10.86.241.35] ([10.86.241.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 08:25:50 -0400 Message-ID: <46937ACD.2080002@cisco.com> Date: Tue, 10 Jul 2007 08:25:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 12:25:50.0313 (UTC) FILETIME=[73705D90:01C7C2ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6214; t=1184070355; x=1184934355; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Brian=20Stucker=20; bh=KbToOJv9R5VZBUWxco8vXLpuWqOBqf56npBuVWYqpL8=; b=RqXwhb2uZQw6wQbpLD5uHdCCnSQTk14PNeFJWuFu2j7DVNMM+WavgFxD0pVVLTelriDTyWFJ iR8GO7EwW5iDl13u8eMnCQPDzON6C1UaKpgJgWLOzYCwZaXiGma2sW0y; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian Stucker wrote: > Comments within. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, July 09, 2007 5:18 PM >> To: Jonathan Rosenberg >> Cc: bliss@ietf.org >> Subject: Re: [BLISS] BLISS problem statement draft >> >> Section 1 >> >>> The SIP specification itself includes primitives to >> support some of >>> these features. For example, RFC 3264 [2] defines SDP signaling >>> parameters for placing a call on hold... >> (This is little more than a nit.) >> >> RFC 3264 probably says more than it should about this. It is >> difficult to argue that those features (sendonly/recvonly) >> are *for* placing a call on hold. Rather they may *be useful >> when placing a call on hold*. >> The recipient of a reINVITE with a=sendonly in general cannot >> and should not conclude that it has been "put on hold". > > Although I agree with you technically, in reality I have yet to see a > widely available device that will not appear to go "on hold" if sent > a=sendonly. Indeed, even your own equipment does this if you look at the > Cisco IOS documentation available online (you thoughtfully allow people > to select between the bad-old way of 0.0.0.0 or a=sendonly). In general I don't control what Cisco builds. I know it has lots of things that violate lots of rules. I exert the influence I can. But I'm not sure exactly what you are saying here. In general it isn't necessary for the device on the receiving end to know whether it is on hold or not. What does it mean to "appear to go on hold"? Its different on the originating end. Of course it knows that it is going on hold. > Are we looking for best-possible implementation or basic level of > interoperability? These are two very different things. > >> I put some words about using offer/answer for hold in the >> offeranswer draft. But I think we could make a good case that >> this should be a subject for BLISS to pursue. >> > [snip] > >> Some cases where this sort of thing can be a problem are: >> >> - confusion about sendonly and hold. Some b2buas conclude that >> an invite with sendonly means hold. Based on local config >> they may reinvite the other end to a MoH server. >> >> It may however be the case that this wasn't intended as hold >> at all. Sendonly may have been offered because there is currently >> no ability to process received media, and there is a true desire >> to send media. > > Plausible but not very commmon for audio streams. Definitely more likely > with video streams. You left out one important detail about the way most > BBUAs handle MoH though, it's not that the media stream was set to > sendonly... It's that the media stream TRANSITIONED to a=sendonly from > a=sendrecv. You'll get all sorts of weird, yet avoidable, usecases if > you don't implement this tracking behavior. If everyone is happy with > using a=sendonly to denote hold (based on what we see that they've > implemented) no matter how wrong it may be, wouldn't this indicate a > successful level of interoperability? > > Again, trying to plumb where people's thoughts are: solve world hunger, > fix only the really bad stuff and leave the rest, or just find a way to > make everything work and call it a day. > >> - Uses of REFER often seem to have an aura of black magic. >> Receiving a REFER request gives information that one is requested >> to send a particular type of request to a specific destination. >> It doesn't explicitly say anything about: >> . if an offer should be included (if allowed for the request) >> . which media sources and sinks managed by the device should >> be included in the request. >> . what media types should be included in a request >> . what media formats should be offered >> . How resources should be shared with other existing sessions >> . ... >> >> Most published call flows for features involving REFER just show >> what happens, not how a decision is made about that. >> >> Note that even enumerating call flows for all features does >> not solve this problem, though in that case the problem will >> hopefully be discovered by developers trying to implement the >> features. >> >> The problem is that you cannot implement your role in a >> feature by following the call flow. Following the call flow >> requires knowing the state of the rest of the system at all times. >> >> Instead, the implementor of a particular node must build up a >> state machine based on information available based on the >> messages has received and sent. And then based on this state >> and new incoming messages it must decide what to do. It must >> consolidate the possibilities from all the call flows it >> might be participating in to achieve this. There is then a >> problem if there is some state and incoming event is >> consistent with two different call flows, which require >> different actions. There is currently no formal process to >> check if specifications have this property. > > Agree whole-heartedly. Call flow diagrams are tools of the devil. They > fool developers into thinking they have a complete implementation based > on their ability to reproduce a limited number of message flow diagrams > instead of understanding what the heck is really going on. They're > useful for purposes of discussion but somewhat evil for purposes of > specification (unless you want to spend a really large chunk of time > enumerating and managing them). State-machine diagrams are much simpler > to verify and still get you the a-picture-is-worth-a-thousand-words > benefits you can get with a call flow diagram. I don't think they are tools of the devil. They are quite useful - necessary but not sufficient. From a UML modeling perspective a call flow diagram is an "interaction diagram". It is useful for detailing a single use case. But of course a single use case doesn't make an algorithm. A collection of use cases is useful input for creating an algorithm. Thanks, Paul _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 10 11:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HTD-0006eo-Lr; Tue, 10 Jul 2007 11:17:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HTB-0006ZB-Us for bliss@ietf.org; Tue, 10 Jul 2007 11:17:42 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8HSw-0007lO-HA for bliss@ietf.org; Tue, 10 Jul 2007 11:17:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6AFGTa14316; Tue, 10 Jul 2007 15:16:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Tue, 10 Jul 2007 10:16:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> In-Reply-To: <46937ACD.2080002@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfC7Y8BwPTdoA5ORXaEWj6hy9jsEwAFksIw References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, July 10, 2007 7:26 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Jonathan Rosenberg; bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 >=20 >=20 > Brian Stucker wrote: > > Comments within. > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, July 09, 2007 5:18 PM > >> To: Jonathan Rosenberg > >> Cc: bliss@ietf.org > >> Subject: Re: [BLISS] BLISS problem statement draft > >> > >> Section 1 > >> > >>> The SIP specification itself includes primitives to > >> support some of > >>> these features. For example, RFC 3264 [2] defines SDP=20 > signaling > >>> parameters for placing a call on hold... > >> (This is little more than a nit.) > >> > >> RFC 3264 probably says more than it should about this. It is=20 > >> difficult to argue that those features (sendonly/recvonly)=20 > are *for*=20 > >> placing a call on hold. Rather they may *be useful when placing a=20 > >> call on hold*. > >> The recipient of a reINVITE with a=3Dsendonly in general cannot and = > >> should not conclude that it has been "put on hold". > >=20 > > Although I agree with you technically, in reality I have=20 > yet to see a=20 > > widely available device that will not appear to go "on=20 > hold" if sent=20 > > a=3Dsendonly. Indeed, even your own equipment does this if=20 > you look at=20 > > the Cisco IOS documentation available online (you=20 > thoughtfully allow=20 > > people to select between the bad-old way of 0.0.0.0 or = a=3Dsendonly). >=20 > In general I don't control what Cisco builds. I know it has=20 > lots of things that violate lots of rules. I exert the=20 > influence I can. >=20 > But I'm not sure exactly what you are saying here. In general=20 > it isn't necessary for the device on the receiving end to=20 > know whether it is on hold or not. What does it mean to=20 > "appear to go on hold"? >=20 > Its different on the originating end. Of course it knows that=20 > it is going on hold. Where applicable, devices tend to denote that they're on hold: flashing icon/button/etc, when they've been sent a=3Dsendonly after having been = at a=3Dsendrecv previously. My point was the question you didn't answer (just below): Are we looking for best-possible implementation or basic level of interoperability? These are two very different things. >=20 > > Are we looking for best-possible implementation or basic level of=20 > > interoperability? These are two very different things. > >=20 > >> I put some words about using offer/answer for hold in the=20 > offeranswer=20 > >> draft. But I think we could make a good case that this should be a=20 > >> subject for BLISS to pursue. > >> > > [snip] > >=20 > >> Some cases where this sort of thing can be a problem are: > >> > >> - confusion about sendonly and hold. Some b2buas conclude that > >> an invite with sendonly means hold. Based on local config > >> they may reinvite the other end to a MoH server. > >> > >> It may however be the case that this wasn't intended as hold > >> at all. Sendonly may have been offered because there=20 > is currently > >> no ability to process received media, and there is a=20 > true desire > >> to send media. > >=20 > > Plausible but not very commmon for audio streams. Definitely more=20 > > likely with video streams. You left out one important=20 > detail about the=20 > > way most BBUAs handle MoH though, it's not that the media=20 > stream was=20 > > set to sendonly... It's that the media stream TRANSITIONED to=20 > > a=3Dsendonly from a=3Dsendrecv. You'll get all sorts of weird, yet=20 > > avoidable, usecases if you don't implement this tracking=20 > behavior. If=20 > > everyone is happy with using a=3Dsendonly to denote hold=20 > (based on what=20 > > we see that they've > > implemented) no matter how wrong it may be, wouldn't this=20 > indicate a=20 > > successful level of interoperability? > >=20 > > Again, trying to plumb where people's thoughts are: solve world=20 > > hunger, fix only the really bad stuff and leave the rest,=20 > or just find=20 > > a way to make everything work and call it a day. Did you have any opinion on the above? > >=20 > >> - Uses of REFER often seem to have an aura of black magic. > >> Receiving a REFER request gives information that one=20 > is requested > >> to send a particular type of request to a specific=20 > destination. > >> It doesn't explicitly say anything about: > >> . if an offer should be included (if allowed for the request) > >> . which media sources and sinks managed by the device should > >> be included in the request. > >> . what media types should be included in a request > >> . what media formats should be offered > >> . How resources should be shared with other existing sessions > >> . ... > >> > >> Most published call flows for features involving=20 > REFER just show > >> what happens, not how a decision is made about that. > >> > >> Note that even enumerating call flows for all features=20 > does not solve=20 > >> this problem, though in that case the problem will hopefully be=20 > >> discovered by developers trying to implement the features. > >> > >> The problem is that you cannot implement your role in a feature by=20 > >> following the call flow. Following the call flow requires=20 > knowing the=20 > >> state of the rest of the system at all times. > >> > >> Instead, the implementor of a particular node must build=20 > up a state=20 > >> machine based on information available based on the messages has=20 > >> received and sent. And then based on this state and new incoming=20 > >> messages it must decide what to do. It must consolidate the=20 > >> possibilities from all the call flows it might be=20 > participating in to=20 > >> achieve this. There is then a problem if there is some state and=20 > >> incoming event is consistent with two different call flows, which=20 > >> require different actions. There is currently no formal process to=20 > >> check if specifications have this property. > >=20 > > Agree whole-heartedly. Call flow diagrams are tools of the=20 > devil. They=20 > > fool developers into thinking they have a complete implementation=20 > > based on their ability to reproduce a limited number of=20 > message flow=20 > > diagrams instead of understanding what the heck is really going on.=20 > > They're useful for purposes of discussion but somewhat evil for=20 > > purposes of specification (unless you want to spend a really large=20 > > chunk of time enumerating and managing them). State-machine=20 > diagrams=20 > > are much simpler to verify and still get you the=20 > > a-picture-is-worth-a-thousand-words > > benefits you can get with a call flow diagram. >=20 > I don't think they are tools of the devil. They are quite=20 > useful - necessary but not sufficient. >=20 > From a UML modeling perspective a call flow diagram is an=20 > "interaction diagram". It is useful for detailing a single=20 > use case. But of course a single use case doesn't make an=20 > algorithm. A collection of use cases is useful input for=20 > creating an algorithm. Agree, but people tend to look at the diagrams and less at the words. I've gone through many interop exercises that were built solely around call flow diagrams and they tend to suck up a LOT more time than necessary and produce a comparitively poor result. Specifying the algorithm is far more useful. >=20 > Thanks, > Paul >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 10 15:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LCW-0001FP-W7; Tue, 10 Jul 2007 15:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LCV-00016N-Cb for bliss@ietf.org; Tue, 10 Jul 2007 15:16:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8LCR-0008V4-1E for bliss@ietf.org; Tue, 10 Jul 2007 15:16:43 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2007 15:16:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJt3k0ZAZnmf/2dsb2JhbACIUZ57 X-IronPort-AV: i="4.16,523,1175486400"; d="scan'208"; a="125698314:sNHT27803886" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6AJGc3W012039; Tue, 10 Jul 2007 15:16:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6AJGPs4013622; Tue, 10 Jul 2007 19:16:38 GMT 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.1830); Tue, 10 Jul 2007 15:16:13 -0400 Received: from [10.86.241.35] ([10.86.241.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 15:16:12 -0400 Message-ID: <4693DAFB.8010900@cisco.com> Date: Tue, 10 Jul 2007 15:16:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 19:16:12.0934 (UTC) FILETIME=[C7AA2A60:01C7C326] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1400; t=1184094998; x=1184958998; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Brian=20Stucker=20; bh=ISME9meFayiqnbSMxtAkvFnos1XNSKj3dsXhe51Usms=; b=LkJHXizNRtF0lls+Jv+xJZ3IM/Gz3mSxnvbkyqE1eNRO/xjKSoh3ucm/yXbafBcnhGo23LEN 19xJe+hjYTpiFhAaMLfd4nY9EuV90GE0hsa3jbw6pGMTI96sD89NcOvN; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian Stucker wrote: >> But I'm not sure exactly what you are saying here. In general >> it isn't necessary for the device on the receiving end to >> know whether it is on hold or not. What does it mean to >> "appear to go on hold"? >> >> Its different on the originating end. Of course it knows that >> it is going on hold. > > Where applicable, devices tend to denote that they're on hold: flashing > icon/button/etc, when they've been sent a=sendonly after having been at > a=sendrecv previously. > > My point was the question you didn't answer (just below): Are we looking > for best-possible implementation or basic level of interoperability? > These are two very different things. I think for bliss we should be satisfied with a basic level of interoperability. In the case at hand I am satisfied that each end can go on and off hold as it desires, and that media flows (or doesn't flow) as desired. When I initiate "hold" I don't have any particular expectation that the other end is told explicitly that it has been put on hold. So the lack of an explicit "hold" indication on the far end doesn't bother me. However, in this particular case, it is indeed good for the far end to indicate that that it isn't permitted to transmit media. That is equally useful regardless of the reason. I don't require it, but it is a plus. Thanks, Paul _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 10 17:09:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mxx-0001AU-OS; Tue, 10 Jul 2007 17:09:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mxw-0001AI-AO for bliss@ietf.org; Tue, 10 Jul 2007 17:09:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Mxv-0005ne-Mi for bliss@ietf.org; Tue, 10 Jul 2007 17:09:48 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2007 17:09:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIaSk0ZAZnme/2dsb2JhbACIUZ8H X-IronPort-AV: i="4.16,523,1175486400"; d="scan'208"; a="125712902:sNHT61534076" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6AL9dCX028003; Tue, 10 Jul 2007 17:09:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6AL9Gs6010905; Tue, 10 Jul 2007 21:09:21 GMT 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.1830); Tue, 10 Jul 2007 17:09:16 -0400 Received: from [10.86.241.35] ([10.86.241.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 17:09:16 -0400 Message-ID: <4693F57A.6080905@cisco.com> Date: Tue, 10 Jul 2007 17:09:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Huelsemann, Martin" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 21:09:16.0187 (UTC) FILETIME=[92CC6EB0:01C7C336] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10630; t=1184101779; x=1184965779; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20latest=20call-completion=20draft |Sender:=20 |To:=20=22Huelsemann,=20Martin=22=20; bh=uqPqGWgWdJgIDl1fPZJZG8eU6PdcpKeqtUiS4cb8+bc=; b=KIP0+szsc/2/kUdMBRmSusyPISBygBTwmu9LLDnZps2bcaFuY026J14ANzhNpxEdVamTHjTi 5OIPmMK7QKSxh+4nKkoHbSwKyn5UAFoxd+JxHzOIpT2QTJToWE155Rxf; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: adam@nostrum.com, mhammer@cisco.com, bliss@ietf.org, dean.willis@softarmor.com, "Alexeitsev, D" Subject: [BLISS] Re: latest call-completion draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org [Removing sipping from the mailing list becasue cross posting is annoying.] Thank you for producing this revised version! It goes a long way toward addressing the problems that have been raised before - at least those raised by me. I think the direction is quite reasonable now. I still have comments to make, but they are refinements. General Issue: IMO it isn't clear what resource the subscription is targeted to. From the text it seems that it is the *queue*. But that leads to problems about who is notified when. There is some implied relationship between subscribers and queue *entries* but that is not explained. I think this would better modeled as subscription to queue *entries*. What is lacking is how the entry is referenced in the subscription request. I can see a couple of possibilities: - the entry could be identified explicitly. E.g. there could be an event parameter containing the callid of the failing call that caused the queue entry to be made. - it could be implicit - when the subscription request (to the AOR) is received and processed, an association to an entry could be made - perhaps by matching the From address of the subscriber with the From address of the caller. I think either way can be made to work. What is needed is some text that explains this. Part of this is probably to be more explicit in modeling the queue itself - what it contains, when things are added and removed, etc. (This would also provide a place to identify odd cases, such as when a particular caller makes multiple call attempts to the callee. In that case, are multiple entries made in the queue, or what?) If the subscription is modeled as being to an *entry* then many things get simpler and clearer. For instance one class of errors occurs when no matching entry can be found. The triggering event for a notification is then very simple - it is when the state of the *entry* changes from "queued" to "ready-for-call-completion". Another small issue: there is no mention of how long a subscriber has to make a call completion attempt after receiving a "ready-for-call-completion" notification. Presumably at some point there is a state change back to queued, or the entry is removed altogether. It would be good to tell the subscriber about this. Perhaps the "ready-for-call-completion" notification could carry the amount of time allotted for the attempt. This also should probably also be part of the model of the queue. The following are more localized comments about particular parts of the draft. > 3. > Overview > > Completion of Calls on no Reply (CCNR) provides the cability to > queue not answered calls from several callers to a callee and to > inform the caller that he can initiate a call-completion call after > the callee has become not busy after having initiated an activity. The above is a pretty narrow definition. Isn't the *goal* to inform the caller when the callee is available? In some implementations "callee has become not busy after having initiated an activity" may be the best that can be done to determine availability. But should that be enshrined in the specification? For instance in some cases there may be other presence sources. E.g. if the callee device is a softphone on a PC then typing on the keyboard is also an indication of presence. > 5.1 > Proposed solution > ... A NOTIFY > request that reports that the callee is available for a call- > completion call attempt to be made will cause the subscriber to > trigger the establishment of that call, subject to the caller being > available too. Its a stretch to say the notification will *cause* the subscriber to call. All it does is inform the caller that it *may* initiate a call with reasonable expectation of success. How about: "A NOTIFY request that reports the callee is available for a call-compleion call attempt to be made will inform the subscriber that it has an opportunity to attempt establishment of that call." > ... It is > assumed that the call-completion service logic can distinguish > between a new subscription and a resuming subscription, when there > is an entry for the subscriber in the call completion queue. Why should it matter? Either somebody is interested in the entry, or nobody is. If it really does matter (which I doubt) then the model of the queue, which I requested above, should explain what this extra state is and why it is important. > 6.7 > Notifier Processing of SUBSCRIBE Requests > > Upon receiving a subscription refresh, the notifier MUST set the > "expires" parameter of the Subscription-State header to the current > remaining duration of the subscription regardless of the value > received in the Expires header (if present) of the subscription > refresh. This needs to be changed somewhat for compliance with 3265. The response to the subscription refresh must not return a value larger than in the request. I gather you don't want the subscription to remain once the queue entry it is associated with ages out of the queue. You *could* define the maximum value based on that time. Or you could just terminate the subscription, sending a final NOTIFY with Terminated status, when it ages out. It is probably better to do that, because otherwise the subscriber may decide that it needs to refresh the subscription just before it is about to age out. > If a subscription is not successful because the call-completion > queue has reached the maximum number of entries (short term > denial), the notifier MUST send a 480 Temporarily Unavailable > response to the subscriber. > If a subscription is not successful because a general error that > prevents the call-completion service has occurred (long term > denial), the notifier MUST send a 403 Forbidden response to the > subscriber. I'm confused by this. As I understand it, the queue is populated as call attempts fail. I do understand that if the queue is full, it may be that another call attempt may fail to be queued. But that has nothing to do with the subscription, which simply checks on the status of an entry in the queue. If an entry was not queued, due to the queue being full, then a subsequent subscription inquiring about that entry will be able to tell that there is no such entry, but won't be able to discern *why* the entry is absent. Nor will a subsequent subscription request somehow be able to get a different conclusion in this case. Or are you limiting the number of subscribers to the event? Under normal circumstances one would expect that the number of subscriptions would be less than or equal to the number of entries in the queue. It would be unwise for an implementation to allow fewer subscriptions than that. There could be more, for valid or invalid reasons. A valid reason might be if the caller has multiple devices, using the same identity, that wish to track the same queue entry. An invalid reason would be when devices subscribe but have no entry in the queue. The invalid case can be handled by 403 as you suggest, or by a 200 response with a single NOTIFY that terminates the subscription and indicates no entry in the queue. The valid case could be handled by 480 as you suggest. Maybe this would all be clearer if you provide a sufficient model of the queue. > 7.2 > service-retention > > The service-retention indicates the support of the retain option. > The retain option, if supported at the callee, will maintain the > entry in the call-completion queue, if a call-completion call has > failed due to destination busy condition. If present, this > parameter indicates that the retain option is supported, otherwise > it is not supported. This parameter MAY be present in NOTIFY > requests. I'm confused about this "option". In what sense is it an option? I gather this is not an option requested by the subscriber or caller, but rather is an implementation choice on the part of the notifier. Is that right? So from the point of view of the subscriber this simply says what to expect after it tries and fails to make a call-completion call??? IMO this deserves more complete explanation, even if I got it right. It sounds like there might be two different models for queue management. If so, when modeling the queue you should show both models and specify that a node may choose (or be configured) to support one or the other. > 8. > Signaling Flows All the NOTIFYs have the To/From URIs interchanged. (The To/From of the NOTIFY should be reversed from that in the SUBSCRIBE.) > 9. > Security Considerations Given the intended usage, I think it might be better to give more guidance. In particular I suggest that in the absence of some explicit policy to the contrary, subscriptions SHOULD only be allowed from the same identity that made the original call attempt. Thanks, Paul Huelsemann, Martin wrote: > > > Hi all, > > the latest call-completion draft has been uploaded, as agreed > call-completion was shifted to BLISS, so you can find the result under > _http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00.txt_. > > The main issue of the discussion on the mailing list was the usage of > SUBSCRIBE bodies for queue manipulation actions (e.g. add, suspend, > resume), which is not in accordance with RFC 3265. > > The solution discussed was the scenario, where not answered calls > (because of busy or no reply) are getting queued at the callee, and the > caller is informed that he can receive call-completion information, > which would inform him that he is either still queued, or that he can > start the recall. > > So what is described now is a proposal for a pure call-completion event > package with the values 'queued' and 'ready-for-call-completion' (and an > additional value for service retention), so no more queue manipulation > parameters in the SUBSCRIBE body, and the proposed usage of the > Allow-events in 180 and 486. > > Suspending and resuming would be done by un-subscribing and subscribing > again to the call-completion event package. > > > Comments and questions are welcome. > > > > Regards, Martin > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jul 11 02:24:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Vcl-0002tK-Mm; Wed, 11 Jul 2007 02:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Vci-0002tC-SW for bliss@ietf.org; Wed, 11 Jul 2007 02:24:29 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Vce-0006Ao-AW for bliss@ietf.org; Wed, 11 Jul 2007 02:24:28 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Wed, 11 Jul 2007 08:24:23 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 08:24:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Jul 2007 08:24:22 +0200 Message-Id: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-poetzl-bliss-call-completion-00 uploaded Thread-Index: AcfCH5f9WpKZRVbYTdmlHQJ6AnUcswBY6gaA From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 11 Jul 2007 06:24:22.0831 (UTC) FILETIME=[1F1AFBF0:01C7C384] X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: adam@nostrum.com, mhammer@cisco.com, "Alexeitsev, D" Subject: [BLISS] draft-poetzl-bliss-call-completion-00 uploaded X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770343042==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============1770343042== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C384.1EB8DFF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C384.1EB8DFF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, the latest call-completion draft has been uploaded, as agreed=20 call-completion was shifted to BLISS, so you can find the=20 result under=20 http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00= .txt. The main issue of the discussion on the mailing list was the=20 usage of SUBSCRIBE bodies for queue manipulation actions=20 (e.g. add, suspend, resume), which is not in accordance with RFC 3265. The solution discussed was the scenario, where not answered=20 calls (because of busy or no reply) are getting queued at the=20 callee, and the caller is informed that he can receive=20 call-completion information, which would inform him that he=20 is either still queued, or that he can start the recall. So what is described now is a proposal for a pure=20 call-completion event package with the values 'queued' and=20 'ready-for-call-completion' (and an additional value for=20 service retention), so no more queue manipulation parameters=20 in the SUBSCRIBE body, and the proposed usage of the=20 Allow-events in 180 and 486.=20 Suspending and resuming would be done by un-subscribing and=20 subscribing again to the call-completion event package. Comments and questions are welcome. Regards, Martin ------_=_NextPart_001_01C7C384.1EB8DFF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-poetzl-bliss-call-completion-00 uploaded

Hi all,

the latest call-completion draft has = been uploaded, as agreed
call-completion was shifted to BLISS, = so you can find the
result under
http://www.ietf.org/internet-drafts/draft-poetzl-bliss-cal= l-completion-00.txt.

The main issue of the discussion on the = mailing list was the
usage of SUBSCRIBE bodies for queue = manipulation actions
(e.g. add, suspend, resume), which is = not in accordance with RFC 3265.

The solution discussed was the = scenario, where not answered
calls (because of busy or no reply) = are getting queued at the
callee, and the caller is informed = that he can receive
call-completion information, which = would inform him that he
is either still queued, or that he can = start the recall.

So what is described now is a proposal for a pure =
call-completion event package with the = values 'queued' and
'ready-for-call-completion' = (and = an additional value for
service retention), so no more queue = manipulation parameters
in the SUBSCRIBE body, and = the proposed usage of the
Allow-events in 180 and = 486.
Suspending and resuming would be done = by un-subscribing and
subscribing again to the = call-completion event package.


Comments and questions are = welcome.

Regards, Martin



------_=_NextPart_001_01C7C384.1EB8DFF8-- --===============1770343042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1770343042==-- From bliss-bounces@ietf.org Thu Jul 12 15:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93wt-0005t8-An; Thu, 12 Jul 2007 15:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93ws-0005sG-Cw for bliss@ietf.org; Thu, 12 Jul 2007 15:03:34 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I93wn-00018j-Sf for bliss@ietf.org; Thu, 12 Jul 2007 15:03:34 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JL20079DY9GMU@siemenscomms.co.uk> for bliss@ietf.org; Thu, 12 Jul 2007 20:03:16 +0100 (BST) Date: Thu, 12 Jul 2007 20:03:28 +0100 From: "Elwell, John" Subject: RE: [BLISS] BLISS problem statement draft In-reply-to: <46897CB3.9050609@cisco.com> To: Jonathan Rosenberg , bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: Ace8+MvW2p9n7zIESwuXZVGVRtaldgHvNzbw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46897CB3.9050609@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan, I like the methodology proposed. One point of detail concerning the particular example given: "In the case of CFNA, clearly a functional primitive of "call forwarding features that execute on no-answer" is too narrow. A functional primitive of "features that handle an initial INVITE" is too broad. An ideal starting point would probably be, "features that result in a retargeting or response operation that depend on user-specified criteria". This covers all of the call forwarding variations, but also includes features like Do-Not- Disturb." I agree that one action that can be taken on DND is to forward (e.g., to voicemail, to an assistant). However, the bliss-dnd draft covers more than this, in particular what to indicate to the caller, how to clearly indicate DND to the proxy if the proxy is responsible for forwarding, and what to indicate in presence. These aspects are somewhat different from the call forwarding set of problems. I prefer to regard it as an interaction between two groups of features (or two functional primitives) - the DND group and the forwarding group. In fact the problem of interactions will come up a lot, for example impact of call forwarding on shared line appearance. We have to draw lines between groups of features somewhere and accept that there will be interactions between groups and find out ways to handle these interactions (in a way that does not constrain implementations but does not lead to unpredictable or undesirable behaviour). Otherwise we will end up with just one huge and unmanageable group. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 02 July 2007 23:31 > To: bliss@ietf.org > Subject: [BLISS] BLISS problem statement draft > > I've submitted a draft that provides a problem statement around what > BLISS is trying to solve, and defines a framework for solving it. It > uses concrete examples the whole way through so we can be > clear on what > we are talking about. Until it appears in the archives, you > can pick it > up here: > > http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-st > atement-00.txt > > This is something I should have gotten out a month or so > back, so that > we could have used it as a context for discussion and draft > writing in > the remaining time. I apologize for getting this in just before the > deadline - too late to be useful for anyone elses drafts. > > I think its really important that we discuss this draft and get > agreement on it. Its really trying to define the process by which we > will be doing our work. > > 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 > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 16 04:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMBF-0005AM-8Q; Mon, 16 Jul 2007 04:43:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMBE-00057n-21 for bliss@ietf.org; Mon, 16 Jul 2007 04:43:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAMBA-00031d-Gy for bliss@ietf.org; Mon, 16 Jul 2007 04:43:44 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E357321AF0; Mon, 16 Jul 2007 10:43:39 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-96-469b2fbb31cb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C904121641; Mon, 16 Jul 2007 10:43:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 10:43:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Mon, 16 Jul 2007 10:43:38 +0200 Message-ID: <7374777208BDC7449D5620EF94232567072B6638@esealmw113.eemea.ericsson.se> In-Reply-To: <46897CB3.9050609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: Ace8+Mtc9RT46pKNTPmJ5DGz2PLXZwKi+HJQ References: <46897CB3.9050609@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 16 Jul 2007 08:43:39.0405 (UTC) FILETIME=[6813BBD0:01C7C785] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Jonathan,=20 I have a few questions for clarification.=20 First, how are we going to define each feature? Will we do a "feature = definition", or will we (if possible) use existing documentation which = defines the features? For example, the feature names you have listed all = exist as supplementary services, with existing service definition. Second, chapter 5.2 says "Participants can also suggest flows they think = might exist". Does that cover flows that other SDOs have produced, e.g. = a TISPAN flow for a supplementary service which is similar to a specific = "feature"? Regards,=20 Christer=20 =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 3. hein=E4kuuta 2007 1:31 > To: bliss@ietf.org > Subject: [BLISS] BLISS problem statement draft >=20 > I've submitted a draft that provides a problem statement=20 > around what BLISS is trying to solve, and defines a framework=20 > for solving it. It uses concrete examples the whole way=20 > through so we can be clear on what we are talking about.=20 > Until it appears in the archives, you can pick it up here: >=20 > http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-st > atement-00.txt >=20 > This is something I should have gotten out a month or so=20 > back, so that we could have used it as a context for=20 > discussion and draft writing in the remaining time. I=20 > apologize for getting this in just before the deadline - too=20 > late to be useful for anyone elses drafts. >=20 > I think its really important that we discuss this draft and=20 > get agreement on it. Its really trying to define the process=20 > by which we will be doing our work. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 16 08:26:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAPeL-000313-00; Mon, 16 Jul 2007 08:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAPeJ-00030f-T2 for bliss@ietf.org; Mon, 16 Jul 2007 08:25:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAPeF-0008CU-Gj for bliss@ietf.org; Mon, 16 Jul 2007 08:25:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2007 08:25:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAD8Am0ZAZnmf/2dsb2JhbACIWJ1b X-IronPort-AV: i="4.16,541,1175486400"; d="scan'208"; a="126132410:sNHT30330754" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6GCPtNU029560; Mon, 16 Jul 2007 08:25:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6GCPfWS019059; Mon, 16 Jul 2007 12:25:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 08:25:47 -0400 Received: from [10.86.243.34] ([10.86.243.34]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 08:25:47 -0400 Message-ID: <469B63CA.5080004@cisco.com> Date: Mon, 16 Jul 2007 08:25:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <7374777208BDC7449D5620EF94232567072B6638@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567072B6638@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jul 2007 12:25:47.0527 (UTC) FILETIME=[7041C170:01C7C7A4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2841; t=1184588755; x=1185452755; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=hpRuqvt6cfz1Bz/lEfa4rnfKnK+rYGZkj9mHL+JCZeA=; b=BEUXl3+62KaXP6cHdQrExYRB2XKAY+BKy2O5uapwe81Bphm3+ZGKRLnNtZS248xxBfFddNe3 tjHW89RWw4qmYW8ybJxAlz/0aQxyr0Xupfy96a1NoP+xy9Om1YES1DcK; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi Jonathan, I'm not speaking for Jonathan. The following is my opinion. > I have a few questions for clarification. > > First, how are we going to define each feature? Will we do a "feature definition", or will we (if possible) use existing documentation which defines the features? For example, the feature names you have listed all exist as supplementary services, with existing service definition. My experience is that it is very difficult to get universal agreement on the precise definition of features. There are indeed lots of definitions of similar features. For that reason Jonathan is focusing on loosely defined groups of similar/related features. > Second, chapter 5.2 says "Participants can also suggest flows they think might exist". Does that cover flows that other SDOs have produced, e.g. a TISPAN flow for a supplementary service which is similar to a specific "feature"? IMO it is quite appropriate to bring in definitions from other SDOs. Paul > Regards, > > Christer > > > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 3. heinäkuuta 2007 1:31 >> To: bliss@ietf.org >> Subject: [BLISS] BLISS problem statement draft >> >> I've submitted a draft that provides a problem statement >> around what BLISS is trying to solve, and defines a framework >> for solving it. It uses concrete examples the whole way >> through so we can be clear on what we are talking about. >> Until it appears in the archives, you can pick it up here: >> >> http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-st >> atement-00.txt >> >> This is something I should have gotten out a month or so >> back, so that we could have used it as a context for >> discussion and draft writing in the remaining time. I >> apologize for getting this in just before the deadline - too >> late to be useful for anyone elses drafts. >> >> I think its really important that we discuss this draft and >> get agreement on it. Its really trying to define the process >> by which we will be doing our work. >> >> 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 >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 16 09:14:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQPA-0000C0-Ux; Mon, 16 Jul 2007 09:14:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQP9-0000Bn-Ph for bliss@ietf.org; Mon, 16 Jul 2007 09:14:23 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAQP9-0005GZ-Ak for bliss@ietf.org; Mon, 16 Jul 2007 09:14:23 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id DA5532C11E; Mon, 16 Jul 2007 09:13:50 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odHGNYOSIJwe; Mon, 16 Jul 2007 09:13:49 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 54A242C115; Mon, 16 Jul 2007 09:13:49 -0400 (EDT) In-Reply-To: <469B63CA.5080004@cisco.com> To: Paul Kyzivat Subject: Re: [BLISS] BLISS problem statement draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: dan_york@Mitel.com Date: Mon, 16 Jul 2007 09:13:55 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/16/2007 09:13:48 AM, Serialize complete at 07/16/2007 09:13:48 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1248898345==" Errors-To: bliss-bounces@ietf.org This is a multipart message in MIME format. --===============1248898345== Content-Type: multipart/alternative; boundary="=_alternative 0048ACFB8525731A_=" This is a multipart message in MIME format. --=_alternative 0048ACFB8525731A_= Content-Type: text/plain; charset="US-ASCII" Christer, Paul Kyzivat wrote: > Christer Holmberg (JO/LMF) wrote: > > Hi Jonathan, > > I'm not speaking for Jonathan. The following is my opinion. > > > I have a few questions for clarification. > > > > First, how are we going to define each feature? Will we do a "feature definition", > > or will we (if possible) use existing documentation which defines the features? > > For example, the feature names you have listed all exist as supplementary services, > > with existing service definition. I guess I suffer a knee-jerk negative reaction to the term "feature definition" because I am suddenly thinking in terms of *marketing* definitions of features. And the reality is that to a degree those definitions will always be different as vendors try for "competitive differentiation". ("Our call forwarding works better that Vendor X's because we maximize the synergistic relativity paradigm", etc.) How precisely do you want to define a feature? Or are you thinking in terms of the feature interoperability? I guess my concern with using 'existing documentation' would come back to "whose documentation do you use?" If it's documentation from another standards body, I don't really have an issue. If it is documentation from a vendor, we'll get into all sorts of concerns from other competing vendors, IMHO. > My experience is that it is very difficult to get universal agreement on > the precise definition of features. There are indeed lots of definitions > of similar features. For that reason Jonathan is focusing on loosely > defined groups of similar/related features. I agree with Paul that we should avoid getting bogged down in the precise definitions of features and stay focused on defining the mechanism that allows interoperability. To jump to a completely different context, vendor A may be say "tomato" as "toe-MAY-toe" and view it as a vegetable. Vendor B may spell it "tomatoe", say it "toe-MAH-toe" and view it as a fruit. We (IETF) need to be saying that however you spell it, say it or view it, if you slice it in this particular way it will sit nicely on most hamburgers or sandwiches. > > Second, chapter 5.2 says "Participants can also suggest flows they think might exist". > > Does that cover flows that other SDOs have produced, e.g. a TISPAN flow for a > > supplementary service which is similar to a specific "feature"? > > IMO it is quite appropriate to bring in definitions from other SDOs. Agreed. My 2 cents, Dan -- Dan York, CISSP Dir of IP Technology, Office of the CTO Mitel http://www.mitel.com dan_york@mitel.com +1-613-592-2122 PGP key (F7E3C3B4) available for secure communication --=_alternative 0048ACFB8525731A_= Content-Type: text/html; charset="US-ASCII"
Christer,

Paul Kyzivat <pkyzivat@cisco.com> wrote:
> Christer Holmberg (JO/LMF) wrote:
> > Hi Jonathan,
>
> I'm not speaking for Jonathan. The following is my opinion.
>
> > I have a few questions for clarification.
> >
> > First, how are we going to define each feature? Will we do a "feature definition",
> > or will we (if possible) use existing documentation which defines the features?
> > For example, the feature names you have listed all exist as supplementary services,
> > with existing service definition.
I guess I suffer a knee-jerk negative reaction to the term "feature definition"
because I am suddenly thinking in terms of *marketing* definitions of features.
And the reality is that to a degree those definitions will always be different as
vendors try for "competitive differentiation".  ("Our call forwarding works better
that Vendor X's because we maximize the synergistic relativity paradigm", etc.)

How precisely do you want to define a feature?  Or are you thinking in terms of the
feature interoperability?

I guess my concern with using 'existing documentation' would come back to "whose
documentation do you use?"  If it's documentation from another standards body, I don't
really have an issue.  If it is documentation from a vendor, we'll get into all sorts
of concerns from other competing vendors, IMHO.

> My experience is that it is very difficult to get universal agreement on
> the precise definition of features. There are indeed lots of definitions
> of similar features. For that reason Jonathan is focusing on loosely
> defined groups of similar/related features.
I agree with Paul that we should avoid getting bogged down in the precise definitions
of features and stay focused on defining the mechanism that allows interoperability.  

To jump to a completely different context, vendor A may be say "tomato" as "toe-MAY-toe"
and view it as a vegetable.  Vendor B may spell it "tomatoe", say it "toe-MAH-toe" and view
it as a fruit.  We (IETF) need to be saying that however you spell it, say it or view it,
if you slice it in this particular way it will sit nicely on most hamburgers or sandwiches.

> > Second, chapter 5.2 says "Participants can also suggest flows they think might exist".
> > Does that cover flows that other SDOs have produced, e.g. a TISPAN flow for a
> > supplementary service which is similar to a specific "feature"?
>
> IMO it is quite appropriate to bring in definitions from other SDOs.

Agreed.

My 2 cents,
Dan

--
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel       http://www.mitel.com
dan_york@mitel.com +1-613-592-2122
PGP key (F7E3C3B4) available for
secure communication --=_alternative 0048ACFB8525731A_=-- --===============1248898345== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1248898345==-- From bliss-bounces@ietf.org Mon Jul 16 19:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZiK-000678-CP; Mon, 16 Jul 2007 19:10:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZiJ-00066v-Lt for bliss@ietf.org; Mon, 16 Jul 2007 19:10:47 -0400 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAZiJ-0006nO-BB for bliss@ietf.org; Mon, 16 Jul 2007 19:10:47 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6GNAMnQ014702 for ; Mon, 16 Jul 2007 17:10:22 -0600 Message-ID: <469BFADB.2030206@ntt-at.com> Date: Mon, 16 Jul 2007 16:10:19 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [BLISS] agenda uploaded X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Agenda for the upcoming meeting is available at: http://www3.ietf.org/proceedings/07jul/agenda/bliss.html Send in any comments please. Regards Shida _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 17 06:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkIl-0000nc-7n; Tue, 17 Jul 2007 06:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkIk-0000nS-DC for bliss@ietf.org; Tue, 17 Jul 2007 06:29:06 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAkIf-0000hK-LG for bliss@ietf.org; Tue, 17 Jul 2007 06:29:06 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0D47F20B95; Tue, 17 Jul 2007 12:29:01 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-15-469c99ec73ec Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EE37220BBF; Tue, 17 Jul 2007 12:29:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:29:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Tue, 17 Jul 2007 12:28:59 +0200 Message-ID: <7374777208BDC7449D5620EF94232567073438EE@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfHqyoJbNqw98VrTra3BJ3/8M4s9AAnjJKw References: <469B63CA.5080004@cisco.com> From: "Christer Holmberg (JO/LMF)" To: , "Paul Kyzivat" X-OriginalArrivalTime: 17 Jul 2007 10:29:00.0508 (UTC) FILETIME=[4A2941C0:01C7C85D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi,=20 >>Ihave a few questions for clarification.=20 >>=20 >>First, how are we going to define each feature? Will we do a "feature definition",=20 >>or will we (if possible) use existing documentation which defines the features?=20 >>For example, the feature names you have listed all exist as supplementary services,=20 >>with existing service definition. >=09 >I guess I suffer a knee-jerk negative reaction to the term "feature definition"=20 >because I am suddenly thinking in terms of *marketing* definitions of features.=20 >And the reality is that to a degree those definitions will always be different as=20 >vendors try for "competitive differentiation". ("Our call forwarding works better=20 >that Vendor X's because we maximize the synergistic relativity paradigm", etc.)=20 > >How precisely do you want to define a feature? Or are you thinking in terms of the=20 >feature interoperability?=20 >=09 >I guess my concern with using 'existing documentation' would come back to "whose=20 >documentation do you use?" If it's documentation from another standards body, I don't=20 >really have an issue. If it is documentation from a vendor, we'll get into all sorts=20 >of concerns from other competing vendors, IMHO.=20 When it comes to features based on standardized supplementary services, I was thinking of documentation from other standard bodies, not from specific vendors. =09 >My experience is that it is very difficult to get universal agreement on=20 >the precise definition of features. There are indeed lots of definitions=20 >of similar features. For that reason Jonathan is focusing on loosely=20 >defined groups of similar/related features. The preciseness can be discussed. >I agree with Paul that we should avoid getting bogged down in the precise definitions=20 >of features and stay focused on defining the mechanism that allows interoperability. =20 You need to say what the feature is supposed to do, in order to allow interoperability. =09 >To jump to a completely different context, vendor A may be say "tomato" as "toe-MAY-toe"=20 >and view it as a vegetable. Vendor B may spell it "tomatoe", say it "toe-MAH-toe" and view=20 >it as a fruit. We (IETF) need to be saying that however you spell it, say it or view it,=20 >if you slice it in this particular way it will sit nicely on most hamburgers or sandwiches.=20 Yes, but unless you define that you are going to slice the tomato, someone could make ketchup out of it... Yes, you can still put ketchup on your burger, but if I ask for sliced tomates I don't get what I want :) Regards, Christer _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 17 10:17:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAnsC-0002hk-Oy; Tue, 17 Jul 2007 10:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAnsA-0002fn-Br for bliss@ietf.org; Tue, 17 Jul 2007 10:17:54 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAns8-00011H-VK for bliss@ietf.org; Tue, 17 Jul 2007 10:17:54 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id BA6822C099; Tue, 17 Jul 2007 10:17:52 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFzGhCJpHLnx; Tue, 17 Jul 2007 10:17:51 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 6908D2C060; Tue, 17 Jul 2007 10:17:51 -0400 (EDT) In-Reply-To: <7374777208BDC7449D5620EF94232567073438EE@esealmw113.eemea.ericsson.se> To: "Christer Holmberg (JO/LMF)" Subject: RE: [BLISS] BLISS problem statement draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: dan_york@Mitel.com Date: Tue, 17 Jul 2007 10:17:49 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/17/2007 10:17:50 AM, Serialize complete at 07/17/2007 10:17:50 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590538761==" Errors-To: bliss-bounces@ietf.org This is a multipart message in MIME format. --===============1590538761== Content-Type: multipart/alternative; boundary="=_alternative 004E86948525731B_=" This is a multipart message in MIME format. --=_alternative 004E86948525731B_= Content-Type: text/plain; charset="US-ASCII" Christer, > When it comes to features based on standardized supplementary services, > I was thinking of documentation from other standard bodies, not from > specific vendors. Sounds reasonable. > You need to say what the feature is supposed to do, in order to allow > interoperability. I completely agree... perhaps I am just getting hung up on "feature definition" and the level to which it is described. I guess when I think of something like "DND", we do need a high-level "definition" that says what it will do and then agreement on how to interoperate (really the "feature groups" of Jonathan's text). My concern is how far down we define what "DND" is and does. If we get extremely specific, it may cause friction with some vendors who want more flexibility. As I write this, though, it does occur to me that one of the simplest approaches may just be to see how specific we *can* make these initial 4 pieces of the SIP interop puzzle and just say "if you want to be interoperable, thou shalt implement it THIS way" and be done with it. If we can get enough of the vendors behind a specific implementation we'd have the market pressure that would encourage others to come along. (If only things were that simple...) > > We (IETF) need to be saying that however you spell it, > say it or view it, > >if you slice it in this particular way it will sit nicely on most > hamburgers or sandwiches. > > Yes, but unless you define that you are going to slice the tomato, > someone could make ketchup out of it... > > Yes, you can still put ketchup on your burger, but if I ask for sliced > tomates I don't get what I want :) Many thanks for the witty response... it gave me a good laugh! Regards, Dan -- Dan York, CISSP Dir of IP Technology, Office of the CTO Mitel http://www.mitel.com dan_york@mitel.com +1-613-592-2122 PGP key (F7E3C3B4) available for secure communication --=_alternative 004E86948525731B_= Content-Type: text/html; charset="US-ASCII"

Christer,

> When it comes to features based on standardized supplementary services,
> I was thinking of documentation from other standard bodies, not from
> specific vendors.
Sounds reasonable.

> You need to say what the feature is supposed to do, in order to allow
> interoperability.
I completely agree... perhaps I am just getting hung up on "feature
definition" and the level to which it is described. I guess when I think
of something like "DND", we do need a high-level "definition" that says
what it will do and then agreement on how to interoperate (really the
"feature groups" of Jonathan's text).  My concern is how far down we
define what "DND" is and does.  If we get extremely specific, it may
cause friction with some vendors who want more flexibility.

As I write this, though, it does occur to me that one of the simplest
approaches may just be to see how specific we *can* make these initial
4 pieces of the SIP interop puzzle and just say "if you want to be
interoperable, thou shalt implement it THIS way" and be done with it.
If we can get enough of the vendors behind a specific implementation
we'd have the market pressure that would encourage others to come along.
(If only things were that simple...)
                 
> > We (IETF) need to be saying that however you spell it,
> say it or view it,
> >if you slice it in this particular way it will sit nicely on most
> hamburgers or sandwiches.
>
> Yes, but unless you define that you are going to slice the tomato,
> someone could make ketchup out of it...
>
> Yes, you can still put ketchup on your burger, but if I ask for sliced
> tomates I don't get what I want :)

Many thanks for the witty response... it gave me a good laugh!

Regards,
Dan

--
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel       http://www.mitel.com
dan_york@mitel.com +1-613-592-2122
PGP key (F7E3C3B4) available for
secure communication --=_alternative 004E86948525731B_=-- --===============1590538761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1590538761==-- From bliss-bounces@ietf.org Tue Jul 17 12:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApkY-00048H-4D; Tue, 17 Jul 2007 12:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApkX-00048C-7B for bliss@ietf.org; Tue, 17 Jul 2007 12:18:09 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IApkW-0005uK-8j for bliss@ietf.org; Tue, 17 Jul 2007 12:18:09 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Tue, 17 Jul 2007 18:17:57 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 18:17:57 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Jul 2007 18:17:52 +0200 Message-Id: In-Reply-To: <4693F57A.6080905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: latest call-completion draft Thread-Index: AcfDNqfMIBxc9cHBSlG1vxd9w9oO2AFLPPLA From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 17 Jul 2007 16:17:57.0051 (UTC) FILETIME=[095030B0:01C7C88E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: adam@nostrum.com, mhammer@cisco.com, dennis.luebbers@nsn.com, jean-marie.stupka@nsn.com, bliss@ietf.org, "Alexeitsev, D" Subject: [BLISS] AW: latest call-completion draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Paul, I've never seen the mail in my BLISS folder, but it's in the BLISS = archive, so I think it works when I answer on the list. A lot of comments, thanks. The answers are included in the text below. One major issue for the next revision seems to provide a more exact = explanation of model for the queue. Shortly: When a call ends in busy, a queue entry is created (to which the caller = can subscribe).=20 The queue entry is deleted after timer expiry, or during the = call-completion attempt. For the latter there are two options:=20 1) every call-completion attempt deletes the entry, or=20 2) only a successful call-completion attempt (the callee is not busy = again) deletes the entry The caller has to be informed, which option is true. Regards, Martin =20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Dienstag, 10. Juli 2007 23:09 > An: H=FClsemann, Martin > Cc: bliss@ietf.org; adam@nostrum.com;=20 > dean.willis@softarmor.com; audet@nortel.com;=20 > john.elwell@siemens.com; Alexeitsev, Denis;=20 > mhammer@cisco.com; jason@counterpath.com; shida@ntt-at.com > Betreff: Re: latest call-completion draft >=20 >=20 > [Removing sipping from the mailing list becasue cross posting=20 > is annoying.] >=20 > Thank you for producing this revised version! It goes a long=20 > way toward=20 > addressing the problems that have been raised before - at least those=20 > raised by me. I think the direction is quite reasonable now. I still=20 > have comments to make, but they are refinements. >=20 > General Issue: >=20 > IMO it isn't clear what resource the subscription is targeted=20 > to. From=20 > the text it seems that it is the *queue*. But that leads to problems=20 > about who is notified when. There is some implied=20 > relationship between=20 > subscribers and queue *entries* but that is not explained. >=20 > I think this would better modeled as subscription to queue *entries*.=20 > What is lacking is how the entry is referenced in the subscription=20 > request. I can see a couple of possibilities: >=20 > - the entry could be identified explicitly. E.g. there could=20 > be an event=20 > parameter containing the callid of the failing call that caused the=20 > queue entry to be made. >=20 > - it could be implicit - when the subscription request (to=20 > the AOR) is=20 > received and processed, an association to an entry could be made -=20 > perhaps by matching the From address of the subscriber with the From=20 > address of the caller. I have no strong opinion to this, except the fact that there is = explaining text missing, because the intention really is to subscribe to = a certain entry. To keep it simple, a correlation between the From headers of caller and = subscriber might be sufficient.=20 The other option you mentioned is not quite clear to me. It would have = to be a parameter transported somehow in the 486 or the 180. Is it = possible to use a special event parameters with the Allow-events header? >=20 > I think either way can be made to work. What is needed is=20 > some text that=20 > explains this. Part of this is probably to be more explicit=20 > in modeling=20 > the queue itself - what it contains, when things are added=20 > and removed,=20 > etc. (This would also provide a place to identify odd cases, such as=20 > when a particular caller makes multiple call attempts to the=20 > callee. In=20 > that case, are multiple entries made in the queue, or what?) >=20 > If the subscription is modeled as being to an *entry* then=20 > many things=20 > get simpler and clearer. For instance one class of errors=20 > occurs when no=20 > matching entry can be found. The triggering event for a=20 > notification is=20 > then very simple - it is when the state of the *entry* changes from=20 > "queued" to "ready-for-call-completion". Once a caller has subscribed to a certain entry and calls again, = different implementations in the service logic are possible: - the existing entry can be deleted, a new entry can be created and = Allow-events is again included in the response - the existing entry is not deleted, Allow-events is not included in the = response; the entry matures and is deleted after timer expiry. In my opinion the second possibility is the better one (this is also the = way it is mostly done in the PSTN, and this is how I woulk like to have = ot done), but I didn't want to prescribe the solution in the draft. If = people think it's better to have some normative text (for the second = possibility, timer expiry) in the draft, I can include that in the next = revision. >=20 > Another small issue: there is no mention of how long a=20 > subscriber has to=20 > make a call completion attempt after receiving a=20 > "ready-for-call-completion" notification. Presumably at some=20 > point there=20 > is a state change back to queued, or the entry is removed=20 > altogether. It=20 > would be good to tell the subscriber about this. Perhaps the=20 > "ready-for-call-completion" notification could carry the=20 > amount of time=20 > allotted for the attempt. This also should probably also be=20 > part of the=20 > model of the queue. There is a timer for this attempt, if there is no recall in this time = the state chages to queued again and the subscriber is informed. I think = we can do without the indication of the granted time for the = call-completion attempt, the subscribers will realize that this time is = limited after their state has changed back to 'queued' several times. = But if people would like this indication, it's noted for the next = revision. >=20 > The following are more localized comments about particular=20 > parts of the=20 > draft. >=20 >=20 > > 3.=20 > > Overview=20 > > =20 > > Completion of Calls on no Reply (CCNR) provides the cability to=20 > > queue not answered calls from several callers to a=20 > callee and to=20 > > inform the caller that he can initiate a=20 > call-completion call after=20 > > the callee has become not busy after having initiated=20 > an activity.=20 >=20 > The above is a pretty narrow definition. Isn't the *goal* to=20 > inform the=20 > caller when the callee is available? In some implementations=20 > "callee has=20 > become not busy after having initiated an activity" may be=20 > the best that=20 > can be done to determine availability. But should that be=20 > enshrined in=20 > the specification? Yes, 'become not busy after some activity' is the PSTN trigger. There = are of course other triggers. The text has to be modified. >=20 > For instance in some cases there may be other presence=20 > sources. E.g. if=20 > the callee device is a softphone on a PC then typing on the=20 > keyboard is=20 > also an indication of presence. >=20 > > 5.1=20 > > Proposed solution=20 >=20 > > ... A NOTIFY=20 > > request that reports that the callee is available for a call- > > completion call attempt to be made will cause the subscriber to=20 > > trigger the establishment of that call, subject to the=20 > caller being=20 > > available too.=20 >=20 > Its a stretch to say the notification will *cause* the subscriber to=20 > call. All it does is inform the caller that it *may* initiate a call=20 > with reasonable expectation of success. >=20 > How about: >=20 > "A NOTIFY request that reports the callee is available for a=20 > call-compleion call attempt to be made will inform the=20 > subscriber that=20 > it has an opportunity to attempt establishment of that call." Noted for the revision. >=20 > > ... It is=20 > > assumed that the call-completion service logic can distinguish=20 > > between a new subscription and a resuming subscription,=20 > when there=20 > > is an entry for the subscriber in the call completion queue.=20 >=20 > Why should it matter? Either somebody is interested in the entry, or=20 > nobody is. >=20 > If it really does matter (which I doubt) then the model of the queue,=20 > which I requested above, should explain what this extra state=20 > is and why=20 > it is important. I have received comments that asked for this correlation. I see also a = advantage for the interworking with the PSTN, where Suspend and Resume = are different messages. We can discuss if the reference to the optional = usage of etags is useful for the call-completion draft. I haven't really = a strong opinion. >=20 > > 6.7=20 > > Notifier Processing of SUBSCRIBE Requests=20 > > =20 > > Upon receiving a subscription refresh, the notifier=20 > MUST set the=20 > > "expires" parameter of the Subscription-State header to=20 > the current=20 > > remaining duration of the subscription regardless of the value=20 > > received in the Expires header (if present) of the subscription=20 > > refresh. =20 >=20 > This needs to be changed somewhat for compliance with 3265.=20 > The response=20 > to the subscription refresh must not return a value larger=20 > than in the=20 > request. >=20 > I gather you don't want the subscription to remain once the=20 > queue entry=20 > it is associated with ages out of the queue. You *could* define the=20 > maximum value based on that time. Or you could just terminate the=20 > subscription, sending a final NOTIFY with Terminated status, when it=20 > ages out. It is probably better to do that, because otherwise the=20 > subscriber may decide that it needs to refresh the subscription just=20 > before it is about to age out. Yes, this has to be changed.=20 It has to be avoided that there is a subsription when there is no queue = entry any longer. So what is really meant is that "Upon receiving a subscription refresh, the notifier MUST set the = "Expires" parameter of the Subscription-State header to the current = remaining duration of the subscription or to the value received in the = Expires header (if present) of the subscription refresh, if this value = is less then the remaining duration." So the maximum for the refresh would be the remaining duration, or a = value less then that if the user thinks that a call-completion = notification doesn't make sense for him longer. >=20 > > If a subscription is not successful because the call-completion=20 > > queue has reached the maximum number of entries (short term=20 > > denial), the notifier MUST send a 480 Temporarily Unavailable=20 > > response to the subscriber.=20 > > If a subscription is not successful because a general=20 > error that=20 > > prevents the call-completion service has occurred (long term=20 > > denial), the notifier MUST send a 403 Forbidden response to the=20 > > subscriber.=20 >=20 > I'm confused by this. As I understand it, the queue is=20 > populated as call=20 > attempts fail. I do understand that if the queue is full, it=20 > may be that=20 > another call attempt may fail to be queued. >=20 > But that has nothing to do with the subscription, which=20 > simply checks on=20 > the status of an entry in the queue. If an entry was not=20 > queued, due to=20 > the queue being full, then a subsequent subscription inquiring about=20 > that entry will be able to tell that there is no such entry,=20 > but won't=20 > be able to discern *why* the entry is absent. Nor will a subsequent=20 > subscription request somehow be able to get a different conclusion in=20 > this case. >=20 > Or are you limiting the number of subscribers to the event?=20 > Under normal=20 > circumstances one would expect that the number of=20 > subscriptions would be=20 > less than or equal to the number of entries in the queue. It would be=20 > unwise for an implementation to allow fewer subscriptions than that.=20 > There could be more, for valid or invalid reasons. A valid=20 > reason might=20 > be if the caller has multiple devices, using the same identity, that=20 > wish to track the same queue entry. An invalid reason would be when=20 > devices subscribe but have no entry in the queue. >=20 > The invalid case can be handled by 403 as you suggest, or by a 200=20 > response with a single NOTIFY that terminates the subscription and=20 > indicates no entry in the queue. >=20 > The valid case could be handled by 480 as you suggest. >=20 > Maybe this would all be clearer if you provide a sufficient=20 > model of the=20 > queue. The model of the queue is a limited number of queue entries which are = generated when a particular call fails. To this queue entries the = regarding callers can subscribe, so that in fact the number of = subscriptions is less than or equal to the number of entries in the = queue. However, regardless the fact that the caller was informed with = 'Allow-events' of the possibility to subscribe to the queue entry, there = might occur error conditions, which means the queue entry doesn't exist = anymore when the SUBSCRIBE is received. This especially occurs at the = interworking with the PSTN, where you are just informed about the = general availability of the call-completion service, but your activation = request can fail because the queue is already full. So for the = interworking of the PSTN 'short term denial' and 'long term denial' the = 403 and the 480 would be very helpful. But I think also in a pure SIP = environment, which this draft of course aims for, such errors can occur, = for the reasons you mentioned. >=20 > > 7.2=20 > > service-retention=20 > > =20 > > The service-retention indicates the support of the=20 > retain option. =20 > > The retain option, if supported at the callee, will=20 > maintain the=20 > > entry in the call-completion queue, if a=20 > call-completion call has=20 > > failed due to destination busy condition. If present, this=20 > > parameter indicates that the retain option is=20 > supported, otherwise=20 > > it is not supported. This parameter MAY be present in NOTIFY=20 > > requests.=20 >=20 > I'm confused about this "option". In what sense is it an option? I=20 > gather this is not an option requested by the subscriber or=20 > caller, but=20 > rather is an implementation choice on the part of the=20 > notifier. Is that=20 > right? So from the point of view of the subscriber this=20 > simply says what=20 > to expect after it tries and fails to make a call-completion call??? >=20 > IMO this deserves more complete explanation, even if I got it=20 > right. It=20 > sounds like there might be two different models for queue=20 > management. If=20 > so, when modeling the queue you should show both models and=20 > specify that=20 > a node may choose (or be configured) to support one or the other. The option here is wether a queue entry is deleted when call-completion = is just attempted or when call-completion is attempted successfully. = Also a call for call-completion can end in busy, if there was another = call to the callee after the NOTIFY 'ready-for-call-completion' was = sent.=20 In the case the entry is deleted at every attempt, successful or not, = and the callee is busy again, the normal procedure would be that the = subscription would have to be terminated when the entry is deleted by = sending the final NOTIFY, and more or less at the same time a new = Allow-events would have to be sent. The usage of the service-retention parameter avoids these complicated = procedures and informs the user before the call-completion attempt if = his queue entry remains or not in case of a not successful attempt.=20 And, you guess it, this parameter is also needed for the PSTN = interworking, where the user is also informed before the call-completion = attempt, if his call-completion request remains activated in case of a = failure. So when the call fails, there is no new 'CCBS possible' = indication which could be mapped into a new = 'Allow-events:call-completion'. >=20 > > 8.=20 > > Signaling Flows=20 >=20 > All the NOTIFYs have the To/From URIs interchanged. (The=20 > To/From of the=20 > NOTIFY should be reversed from that in the SUBSCRIBE.) Yes, thanks, noted for the revision. >=20 > > 9.=20 > > Security Considerations=20 >=20 > Given the intended usage, I think it might be better to give more=20 > guidance. In particular I suggest that in the absence of some=20 > explicit=20 > policy to the contrary, subscriptions SHOULD only be allowed from the=20 > same identity that made the original call attempt. Okay. Other comments/suggestions? >=20 > Thanks, > Paul >=20 > Huelsemann, Martin wrote: > >=20 > >=20 > > Hi all, > >=20 > > the latest call-completion draft has been uploaded, as agreed=20 > > call-completion was shifted to BLISS, so you can find the=20 > result under=20 > >=20 > _http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-c > ompletion-00.txt_. > >=20 > > The main issue of the discussion on the mailing list was=20 > the usage of=20 > > SUBSCRIBE bodies for queue manipulation actions (e.g. add, suspend,=20 > > resume), which is not in accordance with RFC 3265. > >=20 > > The solution discussed was the scenario, where not answered calls=20 > > (because of busy or no reply) are getting queued at the=20 > callee, and the=20 > > caller is informed that he can receive call-completion information,=20 > > which would inform him that he is either still queued, or=20 > that he can=20 > > start the recall. > >=20 > > So what is described now is a proposal for a pure=20 > call-completion event=20 > > package with the values 'queued' and=20 > 'ready-for-call-completion' (and an=20 > > additional value for service retention), so no more queue=20 > manipulation=20 > > parameters in the SUBSCRIBE body, and the proposed usage of the=20 > > Allow-events in 180 and 486. > >=20 > > Suspending and resuming would be done by un-subscribing and=20 > subscribing=20 > > again to the call-completion event package. > >=20 > >=20 > > Comments and questions are welcome. > >=20 > >=20 > >=20 > > Regards, Martin > >=20 > >=20 > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 17 16:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtG9-0007e2-MK; Tue, 17 Jul 2007 16:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtG7-0007dl-1H for bliss@ietf.org; Tue, 17 Jul 2007 16:02:59 -0400 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAtG5-0005uy-SQ for bliss@ietf.org; Tue, 17 Jul 2007 16:02:58 -0400 Received: by an-out-0708.google.com with SMTP id c17so347359anc for ; Tue, 17 Jul 2007 13:02:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=s8Vgtp5xd6kYmeNfgYxNQCSyABOXnjK7RIcPBm6U30wyJoyXeFNGDZNnznTLUonxXxry/Bm2U+B1JUjIZFJhMFzXELDrvPF6BpA+jVO0LrURAgaCemwQCNfh6q7F9apWwvNape4fM9n22KhcoT8SBzB1WvzSMBQrUwkbaZ7AW6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=aNiDQQZyd1jnrSXhN89gGefCtY9RYRPy/Qnb/dvighcM/9Ndb+oQwaghVjAr4/AP68Mlz0mSwwtRL2lD9cmx0du+E374XC0E/Uoee/2u/CPQTgAKBM6y2XxbHbbFY5TghleGEp34rsJywJusC13uaGwpzITxPbacV27foJlA18c= Received: by 10.100.37.4 with SMTP id k4mr445778ank.1184702576439; Tue, 17 Jul 2007 13:02:56 -0700 (PDT) Received: by 10.100.190.17 with HTTP; Tue, 17 Jul 2007 13:02:56 -0700 (PDT) Message-ID: <458913680707171302n57943755p801b913950473a19@mail.gmail.com> Date: Tue, 17 Jul 2007 22:02:56 +0200 From: "Xavier Marjou" To: bliss@ietf.org, "Alan Johnston" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: bf4d6e59a12e30a3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [BLISS] Comments on draft-johnston-bliss-mla-req-00.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi, With regards to usage scenario 1, the executive probably wants to keep its own "line" private in order that the caller does not learn a way to join him directly. I understand this is covered by REQ-13. However in Section 5, it seems to me that privacy is not entirely covered. For example, if an INVITE from a caller finally arrives at the executive UA, the Contact of 200 returned by the executive UA to the caller would indicate a way to directy reach his "line". Concerning the "Implementation Options" section, I'd suggest to indicate an authentication step during the registration (step 3) so that any UA (i.e. a UA external to the group) can not join the group. Cheers, Xavier _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 17 18:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAvAg-0001Zl-Tm; Tue, 17 Jul 2007 18:05:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAvAf-0001Zg-Lw for bliss@ietf.org; Tue, 17 Jul 2007 18:05:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAvAe-0000lh-6l for bliss@ietf.org; Tue, 17 Jul 2007 18:05:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2007 15:05:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAGLanEarR7O6/2dsb2JhbACIWp1I X-IronPort-AV: i="4.16,547,1175497200"; d="scan'208"; a="183801082:sNHT27498834" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6HM5R8h002942; Tue, 17 Jul 2007 15:05:27 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6HM5QSb006473; Tue, 17 Jul 2007 22:05:27 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 18:05:26 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 18:05:26 -0400 Message-ID: <469D3D24.4010509@cisco.com> Date: Tue, 17 Jul 2007 18:05:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [BLISS] Comments on draft-johnston-bliss-mla-req-00.txt References: <458913680707171302n57943755p801b913950473a19@mail.gmail.com> In-Reply-To: <458913680707171302n57943755p801b913950473a19@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 22:05:26.0355 (UTC) FILETIME=[94778230:01C7C8BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1240; t=1184709927; x=1185573927; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Comments=20on=20draft-johnston-bliss-mla-re q-00.txt |Sender:=20; bh=yWGZafMDbkZOazvC0ZDv7F+ege19XVdBw/ZBNnopyFk=; b=mI6stDrJF0vgjUY+/SV8SLulIaeKY8La87QcLZI/hEoeuZ8t96QGa/UAJCwny6CcTCrr/Yl0 Oe9kYSYh/1L1A5qDknpMxx60qDzS1H/FwawuQuD/EOnUG6qVeWPDPwKZ; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Xavier Marjou wrote: > Hi, > > With regards to usage scenario 1, the executive probably wants to keep > its own "line" private in order that the caller does not learn a way > to join him directly. I understand this is covered by REQ-13. However > in Section 5, it seems to me that privacy is not entirely covered. For > example, if an INVITE from a caller finally arrives at the executive > UA, the Contact of 200 returned by the executive UA to the caller > would indicate a way to directy reach his "line". Interesting problem. The contact probably does need to address him directly for some features to work (e.g. another transfer). A temporary GRUU would do the job here. With that, the caller could in principle call him back directly using that URI until/unless the executive forces temp gruus to be invalidated. Paul > Concerning the "Implementation Options" section, I'd suggest to > indicate an authentication step during the registration (step 3) so > that any UA (i.e. a UA external to the group) can not join the group. > > Cheers, > Xavier > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jul 18 13:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDE5-000202-Cl; Wed, 18 Jul 2007 13:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDE4-0001zw-1R for bliss@ietf.org; Wed, 18 Jul 2007 13:22:12 -0400 Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBDE2-0007jO-GN for bliss@ietf.org; Wed, 18 Jul 2007 13:22:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 11:22:08 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BLISS problem statement draft Thread-Index: AcfJYCt/IPPlp69rRRqzMgl+rUWq1w== From: "Peter Musgrave" To: , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: Subject: [BLISS] BLISS problem statement draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2098308992==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============2098308992== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C960.2C151437" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C960.2C151437 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan,=20 =20 In the motivation section you have: In some cases, these interoperability failures are the fault of poor implementations. In other cases, they are purposeful failures, meant to ensure that third party equipment is not utilized in a vendor's solution. =20 =20 I think there is another major reason we are in "the confusion of tongues" (nice turn of phrase BTW). It is simply that an implementing company is typically developing a server or a specific UA and is trying to provide some feature to the customer. The only thing under their direct control is the part of the 'distributed state-machine' that resides within their product. To release a feature in a timely way the implementation will be tilted in favor of an implementation on that product which makes only very basic assumptions about the other elements in the 'distributed state machine'.=20 =20 In this case I don't see it as poor implementations or deliberate failures - it simply stems from a desire to get stuff out the door - and I think it will keep happening over and over again. =20 While I really want BLISS to succeed (since it's almost kinda funny that after 20 SIPits things like park/pickup are still fair game for discussion), I think the ambition expressed in your problem statement is *very* difficult. Mandating a specific implementation (modulo some details) may be ultimately more successful. =20 =20 Are you aware of any 'existence proofs' of efforts where a specification has constrained behavior without detailing implementation and led to successful interop? =20 I think the "Phase II" - Submit feature flows - is of substantial benefit in its own right. There are many cases where I have developed a flow for something only to find a much better one after its "too late" - and a "Field Guide" to flows for common features *especially* with why some flows crash-and-burn in some cases would be very useful - even if we still end up with a confusion of tongues some of the more tortuous dialects may be avoided. =20 =20 =20 Regards,=20 =20 Peter Musgrave ------_=_NextPart_001_01C7C960.2C151437 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

 

In the motivation section you = have:

   In some cases, these =
interoperability failures are the fault of =
poor
   implementations.  In other =
cases, they are purposeful failures, =
meant
   to ensure that third party =
equipment is not utilized in a =
vendor's
   solution.  =

 

I think there is another major reason we are in = “the confusion of tongues” (nice turn of phrase BTW). It is simply that = an implementing company is typically developing a server or a specific UA = and is trying to provide some feature to the customer. The only thing under = their direct control is the part of the ‘distributed state-machine’ that = resides within their product. To release a feature in a timely way the = implementation will be tilted in favor of an implementation on that product which makes = only very basic assumptions about the other elements in the = ‘distributed state machine’.

 

In this case I don’t see it as poor = implementations or deliberate failures – it simply stems from a desire to get stuff = out the door – and I think it will keep happening over and over = again.

 

While I really want BLISS to succeed (since = it’s almost kinda funny that after 20 SIPits things like park/pickup are = still fair game for discussion), I think the ambition expressed in your problem = statement is *very* difficult. = Mandating a specific implementation (modulo some details) may be ultimately more = successful.  

 

Are you aware of any ‘existence proofs’ = of efforts where a specification has constrained behavior without detailing implementation and led to successful = interop?

 

I think the “Phase II” – Submit = feature flows – is of substantial benefit in its own right. There are many = cases where I have developed a flow for something only to find a much better = one after its “too late” – and a “Field Guide” = to flows for common features *especially* with why some flows crash-and-burn in some cases would be very useful = – even if we still end up with a confusion of tongues some of the more = tortuous dialects may be avoided.

 

 

 

Regards,

 

Peter = Musgrave

------_=_NextPart_001_01C7C960.2C151437-- --===============2098308992== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============2098308992==-- From bliss-bounces@ietf.org Wed Jul 18 19:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIVv-0004lH-OG; Wed, 18 Jul 2007 19:00:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIVs-0004l0-5b for bliss@ietf.org; Wed, 18 Jul 2007 19:00:57 -0400 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBIVr-0002OS-NW for bliss@ietf.org; Wed, 18 Jul 2007 19:00:56 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6IN0ffR011795; Wed, 18 Jul 2007 17:00:42 -0600 Message-ID: <469E9B94.9080100@ntt-at.com> Date: Wed, 18 Jul 2007 16:00:36 -0700 From: Shida Schubert User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371155981A6@zrc2hxm2.corp.nortel.com> <468CF7A5.8080605@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371156F627F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371156F627F@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian; My personal comment on the remark you made here.. Sorry for budding in so late. >> ..it seems like it could be endless >> >>> without a clear constraint. >>> >> I think our scope covers whatever it needs to cover in order >> to achieve interoperability. >> > > Mmm... Really? That seems extremely ambitious. How does BLISS then > differ from SPEERMINT? > I have to agree with Jonathan here, but would be careful with how much BLISS would take on. After the analysis of the problem and coming up with a potential solution to resolve the interop problems, if we decide that a way to communicate configuration means between components is intrinsic, then I see no reason why we couldn't address the issue within the group, of course if new SIP extension, extension to RPID etc. is needed then the task should be delegated to an appropriate WG such as SIP and SIMPLE. Further, if we see way to improve the interop problems to some level but see that sorting out the configuration means through negotiation for example would improve the interop problems even more, I see no reason why we can't produce multiple documents to relieve some of the headaches and later try to relieve more with whatever is considered desirable. Similar to error correction approach taken in SIP WG for example may be acceptable here as well, not desirable definitely, but if it looks like we can save 70% of the problems with the first approach and 95% if we pursue with the more complicated approach that may take year or more then, I feel that we should release whatever we need to save the 70% and later release the latter. Regards Shida _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jul 18 19:31:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIzR-0002aA-KE; Wed, 18 Jul 2007 19:31:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIzP-0002a5-FR for bliss@ietf.org; Wed, 18 Jul 2007 19:31:27 -0400 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBIzO-0002y4-Uc for bliss@ietf.org; Wed, 18 Jul 2007 19:31:27 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6INVKsm024140; Wed, 18 Jul 2007 17:31:21 -0600 Message-ID: <469EA2C3.60400@ntt-at.com> Date: Wed, 18 Jul 2007 16:31:16 -0700 From: Shida Schubert User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> In-Reply-To: <4693DAFB.8010900@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Paul, Brian; My personal view on this is that BLISS will provide a basic level of interoperability through recommending primitives to implement and recommending behavior to be implemented by the components. We are really trying to recommend a flavor of an implementation for the target functional primitive which may be analogous to best-possible implementation for interoperability. It may seem too restrictive by recommending a particular implementation, but let's not forget for a moment, that we are focusing on functional primitives and not a whole feature here. I view functional primitive to be a mere fraction of a whole feature that uses the functional primitive, but at the same time the major source of the problems. Being stringent with how functional primitive are implemented SHOULD NOT forbid vendors to come up with variations in providing the feature that utilizes the primitive function as long as it's not the whole feature that BLISS is defining. Further, some of the pre-existing implementations that has interoperability problems may be saved by the recommendation but between the pre-existing implementations that has problems, the problem will persists and some of the variants may not be saved by the recommendation if saving that variant means 90% of the overall effort needed to solve the overall problem. I believe what we are doing here is simply trying to make the future better by recommending a way to implement a portion of the feature that's causing the problem and save whatever we can save while we are at it. Regards Shida Paul Kyzivat wrote: > > > Brian Stucker wrote: > >> >> My point was the question you didn't answer (just below): Are we looking >> for best-possible implementation or basic level of interoperability? >> These are two very different things. > > I think for bliss we should be satisfied with a basic level of > interoperability. In the case at hand I am satisfied that each end can > go on and off hold as it desires, and that media flows (or doesn't > flow) as desired. When I initiate "hold" I don't have any particular > expectation that the other end is told explicitly that it has been put > on hold. So the lack of an explicit "hold" indication on the far end > doesn't bother me. > > However, in this particular case, it is indeed good for the far end to > indicate that that it isn't permitted to transmit media. That is > equally useful regardless of the reason. I don't require it, but it is > a plus. > > Thanks, > Paul > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jul 18 21:31:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKry-0004xh-Qg; Wed, 18 Jul 2007 21:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKrt-0004tL-JP for bliss@ietf.org; Wed, 18 Jul 2007 21:31:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBKrs-0005bM-R4 for bliss@ietf.org; Wed, 18 Jul 2007 21:31:49 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jul 2007 21:31:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAMJankZAZnme/2dsb2JhbACIXp5a X-IronPort-AV: i="4.16,553,1175486400"; d="scan'208"; a="65561758:sNHT55715152" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6J1VmQn005728; Wed, 18 Jul 2007 21:31:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6J1VdWI014351; Thu, 19 Jul 2007 01:31:44 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); Wed, 18 Jul 2007 21:31:39 -0400 Received: from [10.86.242.187] ([10.86.242.187]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 21:31:39 -0400 Message-ID: <469EBEF9.6050207@cisco.com> Date: Wed, 18 Jul 2007 21:31:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> In-Reply-To: <469EA2C3.60400@ntt-at.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 01:31:39.0378 (UTC) FILETIME=[8DC6BD20:01C7C9A4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4743; t=1184808708; x=1185672708; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20shida@ntt-at.com; bh=uzef6fhphbGBpiX7r3xeJ1whL5p3bTD6preFrpAfd1g=; b=HneKPilOb/TvTeP53Hqv+eQ+CT/Z2QQAiJ/NlWwRqVHCWcjRwFW716uUrxVonH2P4uiCO24f gfS1xBNnfUEgJCojkuhbNYpfYRGLoU1KFKqM55zHs27HB6lbm1zfSWxq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I agree with you. Also, in most cases there is one participant in a feature that is the initiator. That participant knows what feature is being invoked. If there are multiple ways to do the feature, that participant has freedom in which way to do it. It may be constrained to some extent by what functionality the peer had advertised support for. But the support it depends on is not for features, but rather only for various primitives. The other participant(s) are more in the way bystanders. They don't know what feature they are being asked to participate in. Rather, they get some stimulus - typically a request in the context of some state the node has, and then must react to that by doing something. What's important is that the non-initiating participants do what is necessary to allow the completion of the service kicked off by the initiator, even if they would never have initiated the service the same way if they were the initiator. Of course is isn't really that simple. The non-initiating participants may still have some discretion in initiating the next step in a complex sequence. So I think the key things we need to do are: - ensure that different features don't result in an identical stimulus to some participant while requiring that participant to take a different action for each feature. (Since it doesn't know what feature it is doing.) - Get agreement on what the set of stimulus:action pairs need to be supported to allow any of the interesting feature implementations to be kicked off by an initiator. The hope and expectation (at least by me) is that the number of stimulus:action pairs that must be supported is much less than the number of feature implementations, because the same stimulus:action pair is used by many features. Thanks, Paul Shida Schubert wrote: > > Hi Paul, Brian; > > My personal view on this is that BLISS will provide a basic level > of interoperability through recommending primitives to implement > and recommending behavior to be implemented by the components. > > We are really trying to recommend a flavor of an implementation > for the target functional primitive which may be analogous to > best-possible implementation for interoperability. > > It may seem too restrictive by recommending a particular implementation, > but let's not forget for a moment, that we are focusing on functional > primitives > and not a whole feature here. I view functional primitive to be a mere > fraction > of a whole feature that uses the functional primitive, but at the same > time the > major source of the problems. > > Being stringent with how functional primitive are implemented SHOULD > NOT forbid vendors to come up with variations in providing the feature > that utilizes the primitive function as long as it's not the whole > feature that > BLISS is defining. > > Further, some of the pre-existing implementations that has interoperability > problems may be saved by the recommendation but between the pre-existing > implementations that has problems, the problem will persists and some of > the > variants may not be saved by the recommendation if saving that variant > means > 90% of the overall effort needed to solve the overall problem. > > I believe what we are doing here is simply trying to make the future > better by recommending a way to implement a portion of the feature > that's causing > the problem and save whatever we can save while we are at it. > > Regards > Shida > > Paul Kyzivat wrote: >> >> >> Brian Stucker wrote: >> >>> >>> My point was the question you didn't answer (just below): Are we looking >>> for best-possible implementation or basic level of interoperability? >>> These are two very different things. >> >> I think for bliss we should be satisfied with a basic level of >> interoperability. In the case at hand I am satisfied that each end can >> go on and off hold as it desires, and that media flows (or doesn't >> flow) as desired. When I initiate "hold" I don't have any particular >> expectation that the other end is told explicitly that it has been put >> on hold. So the lack of an explicit "hold" indication on the far end >> doesn't bother me. >> >> However, in this particular case, it is indeed good for the far end to >> indicate that that it isn't permitted to transmit media. That is >> equally useful regardless of the reason. I don't require it, but it is >> a plus. >> >> Thanks, >> Paul >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jul 19 22:40:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBiPq-0007qf-BX; Thu, 19 Jul 2007 22:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBiPp-0007p4-68 for bliss@ietf.org; Thu, 19 Jul 2007 22:40:25 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBiPo-0002K5-P8 for bliss@ietf.org; Thu, 19 Jul 2007 22:40:25 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070720024023b1400s7hcge>; Fri, 20 Jul 2007 02:40:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6K2eN8t015635 for ; Thu, 19 Jul 2007 22:40:23 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6K2eM3b015631; Thu, 19 Jul 2007 22:40:22 -0400 Date: Thu, 19 Jul 2007 22:40:22 -0400 Message-Id: <200707200240.l6K2eM3b015631@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Martin.Huelsemann@t-com.net) Subject: Re: [BLISS] latest call-completion draft References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Huelsemann, Martin" the latest call-completion draft has been uploaded, as agreed call-completion was shifted to BLISS, so you can find the result under http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00.txt. As a big nit, the text seems to have been put through something that has altered the formatting a great deal. Technically, I think it would help to clean up the Requirements section. As written, it mixes details of the mechanism (e.g., "In this case the state of the caller changes from 'queued' to 'ready-for-call-completion' and the caller will be informed accordingly.") with the actions it is to support. A careful enumeration of the high-level operations would be quite helpful. Also, I don't see a discussion of how the "queue manipulation operations" are performed. Maybe those are implicit. But I get the feeling that the author understands how CCBS works so intuitively that he is not spelling out the algorithms and interactions in the necessary detail. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jul 20 05:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoTl-0003OK-Ey; Fri, 20 Jul 2007 05:08:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoTk-0003OB-Ty for bliss@ietf.org; Fri, 20 Jul 2007 05:08:52 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBoTk-00052L-8t for bliss@ietf.org; Fri, 20 Jul 2007 05:08:52 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Fri, 20 Jul 2007 11:08:02 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 11:08:00 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: WG: [BLISS] latest call-completion draft Date: Fri, 20 Jul 2007 11:07:58 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] latest call-completion draft Thread-Index: AcfKd1Zqgu5HCZ8oR0qQ7BaNlYAK/wAMN4gQAAE/QUA= From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 20 Jul 2007 09:08:00.0434 (UTC) FILETIME=[78921120:01C7CAAD] X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yes, I agree that the queue model has to be described more exactly, so = text for the high-level operations is missing. In the next revision I = will try to consider this in a better way. Very shortly, there are no queue manipulation operations anymore, they = are implicit. So there are no explicit queue manipulation operations = like adding or removing oneself to or from the queue like in the PSTN. A queue entry is created when a call ends in busy, and the caller can = subscribe to the state of this queue entry.=20 A queue entry is deleted when it matures after timer expiry, or when the = caller starts a call-completion attempt after having received the = regarding call-completion notification. This means a 'deactivation' of call-completion like in the PSTN is not = possible, you subscribe to call-completion if you are interested in this = information, and you unsubscribe if you are no longer interested.=20 An explicit deactivation request from the PSTN could also be interworked = in a un-SUBSCRIBE. So in principle it is very simple now, the only thing I have to do is to = explain this in the draft in a understandable manner. Regards, Martin =20 >> -----Urspr=FCngliche Nachricht----- >> Von: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 >> Gesendet: Freitag, 20. Juli 2007 04:40 >> An: bliss@ietf.org >> Betreff: Re: [BLISS] latest call-completion draft >>=20 >>=20 >>=20 >> From: "Huelsemann, Martin" >>=20 >> the latest call-completion draft has been uploaded, as agreed >> call-completion was shifted to BLISS, so you can find the result >> under >> =20 >> = http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00= .txt. > >As a big nit, the text seems to have been put through something that >has altered the formatting a great deal. > >Technically, I think it would help to clean up the Requirements >section. As written, it mixes details of the mechanism (e.g., "In >this case the state of the caller changes from 'queued' to >'ready-for-call-completion' and the caller will be informed >accordingly.") with the actions it is to support. A careful >enumeration of the high-level operations would be quite helpful. > >Also, I don't see a discussion of how the "queue manipulation >operations" are performed. Maybe those are implicit. But I get the >feeling that the author understands how CCBS works so intuitively that >he is not spelling out the algorithms and interactions in the >necessary detail. > >Dale > >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jul 20 06:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBq9a-0007sl-5d; Fri, 20 Jul 2007 06:56:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBq9Z-0007sb-IJ for bliss@ietf.org; Fri, 20 Jul 2007 06:56:09 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBq9Z-0007Zb-9H for bliss@ietf.org; Fri, 20 Jul 2007 06:56:09 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007072010560801300796gue>; Fri, 20 Jul 2007 10:56:08 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6KAu88t019789 for ; Fri, 20 Jul 2007 06:56:08 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6KAu8mx019785; Fri, 20 Jul 2007 06:56:08 -0400 Date: Fri, 20 Jul 2007 06:56:08 -0400 Message-Id: <200707201056.l6KAu8mx019785@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Martin.Huelsemann@t-com.net) Subject: Re: WG: [BLISS] latest call-completion draft References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Huelsemann, Martin" A queue entry is created when a call ends in busy, and the caller can subscribe to the state of this queue entry. A queue entry is deleted when it matures after timer expiry, or when the caller starts a call-completion attempt after having received the regarding call-completion notification. I'd like to see more detail on how the call-completion arbitration operatoin works. How do the calling UA and the call-completion arbiter interact to get the right things to happen in all cases? Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sat Jul 21 14:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK2j-0004Nf-H6; Sat, 21 Jul 2007 14:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK2i-0004Na-Aw for bliss@ietf.org; Sat, 21 Jul 2007 14:51:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICK2h-0000sc-F6 for bliss@ietf.org; Sat, 21 Jul 2007 14:51:04 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B09C20582; Sat, 21 Jul 2007 20:51:02 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-12-46a2559678cd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D29720550; Sat, 21 Jul 2007 20:51:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 20:51:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Sat, 21 Jul 2007 20:50:59 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C922@esealmw113.eemea.ericsson.se> In-Reply-To: <469EBEF9.6050207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfJpJn9vpO2ThujRkmNjKeOANjMAgB6g3PQ References: <46897CB3.9050609@cisco.com><4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com><4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 21 Jul 2007 18:51:01.0839 (UTC) FILETIME=[15869DF0:01C7CBC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi,=20 >I agree with you. >=20 >Also, in most cases there is one participant in a feature=20 >that is the initiator. That participant knows what feature is=20 >being invoked. If there are multiple ways to do the feature,=20 >that participant has freedom in which way to do it. It may be=20 >constrained to some extent by what functionality the peer had=20 >advertised support for. But the support it depends on is not=20 >for features, but rather only for various primitives. >=20 >The other participant(s) are more in the way bystanders. They=20 >don't know what feature they are being asked to participate=20 >in. Rather, they get some stimulus - typically a request in=20 >the context of some state the node has, and then must react=20 >to that by doing something. >=20 >What's important is that the non-initiating participants do=20 >what is necessary to allow the completion of the service=20 >kicked off by the initiator, even if they would never have=20 >initiated the service the same way if they were the initiator. Beavis, you just said "service"... huh huh huh ;) >Of course is isn't really that simple. The non-initiating=20 >participants may still have some discretion in initiating the=20 >next step in a complex sequence. > >=20 >So I think the key things we need to do are: > - ensure that different features don't result in an identical > stimulus to some participant while requiring that participant > to take a different action for each feature. (Since it doesn't > know what feature it is doing.) >=20 >- Get agreement on what the set of stimulus:action pairs need to > be supported to allow any of the interesting feature implementations > to be kicked off by an initiator. >=20 >The hope and expectation (at least by me) is that the number=20 >of stimulus:action pairs that must be supported is much less=20 >than the number of feature implementations, because the same=20 >stimulus:action pair is used by many features. This sounds a little like the work on "common procedures" that TISPAN has been working on, which defines common building blocks/sub-functions that services can refer to. Regards, Christer =20 > Thanks, > Paul >=20 > Shida Schubert wrote: > >=20 > > Hi Paul, Brian; > >=20 > > My personal view on this is that BLISS will provide a basic=20 > level of=20 > > interoperability through recommending primitives to implement and=20 > > recommending behavior to be implemented by the components. > >=20 > > We are really trying to recommend a flavor of an implementation for=20 > > the target functional primitive which may be analogous to=20 > > best-possible implementation for interoperability. > >=20 > > It may seem too restrictive by recommending a particular=20 > > implementation, but let's not forget for a moment, that we are=20 > > focusing on functional primitives and not a whole feature=20 > here. I view=20 > > functional primitive to be a mere fraction of a whole feature that=20 > > uses the functional primitive, but at the same time the=20 > major source=20 > > of the problems. > >=20 > > Being stringent with how functional primitive are=20 > implemented SHOULD=20 > > NOT forbid vendors to come up with variations in providing=20 > the feature=20 > > that utilizes the primitive function as long as it's not the whole=20 > > feature that BLISS is defining. > >=20 > > Further, some of the pre-existing implementations that has=20 > > interoperability problems may be saved by the recommendation but=20 > > between the pre-existing implementations that has problems, the=20 > > problem will persists and some of the variants may not be=20 > saved by the=20 > > recommendation if saving that variant means 90% of the=20 > overall effort=20 > > needed to solve the overall problem. > >=20 > > I believe what we are doing here is simply trying to make=20 > the future=20 > > better by recommending a way to implement a portion of the feature=20 > > that's causing the problem and save whatever we can save=20 > while we are=20 > > at it. > >=20 > > Regards > > Shida > >=20 > > Paul Kyzivat wrote: > >> > >> > >> Brian Stucker wrote: > >> > >>> > >>> My point was the question you didn't answer (just below): Are we=20 > >>> looking for best-possible implementation or basic level=20 > of interoperability? > >>> These are two very different things. > >> > >> I think for bliss we should be satisfied with a basic level of=20 > >> interoperability. In the case at hand I am satisfied that each end=20 > >> can go on and off hold as it desires, and that media flows (or=20 > >> doesn't > >> flow) as desired. When I initiate "hold" I don't have any=20 > particular=20 > >> expectation that the other end is told explicitly that it has been=20 > >> put on hold. So the lack of an explicit "hold" indication=20 > on the far=20 > >> end doesn't bother me. > >> > >> However, in this particular case, it is indeed good for=20 > the far end=20 > >> to indicate that that it isn't permitted to transmit=20 > media. That is=20 > >> equally useful regardless of the reason. I don't require=20 > it, but it=20 > >> is a plus. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >> > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 17:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5Mk-0003dL-3y; Mon, 23 Jul 2007 17:22:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5Mi-0003dD-KJ for bliss@ietf.org; Mon, 23 Jul 2007 17:22:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID5Mi-0002qk-3O for bliss@ietf.org; Mon, 23 Jul 2007 17:22:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 17:22:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABO5pEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126811809:sNHT28911540" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NLMpUl002394; Mon, 23 Jul 2007 17:22:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NLMkWQ021967; Mon, 23 Jul 2007 21:22:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:22:19 -0400 Received: from [10.86.243.142] ([10.86.243.142]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:22:18 -0400 Message-ID: <46A51C12.5050703@cisco.com> Date: Mon, 23 Jul 2007 17:22:26 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> In-Reply-To: <469EBEF9.6050207@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 21:22:18.0687 (UTC) FILETIME=[8C9334F0:01C7CD6F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2777; t=1185225771; x=1186089771; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=hXwaHQoU0Oh4ipbECX4H/lwrsAMXGTcrd+o/aa3mXKQ=; b=ImRkSU1CtWBG0z4MshID+Ip83WzBHs6WadPgta3OH3ew/cvzxezd85YurDeVUHDOLiIdp1dk faZdZb2eQAxRM1vvyJi436t9+9v6qFB7v6NS3HlhWxeyEACzv/fE2PaE; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org inline. Paul Kyzivat wrote: > I agree with you. > > Also, in most cases there is one participant in a feature that is the > initiator. That participant knows what feature is being invoked. If > there are multiple ways to do the feature, that participant has freedom > in which way to do it. It may be constrained to some extent by what > functionality the peer had advertised support for. But the support it > depends on is not for features, but rather only for various primitives. I think we need to be VERY careful here. In all cases, we are expecting *something* to be present, in terms of functionality, from the non-intiators, even in single-ended features. At a minimum, we are expecting RFC 3261. In many cases, we may be expected support for something like REFER. If a UA doesn't support receipt of REFER, then the feature doesn't work even if you think its single ended. As such, even for single ended features, we will need to state minimum requirements (i.e., implement REFER) for that feature group. > > The other participant(s) are more in the way bystanders. They don't know > what feature they are being asked to participate in. Rather, they get > some stimulus - typically a request in the context of some state the > node has, and then must react to that by doing something. > > What's important is that the non-initiating participants do what is > necessary to allow the completion of the service kicked off by the > initiator, even if they would never have initiated the service the same > way if they were the initiator. Right. > > Of course is isn't really that simple. The non-initiating participants > may still have some discretion in initiating the next step in a complex > sequence. If the feature requires the non-initiating participants to do something that is specific to this feature, it is by definition, not single-ended. > > So I think the key things we need to do are: > - ensure that different features don't result in an identical > stimulus to some participant while requiring that participant > to take a different action for each feature. (Since it doesn't > know what feature it is doing.) Right. We need to look very carefully about what expectations we have for non-participants. Even for something like receipt of REFER, you need to make sure that the UA has what it needs to authorize the request. -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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 17:28:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5SP-0008KZ-BF; Mon, 23 Jul 2007 17:28:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5SO-0008KU-LC for bliss@ietf.org; Mon, 23 Jul 2007 17:28:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID5SO-0002y9-30 for bliss@ietf.org; Mon, 23 Jul 2007 17:28:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 17:28:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD+6pEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126812284:sNHT33883154" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NLShhs019136; Mon, 23 Jul 2007 17:28:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NLSQWm023851; Mon, 23 Jul 2007 21:28:43 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); Mon, 23 Jul 2007 17:28:41 -0400 Received: from [10.86.243.142] ([10.86.243.142]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:28:41 -0400 Message-ID: <46A51D90.6040708@cisco.com> Date: Mon, 23 Jul 2007 17:28:48 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 21:28:41.0195 (UTC) FILETIME=[70914BB0:01C7CD70] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3320; t=1185226123; x=1186090123; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=dRBNQkz/UY+Q/5GAE6ibxsqsXW3qwaADbgklWpKoaRc=; b=e8fNTnEIzA/VwpnFyuKgyGIIaJbhagmkJ90e0aYemx+P54tY8nEjWUTgo34wvxFg37nf/Lpg lOBS6xBBZTSKfavfco4XVcONeK11rPCFIhlY7SQlSmE86ZQMjjJW2LgN; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org inline. Elwell, John wrote: > Jonathan, > > I like the methodology proposed. Thanks. > > One point of detail concerning the particular example given: > > "In the case of CFNA, clearly a functional > primitive of "call forwarding features that execute on no-answer" is > too narrow. A functional primitive of "features that handle an > initial INVITE" is too broad. An ideal starting point would probably > be, "features that result in a retargeting or response operation that > depend on user-specified criteria". This covers all of the call > forwarding variations, but also includes features like Do-Not- > Disturb." > > I agree that one action that can be taken on DND is to forward (e.g., to > voicemail, to an assistant). However, the bliss-dnd draft covers more > than this, in particular what to indicate to the caller, how to clearly > indicate DND to the proxy if the proxy is responsible for forwarding, > and what to indicate in presence. Well, I'd argue that all of these apply to CFNA also. It is desirable to indicate to the caller that their call is being forwarded. Obviously we'd need to indicate to the proxy how to do forwarding if its desired. Even presence. For example, if CFNA is enabled, you might include a element in the presence document. > These aspects are somewhat different > from the call forwarding set of problems. I prefer to regard it as an > interaction between two groups of features (or two functional > primitives) - the DND group and the forwarding group. I'm not sure I agree. In fact the > problem of interactions will come up a lot, for example impact of call > forwarding on shared line appearance. We have to draw lines between > groups of features somewhere and accept that there will be interactions > between groups and find out ways to handle these interactions (in a way > that does not constrain implementations but does not lead to > unpredictable or undesirable behaviour). Otherwise we will end up with > just one huge and unmanageable group. The purpose of 'groups' is to understand interactions between components that are required for that feature, and to focus on those interactions that are the source of interop problems. In the case of CFNA and DND, there are identical interactions, so to me, they are the same group. Also note that if any one particular feature doesn't implement everyuthing defined by the group, thats fine too. We're not specifying how to do DND - we're not REQUIRING that anyone set presence based on it. So, if someones CFNA feature doesn't use presence, thats fine. It doesn't mean its a different group. The definition of the groups is not based on feature interactions between groups, and lack of interactions within a group. Its based entirely on a common set of protocol procedures that all of the features in a group require in order to interoperate. -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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 17:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5VB-00022P-67; Mon, 23 Jul 2007 17:31:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5V9-00022D-Fg for bliss@ietf.org; Mon, 23 Jul 2007 17:31:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID5V9-000342-2X for bliss@ietf.org; Mon, 23 Jul 2007 17:31:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2007 17:31:34 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHq6pEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="65935595:sNHT31762956" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NLVYaC020685; Mon, 23 Jul 2007 17:31:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NLVYWO025074; Mon, 23 Jul 2007 21:31:34 GMT 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.1830); Mon, 23 Jul 2007 17:31:07 -0400 Received: from [10.86.243.142] ([10.86.243.142]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:31:07 -0400 Message-ID: <46A51E23.4010304@cisco.com> Date: Mon, 23 Jul 2007 17:31:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <7374777208BDC7449D5620EF94232567072B6638@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567072B6638@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 21:31:07.0446 (UTC) FILETIME=[C7BD6D60:01C7CD70] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1446; t=1185226294; x=1186090294; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=XlwAyefD/64+kD9fcmF/j+K212A3ZBAHXs0i4JkpzQQ=; b=XpCjBaOFDoW71n8BJVbKglJudlXs30C7RfsHSru+LNdiPCfPTMYnIxaCP7knrTUltUHYf2jW upvmttbOMeg/JNDI1C9HZM0WIDrDe+U1lNX7PLbX0EVqG/LUxXm+ruea; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi Jonathan, > > I have a few questions for clarification. > > First, how are we going to define each feature? We're not. > Will we do a "feature > definition", or will we (if possible) use existing documentation > which defines the features? Neither. > For example, the feature names you have > listed all exist as supplementary services, with existing service > definition. Sure. And so? The thing we are defining are functional groups. These groups are defined by a common set of protocol interactions and mecahnisms amongst elements in the network, which are common. The abstract and introduction of our specification would give example features that fit into the category. The precise definition is not relevant. > > Second, chapter 5.2 says "Participants can also suggest flows they > think might exist". Does that cover flows that other SDOs have > produced, e.g. a TISPAN flow for a supplementary service which is > similar to a specific "feature"? Yes, sure. I'd love to see drafts with those proposed. -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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 17:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5pB-0001UO-2p; Mon, 23 Jul 2007 17:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5pA-0001UH-5k for bliss@ietf.org; Mon, 23 Jul 2007 17:52:16 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID5p8-0004et-KM for bliss@ietf.org; Mon, 23 Jul 2007 17:52:16 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLN00IIQJEMF5@siemenscomms.co.uk> for bliss@ietf.org; Mon, 23 Jul 2007 22:51:58 +0100 (BST) Date: Mon, 23 Jul 2007 22:52:12 +0100 From: "Elwell, John" Subject: RE: [BLISS] BLISS problem statement draft In-reply-to: <46A51D90.6040708@cisco.com> To: Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205EA3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfNcLxNINsTPYRLRpGKMBJmJEOBxAAAaVfg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46897CB3.9050609@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> <46A51D90.6040708@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 23 July 2007 22:29 > To: Elwell, John > Cc: bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft > > inline. > > Elwell, John wrote: > > Jonathan, > > > > I like the methodology proposed. > > Thanks. > > > > > One point of detail concerning the particular example given: > > > > "In the case of CFNA, clearly a functional > > primitive of "call forwarding features that execute on > no-answer" is > > too narrow. A functional primitive of "features that handle an > > initial INVITE" is too broad. An ideal starting point > would probably > > be, "features that result in a retargeting or response > operation that > > depend on user-specified criteria". This covers all of the call > > forwarding variations, but also includes features like Do-Not- > > Disturb." > > > > I agree that one action that can be taken on DND is to > forward (e.g., to > > voicemail, to an assistant). However, the bliss-dnd draft > covers more > > than this, in particular what to indicate to the caller, > how to clearly > > indicate DND to the proxy if the proxy is responsible for > forwarding, > > and what to indicate in presence. > > Well, I'd argue that all of these apply to CFNA also. It is > desirable to > indicate to the caller that their call is being forwarded. [JRE] For CFNR and other call forwarding variants we already have a provisional response, 181, for this, whereas for DND we need a final response. > Obviously > we'd need to indicate to the proxy how to do forwarding if > its desired. [JRE] Do you have in mind here instructing the proxy in advance (e.g., by CPL script), or instructing the proxy at call attempt time (using 302 response)? I agree the former is common, although I am not sure this is within the scope of BLISS (it would be done by non-SIP means). The latter doesn't apply to DND. > Even presence. For example, if CFNA is enabled, you might include a > element in the presence document. [JRE] True, although a different indication would be needed here. > > > These aspects are somewhat different > > from the call forwarding set of problems. I prefer to > regard it as an > > interaction between two groups of features (or two functional > > primitives) - the DND group and the forwarding group. > > I'm not sure I agree. > > In fact the > > problem of interactions will come up a lot, for example > impact of call > > forwarding on shared line appearance. We have to draw lines between > > groups of features somewhere and accept that there will be > interactions > > between groups and find out ways to handle these > interactions (in a way > > that does not constrain implementations but does not lead to > > unpredictable or undesirable behaviour). Otherwise we will > end up with > > just one huge and unmanageable group. > > The purpose of 'groups' is to understand interactions between > components > that are required for that feature, and to focus on those > interactions > that are the source of interop problems. In the case of CFNA and DND, > there are identical interactions, so to me, they are the same group. [JRE] Well, I am not convinced. Anyway, during my slot in BLISS tomorrow I will be raising this issue, so perhaps we will get other opinions. > > Also note that if any one particular feature doesn't implement > everyuthing defined by the group, thats fine too. We're not > specifying > how to do DND - we're not REQUIRING that anyone set presence based on > it. So, if someones CFNA feature doesn't use presence, thats fine. It > doesn't mean its a different group. [JRE] I agree that you don't have to implement everything in a group. So if a group includes CFNR, CFB and CFU, it should not oblige everyone to implement all three. But I am not convinced that DND is part of that group (but forwarding due to DND is). > > The definition of the groups is not based on feature interactions > between groups, and lack of interactions within a group. Its based > entirely on a common set of protocol procedures that all of > the features > in a group require in order to interoperate. [JRE] The ability to indicate a DND condition as a reason for call rejection is not a protocol procedure that is required by call forwarding features. > > -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 > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 18:01:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5y1-0001vH-CO; Mon, 23 Jul 2007 18:01:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5xz-0001v9-V9 for bliss@ietf.org; Mon, 23 Jul 2007 18:01:23 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID5xz-0004u6-1Z for bliss@ietf.org; Mon, 23 Jul 2007 18:01:23 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6NM1JG14093; Mon, 23 Jul 2007 22:01:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Mon, 23 Jul 2007 17:01:17 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> In-Reply-To: <46A51C12.5050703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfNb6aRbXMM8j7SQs6iqOKw0i4wPgAAewzg References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org A few comments inline...=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, July 23, 2007 4:22 PM > To: Paul Kyzivat > Cc: bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 > inline. >=20 > Paul Kyzivat wrote: > > I agree with you. > >=20 > > Also, in most cases there is one participant in a feature=20 > that is the=20 > > initiator. That participant knows what feature is being invoked. If=20 > > there are multiple ways to do the feature, that participant has=20 > > freedom in which way to do it. It may be constrained to=20 > some extent by=20 > > what functionality the peer had advertised support for. But the=20 > > support it depends on is not for features, but rather only=20 > for various primitives. >=20 > I think we need to be VERY careful here. In all cases, we are=20 > expecting > *something* to be present, in terms of functionality, from=20 > the non-intiators, even in single-ended features. At a=20 > minimum, we are expecting RFC 3261. In many cases, we may be=20 > expected support for something like REFER. If a UA doesn't=20 > support receipt of REFER, then the feature doesn't work even=20 > if you think its single ended. >=20 > As such, even for single ended features, we will need to=20 > state minimum requirements (i.e., implement REFER) for that=20 > feature group. I'd argue that the only single-ended features are ones that expect the other endpoint to be willing and able to establish a session. I don't even think the non-initiator should be required to understand SIP; meaning, that the feature still works with a SIP-to-foo gateway (where nothing is known about the workings of the foo protocol) in front of the non-initiating endpoint. If you require the non-initiator to do more, then the feature is not single-ended. You're requiring some level of cooperation or willingness to be manipulated by the non-initiator in order to make the feature operate. That's what I meant earlier as the dividing line between what is single-ended and what is double-ended. Single ended features require no state to be created or transferred between the initiator and the non-initiator of a feature beyond what is required to successfully setup the most basic dialog possible because this is the minimum amount of state required to be created in the non-initiating client. Everything else is incremental and makes assumptions about the non-initiator's behavior. I don't see how any feature which uses REFER (just to pick an example) could ever be single-ended, whereas you can definitely implement Call Forwarding as a single-ended feature in which the non-initiator may not even be able to detect that the feature had been invoked. I definitely do agree that stating the minimum requirements for a feature group would be necessary. >=20 > >=20 > > The other participant(s) are more in the way bystanders. They don't=20 > > know what feature they are being asked to participate in.=20 > Rather, they=20 > > get some stimulus - typically a request in the context of=20 > some state=20 > > the node has, and then must react to that by doing something. > >=20 > > What's important is that the non-initiating participants do what is=20 > > necessary to allow the completion of the service kicked off by the=20 > > initiator, even if they would never have initiated the service the=20 > > same way if they were the initiator. >=20 >=20 > Right. By definition, a bystander does not get involved in something. It simply observes what is going on with no requirement to take action or even understand what it is observing. If we're requiring the non-initiator to take action upon our requests (stimulus), it may not need to know where the initiator is ultimately trying to do (i.e. the feature) but it must be willing to 'play-along'. >=20 > >=20 > > Of course is isn't really that simple. The non-initiating=20 > participants=20 > > may still have some discretion in initiating the next step in a=20 > > complex sequence. >=20 > If the feature requires the non-initiating participants to do=20 > something that is specific to this feature, it is by=20 > definition, not single-ended. Again, I would argue that if they require the non-initiating participants to do something that is beyond basic dialog establishment, then it is not single-ended. >=20 > >=20 > > So I think the key things we need to do are: > > - ensure that different features don't result in an identical > > stimulus to some participant while requiring that participant > > to take a different action for each feature. (Since it doesn't > > know what feature it is doing.) >=20 > Right. We need to look very carefully about what expectations=20 > we have for non-participants. Even for something like receipt=20 > of REFER, you need to make sure that the UA has what it needs=20 > to authorize the request. Agree. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 18:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6nf-0005aQ-Lo; Mon, 23 Jul 2007 18:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6nd-0005aL-Gj for bliss@ietf.org; Mon, 23 Jul 2007 18:54:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID6nc-00066s-NK for bliss@ietf.org; Mon, 23 Jul 2007 18:54:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 18:54:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACvOpEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126818230:sNHT33286110" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NMsieZ016453; Mon, 23 Jul 2007 18:54:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6NMsiEZ024678; Mon, 23 Jul 2007 22:54:44 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); Mon, 23 Jul 2007 18:54:44 -0400 Received: from [10.86.243.142] ([10.86.243.142]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 18:54:43 -0400 Message-ID: <46A531BB.6000803@cisco.com> Date: Mon, 23 Jul 2007 18:54:51 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 22:54:43.0761 (UTC) FILETIME=[75B25A10:01C7CD7C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6121; t=1185231284; x=1186095284; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Brian=20Stucker=20; bh=tbkW+gAvIFUu6sS/NL6MArxvIyFhDPtOoJg9FjQGBa8=; b=Lm7k4CLsM6l4AILKDAoEr8QkGSfKsHG1X2aX7ahEVjZ2LSoKpsRyUUw7KNSTn+2cwjZRxRW7 gJ1dUT91kDEy08W/KEq9mK1VLHeQNu2Gba4ff6V0bBv+9NVjxZ+uajXA; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think this is a good definition for single-ended - that it doesn't require other participants to do anything beyond that which would be needed for the most basic call setup. By this definition, almost nothing is single ended.... -Jonathan R. Brian Stucker wrote: > A few comments inline... > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Monday, July 23, 2007 4:22 PM >> To: Paul Kyzivat >> Cc: bliss@ietf.org >> Subject: Re: [BLISS] BLISS problem statement draft >> >> inline. >> >> Paul Kyzivat wrote: >>> I agree with you. >>> >>> Also, in most cases there is one participant in a feature >> that is the >>> initiator. That participant knows what feature is being invoked. If >>> there are multiple ways to do the feature, that participant has >>> freedom in which way to do it. It may be constrained to >> some extent by >>> what functionality the peer had advertised support for. But the >>> support it depends on is not for features, but rather only >> for various primitives. >> >> I think we need to be VERY careful here. In all cases, we are >> expecting >> *something* to be present, in terms of functionality, from >> the non-intiators, even in single-ended features. At a >> minimum, we are expecting RFC 3261. In many cases, we may be >> expected support for something like REFER. If a UA doesn't >> support receipt of REFER, then the feature doesn't work even >> if you think its single ended. >> >> As such, even for single ended features, we will need to >> state minimum requirements (i.e., implement REFER) for that >> feature group. > > I'd argue that the only single-ended features are ones that expect the > other endpoint to be willing and able to establish a session. I don't > even think the non-initiator should be required to understand SIP; > meaning, that the feature still works with a SIP-to-foo gateway (where > nothing is known about the workings of the foo protocol) in front of the > non-initiating endpoint. > > If you require the non-initiator to do more, then the feature is not > single-ended. You're requiring some level of cooperation or willingness > to be manipulated by the non-initiator in order to make the feature > operate. That's what I meant earlier as the dividing line between what > is single-ended and what is double-ended. > > Single ended features require no state to be created or transferred > between the initiator and the non-initiator of a feature beyond what is > required to successfully setup the most basic dialog possible because > this is the minimum amount of state required to be created in the > non-initiating client. Everything else is incremental and makes > assumptions about the non-initiator's behavior. > > I don't see how any feature which uses REFER (just to pick an example) > could ever be single-ended, whereas you can definitely implement Call > Forwarding as a single-ended feature in which the non-initiator may not > even be able to detect that the feature had been invoked. > > I definitely do agree that stating the minimum requirements for a > feature group would be necessary. > >>> The other participant(s) are more in the way bystanders. They don't >>> know what feature they are being asked to participate in. >> Rather, they >>> get some stimulus - typically a request in the context of >> some state >>> the node has, and then must react to that by doing something. >>> >>> What's important is that the non-initiating participants do what is >>> necessary to allow the completion of the service kicked off by the >>> initiator, even if they would never have initiated the service the >>> same way if they were the initiator. >> >> Right. > > By definition, a bystander does not get involved in something. It simply > observes what is going on with no requirement to take action or even > understand what it is observing. If we're requiring the non-initiator to > take action upon our requests (stimulus), it may not need to know where > the initiator is ultimately trying to do (i.e. the feature) but it must > be willing to 'play-along'. > >>> Of course is isn't really that simple. The non-initiating >> participants >>> may still have some discretion in initiating the next step in a >>> complex sequence. >> If the feature requires the non-initiating participants to do >> something that is specific to this feature, it is by >> definition, not single-ended. > > Again, I would argue that if they require the non-initiating > participants to do something that is beyond basic dialog establishment, > then it is not single-ended. > >>> So I think the key things we need to do are: >>> - ensure that different features don't result in an identical >>> stimulus to some participant while requiring that participant >>> to take a different action for each feature. (Since it doesn't >>> know what feature it is doing.) >> Right. We need to look very carefully about what expectations >> we have for non-participants. Even for something like receipt >> of REFER, you need to make sure that the UA has what it needs >> to authorize the request. > > Agree. > >> -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 >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > -- 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 19:03:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6vy-0000uL-82; Mon, 23 Jul 2007 19:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6vx-0000uG-Il for bliss@ietf.org; Mon, 23 Jul 2007 19:03:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID6vw-0006Gt-WA for bliss@ietf.org; Mon, 23 Jul 2007 19:03:21 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 19:03:20 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEbQpEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126818730:sNHT36104730" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NN3KYq019036; Mon, 23 Jul 2007 19:03:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6NN3FEZ027308; Mon, 23 Jul 2007 23:03:16 GMT 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.1830); Mon, 23 Jul 2007 19:03:15 -0400 Received: from [10.86.243.142] ([10.86.243.142]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 19:03:14 -0400 Message-ID: <46A533BB.3020504@cisco.com> Date: Mon, 23 Jul 2007 19:03:23 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> <46A51D90.6040708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0205EA3@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0205EA3@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 23:03:15.0005 (UTC) FILETIME=[A66BFED0:01C7CD7D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3907; t=1185231800; x=1186095800; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=rMnjPTn69/KFNMaOPefrmI2zQ9U7tg+5aWou9cue3Mo=; b=C0A2vYJtJzOWvgQEreC7Ck7OWhxGJbogyJ7dEcw7VGokxy1Xe4g2+FzMhy+NB8iSziNvg4xw E2oimUkDEGAOO+CPQMZ1puqBdeKQMSyvrqYzf6J+WigD7ykFHbZ0DmEx; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Elwell, John wrote: > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 23 July 2007 22:29 >> To: Elwell, John >> Cc: bliss@ietf.org >> Subject: Re: [BLISS] BLISS problem statement draft >> >> inline. >> >> Elwell, John wrote: >>> Jonathan, >>> >>> I like the methodology proposed. >> Thanks. >> >>> One point of detail concerning the particular example given: >>> >>> "In the case of CFNA, clearly a functional >>> primitive of "call forwarding features that execute on >> no-answer" is >>> too narrow. A functional primitive of "features that handle an >>> initial INVITE" is too broad. An ideal starting point >> would probably >>> be, "features that result in a retargeting or response >> operation that >>> depend on user-specified criteria". This covers all of the call >>> forwarding variations, but also includes features like Do-Not- >>> Disturb." >>> >>> I agree that one action that can be taken on DND is to >> forward (e.g., to >>> voicemail, to an assistant). However, the bliss-dnd draft >> covers more >>> than this, in particular what to indicate to the caller, >> how to clearly >>> indicate DND to the proxy if the proxy is responsible for >> forwarding, >>> and what to indicate in presence. >> Well, I'd argue that all of these apply to CFNA also. It is >> desirable to >> indicate to the caller that their call is being forwarded. > [JRE] For CFNR and other call forwarding variants we already have a > provisional response, 181, for this, whereas for DND we need a final > response. > OK, fair point. But I'm not sure that different requires a whole other deliverable. A single specification that covers different types of treatment - rejection, forwarding, redirection, etc., would suffice. Also, its only important to specify what is necessary for interop. As such it may not be necessary to say anything about specific response codes back to the originator. What actual interop problem shows up if the originator gets a simple 400 for DND, rather than something that explicitly says, "your call was rejected due to DND"? And if DND causes a call to go to voicemail, clearly in that case there is no rejection response. >> Obviously >> we'd need to indicate to the proxy how to do forwarding if >> its desired. > [JRE] Do you have in mind here instructing the proxy in advance (e.g., > by CPL script), or instructing the proxy at call attempt time (using 302 > response)? My own preference is instructing the proxy to advance. User expectation in many cases that, from a UA, a user can select "call forward unconditional" or whatever, and that happens. So that needs to be signaled. I tend to prefer this in the proxy, largely due to forking complexities. > I agree the former is common, although I am not sure this is > within the scope of BLISS (it would be done by non-SIP means). The > latter doesn't apply to DND. As per other discussions, I think it is within our scope to make recommendations on this kind of 'provisioning' only when there is a clear requirement for an automated way to convey it from a component to another. > [JRE] The ability to indicate a DND condition as a reason for call > rejection is not a protocol procedure that is required by call > forwarding features. per above, what is the interoperability failure you are concerned about if the element implementing DND uses a response code of its choice? -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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 19:07:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6zr-0004RB-TX; Mon, 23 Jul 2007 19:07:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6zq-0004R6-TM for bliss@ietf.org; Mon, 23 Jul 2007 19:07:22 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID6zq-000597-G8 for bliss@ietf.org; Mon, 23 Jul 2007 19:07:22 -0400 Received: from dhcp-1618.ietf69.org ([130.129.22.24]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ID6zp-0000XG-7g; Mon, 23 Jul 2007 19:07:21 -0400 X-MHO-User: U2FsdGVkX19T5aGpCn5u0+SAYq8/ESx2AX3tKDhMW8Q= X-MHO-User: U2FsdGVkX1/+fNEiozNKtJsa7rjGxTd+VthUVd8FdkI= X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.22.24 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+0DIUM9+CS5e6fIyu8492zt5z8xIzBrvw= Message-ID: <46A534A6.7080104@sipstation.com> Date: Mon, 23 Jul 2007 18:07:18 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [BLISS] Comments on draft-johnston-bliss-mla-req-00.txt References: <458913680707171302n57943755p801b913950473a19@mail.gmail.com> <469D3D24.4010509@cisco.com> In-Reply-To: <469D3D24.4010509@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: bliss@ietf.org, Xavier Marjou X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Xavier, Thanks for your comments on the draft - see mine below. Thanks, Alan Paul Kyzivat wrote: > > > Xavier Marjou wrote: >> Hi, >> >> With regards to usage scenario 1, the executive probably wants to keep >> its own "line" private in order that the caller does not learn a way >> to join him directly. I understand this is covered by REQ-13. However >> in Section 5, it seems to me that privacy is not entirely covered. For >> example, if an INVITE from a caller finally arrives at the executive >> UA, the Contact of 200 returned by the executive UA to the caller >> would indicate a way to directy reach his "line". > > Interesting problem. The contact probably does need to address him > directly for some features to work (e.g. another transfer). > > A temporary GRUU would do the job here. With that, the caller could in > principle call him back directly using that URI until/unless the > executive forces temp gruus to be invalidated. > I agree with Paul that a temporary GRUU would be a good idea here. We will add some text discussing this. > Paul > >> Concerning the "Implementation Options" section, I'd suggest to >> indicate an authentication step during the registration (step 3) so >> that any UA (i.e. a UA external to the group) can not join the group. >> Agree that authentication is important and should be mentioned. >> Cheers, >> Xavier >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 19:22:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7Eg-0006Jr-VM; Mon, 23 Jul 2007 19:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7Ee-0006Iq-0w for bliss@ietf.org; Mon, 23 Jul 2007 19:22:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID7Ed-0006h5-6n for bliss@ietf.org; Mon, 23 Jul 2007 19:22:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2007 19:22:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAG/VpEZAZnmf/2dsb2JhbACIX50O X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="65942709:sNHT32651076" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NNMcRV009829; Mon, 23 Jul 2007 19:22:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6NNMMEh002809; Mon, 23 Jul 2007 23:22:38 GMT 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.1830); Mon, 23 Jul 2007 19:22:25 -0400 Received: from [10.86.241.49] ([10.86.241.49]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 19:22:25 -0400 Message-ID: <46A5382C.9090906@cisco.com> Date: Mon, 23 Jul 2007 19:22:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> <46A531BB.6000803@cisco.com> In-Reply-To: <46A531BB.6000803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 23:22:25.0575 (UTC) FILETIME=[54370B70:01C7CD80] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6822; t=1185232958; x=1186096958; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=rHha9Qdk7dT9YPlOrZwsYo3BTqAzjPiqctVDFJJRLyA=; b=Dpimg1n0QjarBhme5P7fBCIxXQqHbK1Kg4/hEwK0cFRiekG91G2DHrZbcg5FojmADfFd7mdD n9JuqTzRb30EuabfUwMF2pkNPfF5hFTLqvW51W0dxnqdBfvpOp7lHJ8J; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan Rosenberg wrote: > I think this is a good definition for single-ended - that it doesn't > require other participants to do anything beyond that which would be > needed for the most basic call setup. > By this definition, almost nothing is single ended.... In that case its not a useful concept. Maybe "single ended" is uninteresting. I used the terms "initiator" and "bystander". The bystander is still a participant and may have a role to play in features that are not "single ended". We currently have primitives, such as REFER, that in theory can be acted upon without context of why they were received. I hope in some cases features that use such techniques can still work with bystanders that don't have any special context, or knowledge of the feature invoked by the initiator. The key is discovering the cases where this is *not* the case. Before those can be successful there must be a way to ensure that the bystander *does* have "enough" context to unambiguously decide what to do. This in general *does not* require that the bystander have enough context to know exactly what feature is being executed. Paul > -Jonathan R. > > Brian Stucker wrote: >> A few comments inline... >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Monday, >>> July 23, 2007 4:22 PM >>> To: Paul Kyzivat >>> Cc: bliss@ietf.org >>> Subject: Re: [BLISS] BLISS problem statement draft >>> >>> inline. >>> >>> Paul Kyzivat wrote: >>>> I agree with you. >>>> >>>> Also, in most cases there is one participant in a feature >>> that is the >>>> initiator. That participant knows what feature is being invoked. If >>>> there are multiple ways to do the feature, that participant has >>>> freedom in which way to do it. It may be constrained to >>> some extent by >>>> what functionality the peer had advertised support for. But the >>>> support it depends on is not for features, but rather only >>> for various primitives. >>> >>> I think we need to be VERY careful here. In all cases, we are expecting >>> *something* to be present, in terms of functionality, from the >>> non-intiators, even in single-ended features. At a minimum, we are >>> expecting RFC 3261. In many cases, we may be expected support for >>> something like REFER. If a UA doesn't support receipt of REFER, then >>> the feature doesn't work even if you think its single ended. >>> >>> As such, even for single ended features, we will need to state >>> minimum requirements (i.e., implement REFER) for that feature group. >> >> I'd argue that the only single-ended features are ones that expect the >> other endpoint to be willing and able to establish a session. I don't >> even think the non-initiator should be required to understand SIP; >> meaning, that the feature still works with a SIP-to-foo gateway (where >> nothing is known about the workings of the foo protocol) in front of the >> non-initiating endpoint. >> >> If you require the non-initiator to do more, then the feature is not >> single-ended. You're requiring some level of cooperation or willingness >> to be manipulated by the non-initiator in order to make the feature >> operate. That's what I meant earlier as the dividing line between what >> is single-ended and what is double-ended. >> >> Single ended features require no state to be created or transferred >> between the initiator and the non-initiator of a feature beyond what is >> required to successfully setup the most basic dialog possible because >> this is the minimum amount of state required to be created in the >> non-initiating client. Everything else is incremental and makes >> assumptions about the non-initiator's behavior. >> >> I don't see how any feature which uses REFER (just to pick an example) >> could ever be single-ended, whereas you can definitely implement Call >> Forwarding as a single-ended feature in which the non-initiator may not >> even be able to detect that the feature had been invoked. >> >> I definitely do agree that stating the minimum requirements for a >> feature group would be necessary. >> >>>> The other participant(s) are more in the way bystanders. They don't >>>> know what feature they are being asked to participate in. >>> Rather, they >>>> get some stimulus - typically a request in the context of >>> some state >>>> the node has, and then must react to that by doing something. >>>> >>>> What's important is that the non-initiating participants do what is >>>> necessary to allow the completion of the service kicked off by the >>>> initiator, even if they would never have initiated the service the >>>> same way if they were the initiator. >>> >>> Right. >> >> By definition, a bystander does not get involved in something. It simply >> observes what is going on with no requirement to take action or even >> understand what it is observing. If we're requiring the non-initiator to >> take action upon our requests (stimulus), it may not need to know where >> the initiator is ultimately trying to do (i.e. the feature) but it must >> be willing to 'play-along'. >> >>>> Of course is isn't really that simple. The non-initiating >>> participants >>>> may still have some discretion in initiating the next step in a >>>> complex sequence. >>> If the feature requires the non-initiating participants to do >>> something that is specific to this feature, it is by definition, not >>> single-ended. >> >> Again, I would argue that if they require the non-initiating >> participants to do something that is beyond basic dialog establishment, >> then it is not single-ended. >> >>>> So I think the key things we need to do are: >>>> - ensure that different features don't result in an identical >>>> stimulus to some participant while requiring that participant >>>> to take a different action for each feature. (Since it doesn't >>>> know what feature it is doing.) >>> Right. We need to look very carefully about what expectations we have >>> for non-participants. Even for something like receipt of REFER, you >>> need to make sure that the UA has what it needs to authorize the >>> request. >> >> Agree. >> >>> -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 >>> >>> _______________________________________________ >>> BLISS mailing list >>> BLISS@ietf.org >>> https://www1.ietf.org/mailman/listinfo/bliss >>> >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 19:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7hC-00038O-HC; Mon, 23 Jul 2007 19:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7hA-00031R-Nr for bliss@ietf.org; Mon, 23 Jul 2007 19:52:08 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID7h9-0007EO-Qw for bliss@ietf.org; Mon, 23 Jul 2007 19:52:08 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6NNq4m27288; Mon, 23 Jul 2007 23:52:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Mon, 23 Jul 2007 18:52:02 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115BB6E76@zrc2hxm2.corp.nortel.com> In-Reply-To: <46A531BB.6000803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfNfHzqIOYfJgqfT5SmrWm3cq85/AABnBEg References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> <46A531BB.6000803@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yeah, probably a little draconian. Perhaps we could take single-endedness to mean that there's no state requirement (outside of basic protocol requirements) on the non-initiator of the feature. For example, if a feature sends a REFER to another endpoint, and the feature doesn't require some state to be created or pre-exist outside of basic REFER processing, that may also qualify. Looking for a good middle ground to essentially describe the case where one side of the call doesn't have to do anything special outside of supporting widely implemented protocol primitives (I know, slippery ground). It would essentially mean then whether or not you can manipulate the non-initiator into taking all of the necessary steps to appear to understand a particular feature that it does not claim support for. For example, the non-initiator may not support consultative call transfer, but it does support REFER. To the initiator of a consultative call transfer feature that uses only primitives such as REFER, the feature appears to work even though the non-initiator wasn't doing anything specific to that feature: it's single-ended. This is essentially what I was trying to go for here. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, July 23, 2007 5:55 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Paul Kyzivat; bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 > I think this is a good definition for single-ended - that it=20 > doesn't require other participants to do anything beyond that=20 > which would be needed for the most basic call setup. >=20 > By this definition, almost nothing is single ended.... >=20 > -Jonathan R. >=20 > Brian Stucker wrote: > > A few comments inline...=20 > >=20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Monday, July 23, 2007 4:22 PM > >> To: Paul Kyzivat > >> Cc: bliss@ietf.org > >> Subject: Re: [BLISS] BLISS problem statement draft > >> > >> inline. > >> > >> Paul Kyzivat wrote: > >>> I agree with you. > >>> > >>> Also, in most cases there is one participant in a feature > >> that is the > >>> initiator. That participant knows what feature is being=20 > invoked. If=20 > >>> there are multiple ways to do the feature, that participant has=20 > >>> freedom in which way to do it. It may be constrained to > >> some extent by > >>> what functionality the peer had advertised support for. But the=20 > >>> support it depends on is not for features, but rather only > >> for various primitives. > >> > >> I think we need to be VERY careful here. In all cases, we are=20 > >> expecting > >> *something* to be present, in terms of functionality, from the=20 > >> non-intiators, even in single-ended features. At a minimum, we are=20 > >> expecting RFC 3261. In many cases, we may be expected support for=20 > >> something like REFER. If a UA doesn't support receipt of=20 > REFER, then=20 > >> the feature doesn't work even if you think its single ended. > >> > >> As such, even for single ended features, we will need to state=20 > >> minimum requirements (i.e., implement REFER) for that=20 > feature group. > >=20 > > I'd argue that the only single-ended features are ones that=20 > expect the=20 > > other endpoint to be willing and able to establish a=20 > session. I don't=20 > > even think the non-initiator should be required to understand SIP;=20 > > meaning, that the feature still works with a SIP-to-foo=20 > gateway (where=20 > > nothing is known about the workings of the foo protocol) in=20 > front of=20 > > the non-initiating endpoint. > >=20 > > If you require the non-initiator to do more, then the=20 > feature is not=20 > > single-ended. You're requiring some level of cooperation or=20 > > willingness to be manipulated by the non-initiator in order to make=20 > > the feature operate. That's what I meant earlier as the=20 > dividing line=20 > > between what is single-ended and what is double-ended. > >=20 > > Single ended features require no state to be created or transferred=20 > > between the initiator and the non-initiator of a feature=20 > beyond what=20 > > is required to successfully setup the most basic dialog possible=20 > > because this is the minimum amount of state required to be=20 > created in=20 > > the non-initiating client. Everything else is incremental and makes=20 > > assumptions about the non-initiator's behavior. > >=20 > > I don't see how any feature which uses REFER (just to pick=20 > an example)=20 > > could ever be single-ended, whereas you can definitely=20 > implement Call=20 > > Forwarding as a single-ended feature in which the non-initiator may=20 > > not even be able to detect that the feature had been invoked. > >=20 > > I definitely do agree that stating the minimum requirements for a=20 > > feature group would be necessary. > >=20 > >>> The other participant(s) are more in the way bystanders.=20 > They don't=20 > >>> know what feature they are being asked to participate in. > >> Rather, they > >>> get some stimulus - typically a request in the context of > >> some state > >>> the node has, and then must react to that by doing something. > >>> > >>> What's important is that the non-initiating participants=20 > do what is=20 > >>> necessary to allow the completion of the service kicked=20 > off by the=20 > >>> initiator, even if they would never have initiated the=20 > service the=20 > >>> same way if they were the initiator. > >> > >> Right. > >=20 > > By definition, a bystander does not get involved in something. It=20 > > simply observes what is going on with no requirement to=20 > take action or=20 > > even understand what it is observing. If we're requiring the=20 > > non-initiator to take action upon our requests (stimulus),=20 > it may not=20 > > need to know where the initiator is ultimately trying to do=20 > (i.e. the=20 > > feature) but it must be willing to 'play-along'. > >=20 > >>> Of course is isn't really that simple. The non-initiating > >> participants > >>> may still have some discretion in initiating the next step in a=20 > >>> complex sequence. > >> If the feature requires the non-initiating participants to do=20 > >> something that is specific to this feature, it is by=20 > definition, not=20 > >> single-ended. > >=20 > > Again, I would argue that if they require the non-initiating=20 > > participants to do something that is beyond basic dialog=20 > > establishment, then it is not single-ended. > >=20 > >>> So I think the key things we need to do are: > >>> - ensure that different features don't result in an identical > >>> stimulus to some participant while requiring that participant > >>> to take a different action for each feature. (Since it doesn't > >>> know what feature it is doing.) > >> Right. We need to look very carefully about what=20 > expectations we have=20 > >> for non-participants. Even for something like receipt of=20 > REFER, you=20 > >> need to make sure that the UA has what it needs to authorize the=20 > >> request. > >=20 > > Agree. > >=20 > >> -Jonathan R. > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ=20 > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 19:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7m5-0006qd-U0; Mon, 23 Jul 2007 19:57:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7m4-0006qV-6e for bliss@ietf.org; Mon, 23 Jul 2007 19:57:12 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID7m3-0006Ad-5I for bliss@ietf.org; Mon, 23 Jul 2007 19:57:11 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6NNv7m27555; Mon, 23 Jul 2007 23:57:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Mon, 23 Jul 2007 18:57:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115BB6E80@zrc2hxm2.corp.nortel.com> In-Reply-To: <46A5382C.9090906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfNgGDtJM7qUTTMRaeXP7u8VNjWkwABBv9w References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> <46A531BB.6000803@cisco.com> <46A5382C.9090906@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, July 23, 2007 6:22 PM > To: Jonathan Rosenberg > Cc: Stucker, Brian (RICH1:AR00); bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 >=20 >=20 > Jonathan Rosenberg wrote: > > I think this is a good definition for single-ended - that=20 > it doesn't=20 > > require other participants to do anything beyond that which=20 > would be=20 > > needed for the most basic call setup. >=20 > > By this definition, almost nothing is single ended.... >=20 > In that case its not a useful concept. Maybe "single ended"=20 > is uninteresting. I used the terms "initiator" and=20 > "bystander". The bystander is still a participant and may=20 > have a role to play in features that are not "single ended". I'm having a difficult time following what you mean by "bystander". By definition, a bystander cannot be a participant.=20 >=20 > We currently have primitives, such as REFER, that in theory=20 > can be acted upon without context of why they were received.=20 > I hope in some cases features that use such techniques can=20 > still work with bystanders that don't have any special=20 > context, or knowledge of the feature invoked by the initiator. Sounds familiar. :) >=20 > The key is discovering the cases where this is *not* the=20 > case. Before those can be successful there must be a way to=20 > ensure that the bystander > *does* have "enough" context to unambiguously decide what to=20 > do. This in general *does not* require that the bystander=20 > have enough context to know exactly what feature is being executed. Outside of normal protocol restrictions, such as "don't send a REFER on a dialog that is not yet confirmed" I think the only state you can rely upon as the initiator is whatever you can determine unambiguously from the outcome of the previously applied primitive operations. If you need more, it's definitely double-ended. You're having to collude with the non-initiator (I think what you're referring to here as a bystander) to make things work. >=20 > Paul >=20 > > -Jonathan R. > >=20 > > Brian Stucker wrote: > >> A few comments inline... > >>> -----Original Message----- > >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Monday,=20 > >>> July 23, 2007 4:22 PM > >>> To: Paul Kyzivat > >>> Cc: bliss@ietf.org > >>> Subject: Re: [BLISS] BLISS problem statement draft > >>> > >>> inline. > >>> > >>> Paul Kyzivat wrote: > >>>> I agree with you. > >>>> > >>>> Also, in most cases there is one participant in a feature > >>> that is the > >>>> initiator. That participant knows what feature is being=20 > invoked. If=20 > >>>> there are multiple ways to do the feature, that participant has=20 > >>>> freedom in which way to do it. It may be constrained to > >>> some extent by > >>>> what functionality the peer had advertised support for. But the=20 > >>>> support it depends on is not for features, but rather only > >>> for various primitives. > >>> > >>> I think we need to be VERY careful here. In all cases, we are=20 > >>> expecting > >>> *something* to be present, in terms of functionality, from the=20 > >>> non-intiators, even in single-ended features. At a=20 > minimum, we are=20 > >>> expecting RFC 3261. In many cases, we may be expected support for=20 > >>> something like REFER. If a UA doesn't support receipt of=20 > REFER, then=20 > >>> the feature doesn't work even if you think its single ended. > >>> > >>> As such, even for single ended features, we will need to state=20 > >>> minimum requirements (i.e., implement REFER) for that=20 > feature group. > >> > >> I'd argue that the only single-ended features are ones that expect=20 > >> the other endpoint to be willing and able to establish a=20 > session. I=20 > >> don't even think the non-initiator should be required to=20 > understand=20 > >> SIP; meaning, that the feature still works with a=20 > SIP-to-foo gateway=20 > >> (where nothing is known about the workings of the foo protocol) in=20 > >> front of the non-initiating endpoint. > >> > >> If you require the non-initiator to do more, then the=20 > feature is not=20 > >> single-ended. You're requiring some level of cooperation or=20 > >> willingness to be manipulated by the non-initiator in=20 > order to make=20 > >> the feature operate. That's what I meant earlier as the=20 > dividing line=20 > >> between what is single-ended and what is double-ended. > >> > >> Single ended features require no state to be created or=20 > transferred=20 > >> between the initiator and the non-initiator of a feature=20 > beyond what=20 > >> is required to successfully setup the most basic dialog possible=20 > >> because this is the minimum amount of state required to be=20 > created in=20 > >> the non-initiating client. Everything else is incremental=20 > and makes=20 > >> assumptions about the non-initiator's behavior. > >> > >> I don't see how any feature which uses REFER (just to pick an=20 > >> example) could ever be single-ended, whereas you can definitely=20 > >> implement Call Forwarding as a single-ended feature in which the=20 > >> non-initiator may not even be able to detect that the=20 > feature had been invoked. > >> > >> I definitely do agree that stating the minimum requirements for a=20 > >> feature group would be necessary. > >> > >>>> The other participant(s) are more in the way bystanders.=20 > They don't=20 > >>>> know what feature they are being asked to participate in. > >>> Rather, they > >>>> get some stimulus - typically a request in the context of > >>> some state > >>>> the node has, and then must react to that by doing something. > >>>> > >>>> What's important is that the non-initiating participants=20 > do what is=20 > >>>> necessary to allow the completion of the service kicked=20 > off by the=20 > >>>> initiator, even if they would never have initiated the=20 > service the=20 > >>>> same way if they were the initiator. > >>> > >>> Right. > >> > >> By definition, a bystander does not get involved in something. It=20 > >> simply observes what is going on with no requirement to=20 > take action=20 > >> or even understand what it is observing. If we're requiring the=20 > >> non-initiator to take action upon our requests (stimulus),=20 > it may not=20 > >> need to know where the initiator is ultimately trying to=20 > do (i.e. the=20 > >> feature) but it must be willing to 'play-along'. > >> > >>>> Of course is isn't really that simple. The non-initiating > >>> participants > >>>> may still have some discretion in initiating the next step in a=20 > >>>> complex sequence. > >>> If the feature requires the non-initiating participants to do=20 > >>> something that is specific to this feature, it is by=20 > definition, not=20 > >>> single-ended. > >> > >> Again, I would argue that if they require the non-initiating=20 > >> participants to do something that is beyond basic dialog=20 > >> establishment, then it is not single-ended. > >> > >>>> So I think the key things we need to do are: > >>>> - ensure that different features don't result in an identical > >>>> stimulus to some participant while requiring that participant > >>>> to take a different action for each feature. (Since it doesn't > >>>> know what feature it is doing.) > >>> Right. We need to look very carefully about what expectations we=20 > >>> have for non-participants. Even for something like=20 > receipt of REFER,=20 > >>> you need to make sure that the UA has what it needs to=20 > authorize the=20 > >>> request. > >> > >> Agree. > >> > >>> -Jonathan R. > >>> --=20 > >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>> Cisco Fellow =20 > Parsippany, NJ 07054-2711 > >>> Cisco Systems > >>> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >>> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >>> http://www.cisco.com > >>> > >>> _______________________________________________ > >>> BLISS mailing list > >>> BLISS@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/bliss > >>> > >> > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 20:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7rx-0003Bp-Jq; Mon, 23 Jul 2007 20:03:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7rw-000358-7c for bliss@ietf.org; Mon, 23 Jul 2007 20:03:16 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID7rv-0006IV-Rw for bliss@ietf.org; Mon, 23 Jul 2007 20:03:16 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLN0065QPGZW8@siemenscomms.co.uk> for bliss@ietf.org; Tue, 24 Jul 2007 01:02:59 +0100 (BST) Date: Tue, 24 Jul 2007 01:03:13 +0100 From: "Elwell, John" Subject: RE: [BLISS] BLISS problem statement draft In-reply-to: <46A533BB.3020504@cisco.com> To: Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205EA5@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfNfat14Audg9LnSmySTd6WKthokgAB79rA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46897CB3.9050609@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> <46A51D90.6040708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0205EA3@GBNTHT12009MSX.gb002.siemens.net> <46A533BB.3020504@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan, > > > [JRE] The ability to indicate a DND condition as a reason for call > > rejection is not a protocol procedure that is required by call > > forwarding features. > > per above, what is the interoperability failure you are > concerned about > if the element implementing DND uses a response code of its choice? [JRE] If a UAS sends one response code and a proxy programmed to forward on DND expects a different response code, this will result in failure. I agree that the response code the UAC receives is unimportant from an interoperability point of view (but might still be important for conveying appropriate information to the caller - similar motivation to that for extending RPID to indicate DND explicitly). John _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 23 20:29:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8HB-0003Km-NZ; Mon, 23 Jul 2007 20:29:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8HA-0003Kg-FH for bliss@ietf.org; Mon, 23 Jul 2007 20:29:20 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID8HA-0007pS-4T for bliss@ietf.org; Mon, 23 Jul 2007 20:29:20 -0400 Received: from [130.129.17.120] (dhcp-1178.ietf69.org [130.129.17.120]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6O0TJkK008472 for ; Mon, 23 Jul 2007 18:29:19 -0600 Message-ID: <46A547D8.2080503@ntt-at.com> Date: Mon, 23 Jul 2007 17:29:12 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: bliss@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [BLISS] Slides available online. X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1651156944==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============1651156944== Content-Type: multipart/alternative; boundary="------------010606000309010703020203" This is a multi-part message in MIME format. --------------010606000309010703020203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Following slides are available online. Problem Statement Shared Line Automated Handling Regards Shida --------------010606000309010703020203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
 Following slides are available online.

  Problem Statement
  Shared Line
  Automated Handling

 Regards
  Shida
--------------010606000309010703020203-- --===============1651156944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1651156944==-- From bliss-bounces@ietf.org Mon Jul 23 22:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDA44-0004xi-UY; Mon, 23 Jul 2007 22:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDA43-0004xZ-De for bliss@ietf.org; Mon, 23 Jul 2007 22:23:55 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDA41-0001kf-VX for bliss@ietf.org; Mon, 23 Jul 2007 22:23:55 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 418C320492; Tue, 24 Jul 2007 04:23:53 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-3f-46a562b896ac Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 01F86200A1; Tue, 24 Jul 2007 04:23:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 04:23:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Tue, 24 Jul 2007 04:23:47 +0200 Message-ID: <7374777208BDC7449D5620EF94232567074B1BFF@esealmw113.eemea.ericsson.se> In-Reply-To: <46A51E23.4010304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfNcNkNTLE3/988TFKTh5+cSTckSAAJynHA References: <46897CB3.9050609@cisco.com> <7374777208BDC7449D5620EF94232567072B6638@esealmw113.eemea.ericsson.se> <46A51E23.4010304@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 24 Jul 2007 02:23:51.0836 (UTC) FILETIME=[ACEEA5C0:01C7CD99] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi,=20 >>I have a few questions for clarification. >>=20 >>First, how are we going to define each feature? >=20 >We're not. >=20 >>Will we do a "feature definition", or will we (if possible) use existing documentation which=20 >>defines the features? >=20 >Neither. >=20 >>For example, the feature names you have listed all exist as=20 >>supplementary services, with existing service definition. >=20 >Sure. And so? Well, if we are supposed to provide flows on how features are implemented (and then try to create feature groups based on common interop issues), we need to know what the features are supposed to do - and that is normally specified in a feature definition... >The thing we are defining are functional groups. These groups=20 >are defined by a common set of protocol interactions and=20 >mecahnisms amongst elements in the network, which are common.=20 >The abstract and introduction of our specification would give=20 >example features that fit into the category. The precise=20 >definition is not relevant. >=20 >>=20 >>Second, chapter 5.2 says "Participants can also suggest flows they=20 >>think might exist". Does that cover flows that other SDOs have=20 >>produced, e.g. a TISPAN flow for a supplementary service which is=20 >>similar to a specific "feature"? >=20 >Yes, sure. I'd love to see drafts with those proposed. Unless I'm wrong, the 3GPP specifications are available to everyone (3GPP has endorsed most of the TISPAN services), so the flows could maybe be taken from there in that case. Regards, Christer _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 24 10:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLQ2-0004Kg-8C; Tue, 24 Jul 2007 10:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLQ0-0004KV-Ma for bliss@ietf.org; Tue, 24 Jul 2007 10:31:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLPz-0008TC-EL for bliss@ietf.org; Tue, 24 Jul 2007 10:31:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Jul 2007 10:31:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHqqpUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208"; a="126878143:sNHT101939590" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6OEVINN026496; Tue, 24 Jul 2007 10:31:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6OEVHEj008707; Tue, 24 Jul 2007 14:31:18 GMT 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.1830); Tue, 24 Jul 2007 10:31:07 -0400 Received: from [10.86.242.79] ([10.86.242.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:31:07 -0400 Message-ID: <46A60D33.2090208@cisco.com> Date: Tue, 24 Jul 2007 10:31:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> <46A531BB.6000803@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6E76@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437115BB6E76@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 14:31:07.0233 (UTC) FILETIME=[45A7D510:01C7CDFF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8522; t=1185287478; x=1186151478; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20Brian=20Stucker=20; bh=uVT+FZtHSbtxi0Xyj/AtCWTZdDzXtlQfE4hqqOCa4DY=; b=CjTmubQ+v0fRELwNGO1+GlYNhANhst8HRqF2wshPrpouxorwr+UZZ+G41iNB+WFgkm0C2I1L 9rC6mQoLi3G4h1ZNJQKwAjbAwrRC/orE4S5YZCfz3fPQJITCwSHufLiR; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org If the term and concept doesn't actually help us, there may be little point in debating what it is. -Jonathan R. Brian Stucker wrote: > Yeah, probably a little draconian. > > Perhaps we could take single-endedness to mean that there's no state > requirement (outside of basic protocol requirements) on the > non-initiator of the feature. For example, if a feature sends a REFER to > another endpoint, and the feature doesn't require some state to be > created or pre-exist outside of basic REFER processing, that may also > qualify. > > Looking for a good middle ground to essentially describe the case where > one side of the call doesn't have to do anything special outside of > supporting widely implemented protocol primitives (I know, slippery > ground). > > It would essentially mean then whether or not you can manipulate the > non-initiator into taking all of the necessary steps to appear to > understand a particular feature that it does not claim support for. For > example, the non-initiator may not support consultative call transfer, > but it does support REFER. To the initiator of a consultative call > transfer feature that uses only primitives such as REFER, the feature > appears to work even though the non-initiator wasn't doing anything > specific to that feature: it's single-ended. > > This is essentially what I was trying to go for here. > > Regards, > Brian > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Monday, July 23, 2007 5:55 PM >> To: Stucker, Brian (RICH1:AR00) >> Cc: Paul Kyzivat; bliss@ietf.org >> Subject: Re: [BLISS] BLISS problem statement draft >> >> I think this is a good definition for single-ended - that it >> doesn't require other participants to do anything beyond that >> which would be needed for the most basic call setup. >> >> By this definition, almost nothing is single ended.... >> >> -Jonathan R. >> >> Brian Stucker wrote: >>> A few comments inline... >>> >>>> -----Original Message----- >>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>> Sent: Monday, July 23, 2007 4:22 PM >>>> To: Paul Kyzivat >>>> Cc: bliss@ietf.org >>>> Subject: Re: [BLISS] BLISS problem statement draft >>>> >>>> inline. >>>> >>>> Paul Kyzivat wrote: >>>>> I agree with you. >>>>> >>>>> Also, in most cases there is one participant in a feature >>>> that is the >>>>> initiator. That participant knows what feature is being >> invoked. If >>>>> there are multiple ways to do the feature, that participant has >>>>> freedom in which way to do it. It may be constrained to >>>> some extent by >>>>> what functionality the peer had advertised support for. But the >>>>> support it depends on is not for features, but rather only >>>> for various primitives. >>>> >>>> I think we need to be VERY careful here. In all cases, we are >>>> expecting >>>> *something* to be present, in terms of functionality, from the >>>> non-intiators, even in single-ended features. At a minimum, we are >>>> expecting RFC 3261. In many cases, we may be expected support for >>>> something like REFER. If a UA doesn't support receipt of >> REFER, then >>>> the feature doesn't work even if you think its single ended. >>>> >>>> As such, even for single ended features, we will need to state >>>> minimum requirements (i.e., implement REFER) for that >> feature group. >>> I'd argue that the only single-ended features are ones that >> expect the >>> other endpoint to be willing and able to establish a >> session. I don't >>> even think the non-initiator should be required to understand SIP; >>> meaning, that the feature still works with a SIP-to-foo >> gateway (where >>> nothing is known about the workings of the foo protocol) in >> front of >>> the non-initiating endpoint. >>> >>> If you require the non-initiator to do more, then the >> feature is not >>> single-ended. You're requiring some level of cooperation or >>> willingness to be manipulated by the non-initiator in order to make >>> the feature operate. That's what I meant earlier as the >> dividing line >>> between what is single-ended and what is double-ended. >>> >>> Single ended features require no state to be created or transferred >>> between the initiator and the non-initiator of a feature >> beyond what >>> is required to successfully setup the most basic dialog possible >>> because this is the minimum amount of state required to be >> created in >>> the non-initiating client. Everything else is incremental and makes >>> assumptions about the non-initiator's behavior. >>> >>> I don't see how any feature which uses REFER (just to pick >> an example) >>> could ever be single-ended, whereas you can definitely >> implement Call >>> Forwarding as a single-ended feature in which the non-initiator may >>> not even be able to detect that the feature had been invoked. >>> >>> I definitely do agree that stating the minimum requirements for a >>> feature group would be necessary. >>> >>>>> The other participant(s) are more in the way bystanders. >> They don't >>>>> know what feature they are being asked to participate in. >>>> Rather, they >>>>> get some stimulus - typically a request in the context of >>>> some state >>>>> the node has, and then must react to that by doing something. >>>>> >>>>> What's important is that the non-initiating participants >> do what is >>>>> necessary to allow the completion of the service kicked >> off by the >>>>> initiator, even if they would never have initiated the >> service the >>>>> same way if they were the initiator. >>>> Right. >>> By definition, a bystander does not get involved in something. It >>> simply observes what is going on with no requirement to >> take action or >>> even understand what it is observing. If we're requiring the >>> non-initiator to take action upon our requests (stimulus), >> it may not >>> need to know where the initiator is ultimately trying to do >> (i.e. the >>> feature) but it must be willing to 'play-along'. >>> >>>>> Of course is isn't really that simple. The non-initiating >>>> participants >>>>> may still have some discretion in initiating the next step in a >>>>> complex sequence. >>>> If the feature requires the non-initiating participants to do >>>> something that is specific to this feature, it is by >> definition, not >>>> single-ended. >>> Again, I would argue that if they require the non-initiating >>> participants to do something that is beyond basic dialog >>> establishment, then it is not single-ended. >>> >>>>> So I think the key things we need to do are: >>>>> - ensure that different features don't result in an identical >>>>> stimulus to some participant while requiring that participant >>>>> to take a different action for each feature. (Since it doesn't >>>>> know what feature it is doing.) >>>> Right. We need to look very carefully about what >> expectations we have >>>> for non-participants. Even for something like receipt of >> REFER, you >>>> need to make sure that the UA has what it needs to authorize the >>>> request. >>> Agree. >>> >>>> -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 >>>> >>>> _______________________________________________ >>>> BLISS mailing list >>>> BLISS@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/bliss >>>> >> -- >> 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 >> > -- 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 24 10:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLSO-0006lK-7p; Tue, 24 Jul 2007 10:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLSM-0006lB-VF for bliss@ietf.org; Tue, 24 Jul 2007 10:33:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLSM-0008WQ-Jg for bliss@ietf.org; Tue, 24 Jul 2007 10:33:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2007 10:33:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO6qpUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208"; a="66001427:sNHT27764998" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6OEXkWq027785; Tue, 24 Jul 2007 10:33:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6OES5WK009282; Tue, 24 Jul 2007 14:33:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:33:36 -0400 Received: from [10.86.242.79] ([10.86.242.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:33:36 -0400 Message-ID: <46A60DC8.5040803@cisco.com> Date: Tue, 24 Jul 2007 10:33:44 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D02057D4@GBNTHT12009MSX.gb002.siemens.net> <46A51D90.6040708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0205EA3@GBNTHT12009MSX.gb002.siemens.net> <46A533BB.3020504@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0205EA5@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0205EA5@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 14:33:36.0509 (UTC) FILETIME=[9EA18AD0:01C7CDFF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1811; t=1185287626; x=1186151626; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20BLISS=20problem=20statement=20draft |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=4DaN81y1fW2eKuhdbzCAobI3gIRYamSoy5s3EXDTYg4=; b=lZYoy/EgMT979oWdYr17uNOU2FgzvYo593LfcqzvoYUtDlbbR4fHcfOF0vw0saGxjwJHoqIC YBq9cdETZx9bThDeIUSuzouOXoxwnBDj0putHIo7zksZRzs1D3BIIqNK; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think this is presuming that the UA 'invokes' DND by receiving the request and then responds, and then the proxy takes some action on the response. What you are saying is, we need a standard way to signal invocation of DND from a UA to a proxy that is executing it. To that, I agree. However, there are many ways to implement this, and its not obvious that the way you describe (using a response code from UA to proxy) is the right one. This is why I've felt that an important part of the BLISS process is to ENUMERATE the different ways people have realized this, find where things break, and determine what it is we do need to standardize. Thanks, Jonathan R. Elwell, John wrote: > Jonathan, > >>> [JRE] The ability to indicate a DND condition as a reason for call >>> rejection is not a protocol procedure that is required by call >>> forwarding features. >> per above, what is the interoperability failure you are >> concerned about >> if the element implementing DND uses a response code of its choice? > [JRE] If a UAS sends one response code and a proxy programmed to forward > on DND expects a different response code, this will result in failure. I > agree that the response code the UAC receives is unimportant from an > interoperability point of view (but might still be important for > conveying appropriate information to the caller - similar motivation to > that for extending RPID to indicate DND explicitly). > > John > -- 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 24 10:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLie-0002W0-PB; Tue, 24 Jul 2007 10:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLid-0002VY-CN for bliss@ietf.org; Tue, 24 Jul 2007 10:50:35 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDLic-0003uL-CT for bliss@ietf.org; Tue, 24 Jul 2007 10:50:35 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6OEoUb07064; Tue, 24 Jul 2007 14:50:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] BLISS problem statement draft Date: Tue, 24 Jul 2007 09:49:23 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115BB74FD@zrc2hxm2.corp.nortel.com> In-Reply-To: <46A60D33.2090208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] BLISS problem statement draft Thread-Index: AcfN/1KnQkhhg0fTS4iPjbLNU+ohMAAAn5yA References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> <46A531BB.6000803@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6E76@zrc2hxm2.corp.nortel.com> <46A60D33.2090208@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think it does help us, because the interop interactions of a single-ended feature are much simpler to deal with as opposed to something that is double-ended. I wouldn't say that I'm debating what it is so much as trying to find a balance between making it useful and not expecting too much of the various implementations. Regards, Brian =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, July 24, 2007 9:31 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Paul Kyzivat; bliss@ietf.org > Subject: Re: [BLISS] BLISS problem statement draft >=20 > If the term and concept doesn't actually help us, there may=20 > be little point in debating what it is. >=20 > -Jonathan R. >=20 > Brian Stucker wrote: > > Yeah, probably a little draconian. > >=20 > > Perhaps we could take single-endedness to mean that there's=20 > no state=20 > > requirement (outside of basic protocol requirements) on the=20 > > non-initiator of the feature. For example, if a feature=20 > sends a REFER=20 > > to another endpoint, and the feature doesn't require some=20 > state to be=20 > > created or pre-exist outside of basic REFER processing,=20 > that may also=20 > > qualify. > >=20 > > Looking for a good middle ground to essentially describe the case=20 > > where one side of the call doesn't have to do anything=20 > special outside=20 > > of supporting widely implemented protocol primitives (I=20 > know, slippery=20 > > ground). > >=20 > > It would essentially mean then whether or not you can=20 > manipulate the=20 > > non-initiator into taking all of the necessary steps to appear to=20 > > understand a particular feature that it does not claim support for.=20 > > For example, the non-initiator may not support consultative call=20 > > transfer, but it does support REFER. To the initiator of a=20 > > consultative call transfer feature that uses only=20 > primitives such as=20 > > REFER, the feature appears to work even though the non-initiator=20 > > wasn't doing anything specific to that feature: it's single-ended. > >=20 > > This is essentially what I was trying to go for here. > >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Monday, July 23, 2007 5:55 PM > >> To: Stucker, Brian (RICH1:AR00) > >> Cc: Paul Kyzivat; bliss@ietf.org > >> Subject: Re: [BLISS] BLISS problem statement draft > >> > >> I think this is a good definition for single-ended - that=20 > it doesn't=20 > >> require other participants to do anything beyond that=20 > which would be=20 > >> needed for the most basic call setup. > >> > >> By this definition, almost nothing is single ended.... > >> > >> -Jonathan R. > >> > >> Brian Stucker wrote: > >>> A few comments inline...=20 > >>> > >>>> -----Original Message----- > >>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>>> Sent: Monday, July 23, 2007 4:22 PM > >>>> To: Paul Kyzivat > >>>> Cc: bliss@ietf.org > >>>> Subject: Re: [BLISS] BLISS problem statement draft > >>>> > >>>> inline. > >>>> > >>>> Paul Kyzivat wrote: > >>>>> I agree with you. > >>>>> > >>>>> Also, in most cases there is one participant in a feature > >>>> that is the > >>>>> initiator. That participant knows what feature is being > >> invoked. If > >>>>> there are multiple ways to do the feature, that participant has=20 > >>>>> freedom in which way to do it. It may be constrained to > >>>> some extent by > >>>>> what functionality the peer had advertised support for. But the=20 > >>>>> support it depends on is not for features, but rather only > >>>> for various primitives. > >>>> > >>>> I think we need to be VERY careful here. In all cases, we are=20 > >>>> expecting > >>>> *something* to be present, in terms of functionality, from the=20 > >>>> non-intiators, even in single-ended features. At a=20 > minimum, we are=20 > >>>> expecting RFC 3261. In many cases, we may be expected=20 > support for=20 > >>>> something like REFER. If a UA doesn't support receipt of > >> REFER, then > >>>> the feature doesn't work even if you think its single ended. > >>>> > >>>> As such, even for single ended features, we will need to state=20 > >>>> minimum requirements (i.e., implement REFER) for that > >> feature group. > >>> I'd argue that the only single-ended features are ones that > >> expect the > >>> other endpoint to be willing and able to establish a > >> session. I don't > >>> even think the non-initiator should be required to=20 > understand SIP;=20 > >>> meaning, that the feature still works with a SIP-to-foo > >> gateway (where > >>> nothing is known about the workings of the foo protocol) in > >> front of > >>> the non-initiating endpoint. > >>> > >>> If you require the non-initiator to do more, then the > >> feature is not > >>> single-ended. You're requiring some level of cooperation or=20 > >>> willingness to be manipulated by the non-initiator in=20 > order to make=20 > >>> the feature operate. That's what I meant earlier as the > >> dividing line > >>> between what is single-ended and what is double-ended. > >>> > >>> Single ended features require no state to be created or=20 > transferred=20 > >>> between the initiator and the non-initiator of a feature > >> beyond what > >>> is required to successfully setup the most basic dialog possible=20 > >>> because this is the minimum amount of state required to be > >> created in > >>> the non-initiating client. Everything else is incremental=20 > and makes=20 > >>> assumptions about the non-initiator's behavior. > >>> > >>> I don't see how any feature which uses REFER (just to pick > >> an example) > >>> could ever be single-ended, whereas you can definitely > >> implement Call > >>> Forwarding as a single-ended feature in which the=20 > non-initiator may=20 > >>> not even be able to detect that the feature had been invoked. > >>> > >>> I definitely do agree that stating the minimum requirements for a=20 > >>> feature group would be necessary. > >>> > >>>>> The other participant(s) are more in the way bystanders.=20 > >> They don't > >>>>> know what feature they are being asked to participate in. > >>>> Rather, they > >>>>> get some stimulus - typically a request in the context of > >>>> some state > >>>>> the node has, and then must react to that by doing something. > >>>>> > >>>>> What's important is that the non-initiating participants > >> do what is > >>>>> necessary to allow the completion of the service kicked > >> off by the > >>>>> initiator, even if they would never have initiated the > >> service the > >>>>> same way if they were the initiator. > >>>> Right. > >>> By definition, a bystander does not get involved in something. It=20 > >>> simply observes what is going on with no requirement to > >> take action or > >>> even understand what it is observing. If we're requiring the=20 > >>> non-initiator to take action upon our requests (stimulus), > >> it may not > >>> need to know where the initiator is ultimately trying to do > >> (i.e. the > >>> feature) but it must be willing to 'play-along'. > >>> > >>>>> Of course is isn't really that simple. The non-initiating > >>>> participants > >>>>> may still have some discretion in initiating the next step in a=20 > >>>>> complex sequence. > >>>> If the feature requires the non-initiating participants to do=20 > >>>> something that is specific to this feature, it is by > >> definition, not > >>>> single-ended. > >>> Again, I would argue that if they require the non-initiating=20 > >>> participants to do something that is beyond basic dialog=20 > >>> establishment, then it is not single-ended. > >>> > >>>>> So I think the key things we need to do are: > >>>>> - ensure that different features don't result in an identical > >>>>> stimulus to some participant while requiring that participant > >>>>> to take a different action for each feature. (Since it doesn't > >>>>> know what feature it is doing.) > >>>> Right. We need to look very carefully about what > >> expectations we have > >>>> for non-participants. Even for something like receipt of > >> REFER, you > >>>> need to make sure that the UA has what it needs to authorize the=20 > >>>> request. > >>> Agree. > >>> > >>>> -Jonathan R. > >>>> --=20 > >>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>>> Cisco Fellow Parsippany, NJ=20 > >>>> 07054-2711 > >>>> Cisco Systems > >>>> jdrosen@cisco.com FAX: =20 > >> (973) 952-5050 > >>>> http://www.jdrosen.net PHONE:=20 > >> (973) 952-5000 > >>>> http://www.cisco.com > >>>> > >>>> _______________________________________________ > >>>> BLISS mailing list > >>>> BLISS@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/bliss > >>>> > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ=20 > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 24 16:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQZU-00036w-L9; Tue, 24 Jul 2007 16:01:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQZU-00036r-6g for bliss@ietf.org; Tue, 24 Jul 2007 16:01:28 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQZT-0005PY-K2 for bliss@ietf.org; Tue, 24 Jul 2007 16:01:28 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6OK1NsS030230 for ; Tue, 24 Jul 2007 13:01:23 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6OK1MO8032080 for ; Tue, 24 Jul 2007 13:01:22 -0700 Received: from 172.24.28.153 ([172.24.28.153]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jul 2007 20:01:21 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 24 Jul 2007 15:01:19 -0500 From: Eric Burger To: Message-ID: Thread-Topic: Comments on Call Completion Thread-Index: AcfOLWZjpQASiDogEdysnQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [BLISS] Comments on Call Completion X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org The automatic addition of a caller to a queue by virtue of having called once is a huge DDoS opportunity. This is worse than just the normal SPIT DDoS opportunity, where lots of UAC's can attack a UAS by calling lots of time. That is because the effort on the UAC is similar to the effort on the UAS. However, with this proposal, the UAS has to temporarily keep state for every call it gets. Worse yet, once there is a subscription, the UAS has to keep that state for the length of the subscription. First suggestion: there has to be some relatively short default subscription state and recommendations to implementers to have the UAS enforce the short subscription time. Temporarily turning off notifications while remaining on the queue has a ton of issues, too. That means that one has no mechanism for canceling the queue request. While it looks elegant to say that if the UAC does not need to make the call attempt, it can just ignore the "it is OK to call now" message. However, that is wasteful of UAS resources. Even if the UAC cancels its subscription, the UAS still has to carry the state and go through the motions of calculating (1) it is time to send a notification and (2) to suppress that notification. Likewise, if the UAC unsubscribes, then the call attempt trigger occurs, and the UAC later resubscribes, because the user is ready to call, what happens? One option is to either put the caller back into queue or put them at the top of the queue. Either way, the UAS needs to keep state forever. That is not a scalable option. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jul 24 17:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRvJ-0008PX-14; Tue, 24 Jul 2007 17:28:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRvI-0008PD-BK for bliss@ietf.org; Tue, 24 Jul 2007 17:28:04 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRvH-0007E8-Rr for bliss@ietf.org; Tue, 24 Jul 2007 17:28:04 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070724212802m1200fmvmje>; Tue, 24 Jul 2007 21:28:02 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OLS18t011937 for ; Tue, 24 Jul 2007 17:28:01 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OLS1xP011933; Tue, 24 Jul 2007 17:28:01 -0400 Date: Tue, 24 Jul 2007 17:28:01 -0400 Message-Id: <200707242128.l6OLS1xP011933@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A531BB.6000803@cisco.com> (jdrosen@cisco.com) Subject: Re: [BLISS] BLISS problem statement draft References: <46897CB3.9050609@cisco.com> <4692B40B.6070609@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115744A29@zrc2hxm2.corp.nortel.com> <46937ACD.2080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115745096@zrc2hxm2.corp.nortel.com> <4693DAFB.8010900@cisco.com> <469EA2C3.60400@ntt-at.com> <469EBEF9.6050207@cisco.com> <46A51C12.5050703@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437115BB6D12@zrc2hxm2.corp.nortel.com> <46A531BB.6000803@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Jonathan Rosenberg I think this is a good definition for single-ended - that it doesn't require other participants to do anything beyond that which would be needed for the most basic call setup. By this definition, almost nothing is single ended.... I think that should be "the other end of the dialog" rather than "other participants". Under that definition, any feature provided on behalf of the UA by a proxy that has an ongoing relationship with the UA is "single-ended". There aren't many of those now (in plain SIP), but there are likely to be more in the future. Consider DND processing performed by "the proxy" on behalf of the UA. And there really is value is standardizing the interaction between the UA and the supporting proxy for single-ended features. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jul 25 12:33:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjo7-0003AB-UY; Wed, 25 Jul 2007 12:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjo5-0002yk-Sg for bliss@ietf.org; Wed, 25 Jul 2007 12:33:49 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjo4-0004NA-Fw for bliss@ietf.org; Wed, 25 Jul 2007 12:33:49 -0400 Received: from [130.129.16.145] (dhcp-1091.ietf69.org [130.129.16.145]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6PGXhW1025334 for ; Wed, 25 Jul 2007 10:33:43 -0600 Message-ID: <46A77B5D.8020202@ntt-at.com> Date: Wed, 25 Jul 2007 09:33:33 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Subject: [BLISS] Draft minutes, BLISS IETF 69 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org IETF 69 - BLISS Work Group Date: July 24, 2007 Note Taker: Eric Burger Bliss Problem Statement: JDR---------------------------- Add to problem statement: do not need to define the distinction between Application, Service, and Feature. Do not focus on whether something is just a service or a feature, rather just talk about how "it" works. AI for JDR: try to use traces from SIPiT to extract call flows. Do we need guidelines for how BLISS will work: YES Do we take JDR's document as basis for problem statement: YES Find a milestone to run the complete process on. Automated Handling: DND by John Elwell---------------------------- Is this separable from other DND features? No, part of the whole DND feature set. Could be separable after analysis of all features of interest. Call Completion by Martin Huelsemann---------------------------- Open Issue: prioritization: can we do prioritization by comparing caller identity with top-most queue entry? Open Issue: What if no call completion attempt started after free? Open Issue: What if call completion attempt results in busy? Open Issue: what to do if there is an error, like no queue entry at time of subscription? Open Issue: what if lots of user devices subscribe to the same queue entry? Paul procedures - new solution; what about interoperating with what's out there? Is text on dialog package sufficient? Should directly reference queuing directly. Multiple Line Appearances by Alan Johnston---------------------------- How large is large, with respect to multiple lines? 5-10? Why not use NOTIFY, since one is sending NOTIFY's anyway? One issue is that the phone needs to ring / flash / indicate a call is coming. Is that not an INVITE issue? How to indicate the line identifier? How about a separate AOR for the aggregate group? Two-level registrations (or implicit two-level), where the lines are sub-addresses of the device. Note Taker: Brian Rosen List of acronyms used for names in this note jdr presents Bliss Problem Statement Solution Considerations: Avoid Enumeration Allow variability of definitions Assume multimedia Allow variability of Implementation in a multiplicity of environments MD-Is this just SIP or also including e.g. web services. There are services invoked using sip, and others invoked with a GUI, what is in scope JDR-some mechanisms may need, e.g. configuration and may need other protocols to achieve interopeability Bliss Process: 1. Define functional primatives - a bucket with similar flows SN-What do you mean by feature, service JDR-Don't try to parse too finely, just agree on what the thing is we need to interoperate CH-okay, but need to describe differences between the feature and the service JDR-Don't think its a problem JE-We called them features before we invented services Indentify common interaction patterns Bliss Process: 2. submit feature flows Get a lot of them from different implementations Not a deliverable. MD-Like the idea of flows, but not the detail diagrams in ASCII JDR-Okay, lets not get process in the way Bliss Process: 3. problem determination, minimum interop definition Analyze what happens when elements from different implementations get plugged together SN-Lets not apportion blame JDR-Anonymous call flows okay :) ??-There is a confidentiality issues to be worked out in some NDA environment JDR-IETF can't deal with that PB-Any way to do data mining from SIPit? JDR-Good idea CH-Feature names can confuse us JDR-Thats part of the problem we are solving. Decide if they are in the bucket Bliss Process: 4. Interop Spec Actual Deliverable TD-Carriers may be able to help JDR-Great AA-Capabilities negotiation in scope? JDR-Case by case discussion AA-Are provisioning mechanisms in scope JDR-Only as a mention of how to achieve interoperability. Example of DND. BS-Do we assume things meet specs first, or is protocol repair in scope JDR-Hmmm, well spec misinterpretation could be fixed, need to ferret out assumptions etc to find the BS-Problem is eating cost to fix implementation. If we assume correct interpretation, many problems may go away. JDR-don't want to figure out the line ahead of time. Generally agree MS-Great doc. worried about negotiation of capabilities conflict between innovation and simplicity JDR-Agree. Have to make the tradeoff on case by case basis AA-Don't want to have PSTN does it this way spear PB-Don't want only RFCs on the one rightway. Wants a dont do it this way doc JDR-propose a summary of experience in doc JS-How do we separate scope issues with sip/sipping JDR-on a case by case basis HK-Are SBCs in scope? JDR-Yes AA -People don't want their flows to appear in Worst Current Practice JD-Yeah SD-Lots of problems with values rather than message flows JDR-In scope CH-Only sip to sip or interactions with PSTN in scope JDR-What happens on PSTN side doesn't matter but SIP side in scope AE-How are we organizing this JDR-Maybe a "pilot program" JDR-Is this really the process we want to do? Ask for humm MD-Question: What layer of detail? JDR-Only as much as we have to to get interoperability. Maybe a minimum implementation plus a capability discovery for more features CH-Are you asking that other drafts already submitted that don't follow this process have to be redone? Chairs: Yeah, documents will have to be respun JE-Good way forward. Must be fine tuned for each group of features DS-Interpretation of response codes in scope JDR-If it causes interoperability problems in the functional groups it is in scope CH-Does this mean define new codes? JDR-Good point. If things are missing, write requirements for sip, final draft references sip mechanisms draft KD-That is the charter defined process Chairs: Humm on this approach Consensus: yes Humm on using this draft as the basis for this work Consensus: ?? See hands, Consensus yes Chairs: Propose to take one bucket and run through the process for a milestone with a design team AA-By a milestone, do you mean pick a feature CH-One feature or one feature group Chairs: Feature Group MD-Process okay, do you have a sense of the buckets? JDR-In the charter John Elwell presents DND draft DND, CFU, CFNA in same bucket Indicatin DND to a proxy Need explicit indication, reason phrase not sufficient Lots of ways people do this now Maybe a new 4xx or 6xx Scope of 6xx Forking and retargeting issues Does it apply to contacts? Indicating DND to a caller Are they different for indicating DND to a proxy May wish to hide this from caller Reason Phrase has issues Is it sufficient to rely on proxy HERFP problem Indicating DND in presence Need something in RPID? Would this be something in "open"? DND problems that don't need solving Do we need SIP means for setting/clearing DND? Do we need SIP means for overriding DND Is 4412 (RPH) enough? Similarity between DND and other automated handling Differences between DND and other automated handling MD-Is proxy as well as UA work in scope for this JE-Yes MD-Feature line interaction issues, may be regulatory mandate, is that in scope? JE-Explain MD-May be an ovveride required by regulation, is that in scope JE-Have to look at that CH-Need a feature definition first. Is this draft in line with the process define before? JE-No, need to do that. Draft as is doesn't define DND PK-I draw opposite conclusion on related features, they are very related JDR-Feature interaction is generally NOT in charter, but may have to note interactions in resolutions Agree with Paul that these are very related, there is state. If the state is in the endpoint, need a way to signal the proxy to do things. If the state lives in the proxy, then we need signaling to change the state in the proxy. JE-Doc doesn't say one way or another JDR-Great example of what we are doing, doc describes one way, I thought it worked another way JE-Doc describes both SN-Need to look at requirements from user perspective, this does look like other features in the bucket also has feature inteactions within the bucket JE-Seems like we should combine with automated handling JDR-For now yes, but just "consider" that, no final decision ??-Sometimes one part of call flow from one feature is a part of another feature. Look for common flow parts and tie together JE-not sure that is the intention of the process we just agreed AA-Common elements (indicating primative) here. Maybe there are building blocks that could be useful that may also help the non-disclosure problem JE-Yes but you can't slice fragments too small or you lose meaning AA-Building blocks may be here and be useful JE-SIP defines building blocks, we don't want to redefine them Chairs: Out of time JDR-Don't worry about buckets now: put it in now, decide later if it comes out Poetzl on Call Completion Was a sipping draft, now moved to BLISS Compares different solutions, has not looked into interop issues yet Queueing method has changed Event headers not used, done implicitly by creating queue entry Call completion prioritization has changed, new p-header not used Issue: can prioritization be implicit by comparing calller identity with queue entry on top? Changed Queue model: entry created when busy or no reply deleted after timer expiry or call completion attempted Several open issues Next Steps: resolve open issues, revision to align with problem statement draft pk-Stressing the process already, this describes a new procedure without investigating what is done already. Given history, I'm pretty happy with how it addresses the requirements Fundamentally a caller requirement, if the mechanism is there, that's swell. If the caller was in a place where the mechanism isn't there? Phone should have a bag of tricks. Anything better that forcing the user to redial JG-Naive, but why not use 192/408? FA-Section talks about alternatives, using floor control and dialog package. Don't like the dialog package suggestion in the draft. If not really needed, delete. I think a dialog package solution is actually useful. JDR-Think this fits the model. Proprietary piece missing. Maybe we could define at least requirements Possibly a new event package. Using dialog package is a great alternative, but not interoperable. Need the process to show all the possibilities, tradeoffs and solution. An example of lack of standards EB-Focussing on solutions like this open up to big DoS attack. Is this a good idea? JDR-Got to evaluate it in that light. Alan Johnson On Multiple Appearances AKA Bridged Line, Shared Call Appearance, ,,, Avoids using "Line" Group of UAs that can handle incoming lines. Outgoing calls assigned to a unique "appearance" number from a managed pool Bunch of Requirements List Discussion: How large can the group be, Ability to make exceptins (e.g. emergency call). Privacy of Contact URIs FA-How would Notify (if N is large) work? AJ-REFER/Replaces AA-Order of 5-10 gets to be a problem CH-This is one of many ways, need to look at other ways. Now you want to look at requirements? Not the process GD-Notify is a better way all. Need to show lamp status anyway. Requirements Analysis: Forking Proxy/Registrar meets R1 Dialog Pkg meets R2 Replaces/Join meets R3 Registration Pkg meets R4 State Agent for Dialog Pkg meets R5,R6 suggests an "Appearance Agent" which subscribes to the dialog package AA-Always assume single user agent with separate registration for each line? AJ-Doesn't have to be that way Implementation options URI Parameter in e.g. contact (line=) Dialog Package Parameter - needs additional mechanism for incoming calls possibly alert-info FA-Third option, AoR for the group, register with that, subscribe to that, ... May also need a group regsitration, but sometimes not Comparisons: Dialog package meets many, URI parameter not as many Appearance Contention Resolution: 2 UAs use the same appearance number, Could use Publish vs Notifiy JDR = Jonathan Rosenberg SN = Steve Norrys CH = Christer Holmberg AA = Andrew Allen JE = John Elway PB = Peter Blatherwick TD = Tim Dwight BS = Brian Stucker MS = Maureen Stillman HK =Hadriel Kaplan SD=Spencer Dawkins PK=Paul Kyzviat JG=Janet Gunn EB=Eric Berger FA=Francois Audet GD=Geoff Devine _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jul 30 08:46:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUdP-0006bA-CO; Mon, 30 Jul 2007 08:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IED5f-0004QD-UZ; Thu, 26 Jul 2007 19:49:55 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IED5f-0003bZ-Gu; Thu, 26 Jul 2007 19:49:55 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 6B50426E65; Thu, 26 Jul 2007 23:49:55 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IED5f-00064J-BB; Thu, 26 Jul 2007 19:49:55 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Jul 2007 19:49:55 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Mon, 30 Jul 2007 08:46:02 -0400 Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-problem-statement-00.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement Author(s) : J. Rosenberg Filename : draft-ietf-bliss-problem-statement-00.txt Pages : 19 Date : 2007-07-26 The Session Initiation Protocol (SIP) has been designed as a general purpose protocol for establishing and managing multimedia sessions. It provides many core functions and extensions in support of features such as transferring of calls, parking calls, and so on. However, interoperability of more advanced features between different vendors has been poor. This document describes the reason behind these interoperability problems, and presents a framework for addressing them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-problem-statement-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bliss-problem-statement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bliss-problem-statement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-26194519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bliss-problem-statement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bliss-problem-statement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-26194519.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --NextPart--