From bliss-bounces@ietf.org Mon Apr 02 16:34:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTEh-0003vH-Te; Mon, 02 Apr 2007 16:34:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTEg-0003uz-PD for bliss@ietf.org; Mon, 02 Apr 2007 16:34:42 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTEf-0001PV-Em for bliss@ietf.org; Mon, 02 Apr 2007 16:34:42 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070402203440m1400iqsm4e>; Mon, 2 Apr 2007 20:34:40 +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 l32KYdLv011879 for ; Mon, 2 Apr 2007 16:34:39 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l32KYcEZ011870; Mon, 2 Apr 2007 16:34:38 -0400 Date: Mon, 2 Apr 2007 16:34:38 -0400 Message-Id: <200704022034.l32KYcEZ011870@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <50B1CBA96870A34799A506B2313F26670B5BAF44@ntht201e.siemenscomms.co.uk> (john.elwell@siemens.com) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [BLISS] Some 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 * The passage: group telephony feature commonly known as Bridged Line Appearance should be: group >of< telephony feature>s< commonly known as Bridged Line Appearance I've also seen the term "Shared Call Status" used. * Given this: When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances. why is the I-D titled "Multiple Line Appearance Feature" rather than "Multiple Appearances Feature"? * The introduction reads: This specification details a method for implementing a group telephony feature known in telephony as Bridged Line Appearance (BLA) or Multiple Line Appearance, [...] Different approaches will be discussed including [...] Which does this document do, present one method or present several methods? I expect that it focuses on one approach which can be implemented in several ways. If so, the I-D needs to clearly specify the overall approach and distinguish it from the individual methods. * REQ-2 REQ-2 Each UA in the group must be able to learn the call status of the others in the group for the purpose of rendering this information to the user. Though in a traditional "key system", a UA only knows the status of each line appearance as available/ringing/in-use, and not the status of other UAs per se. * REQ-5 REQ-5 The mechanism must scale for large numbers of appearances, n, and large numbers of UAs, N, without introducing excessive messaging traffic. Better give some idea of how large "large" is. In the computer science world, people can consider "large" to start at 1,000,000. Perhaps you want to say that message traffic scales linearly with the number of appearances. * REQ-11 REQ-11 The mechanism must have backwards compatibility such that a UA which is unaware of the feature can still register against the group AOR and make and receive calls. And it should cause only minimal disruption to the MLA UAs. Specifically, it is permitted that calls that it generates/answers are not visible or managable by the MLA mechanism, but they must not interfere with MLA operation for other calls. * REQ-12 REQ-12 The mechanism must not allow UAs outside the group to select or manipulate appearance numbers. Particularly, you don't want the UA generating a call to the AOR to be able to select the appearance number. * REQ-15 REQ-13 For privacy reasons, there must be a mechanism so that appearance information is not leaked outside the group of UAs. (e.g. "So who do you have on line 1?") Are the privacy requirements for MLA any more strict than the ordinary privacy considerations for the dialog event package? * draft-anil-sipping-bla-04 How does this I-D relate to draft-anil-sipping-bla-04.txt? Is this I-D fundamentally a discussion of variations on that I-D? * Section 5.1 This section discusses and compares multiple methods of implementing, conveying, and selecting appearances in SIP while meeting the requirements of Section 4. These approaches are a URI parameter and a SIP dialog package extension parameter. All the approaches here assume the common elements and operations of Figure 1. This is awkwardly phrased, given that you have only two alternatives. The phrasing would be more appropriate if there were a large number of alternatives. This section discusses and compares two methods of implementing, conveying, and selecting appearances in SIP while meeting the requirements of Section 4. One approach involves a URI parameter and is discussed in section 5.1.1. The other approach uses a SIP dialog package extension parameter and is discussed in section 5.1.2. Both approaches assume the common elements and operations of Figure 1. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Apr 02 16:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTFQ-0004Ln-5O; Mon, 02 Apr 2007 16:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTFP-0004KA-1x for bliss@ietf.org; Mon, 02 Apr 2007 16:35:27 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTFF-0002AQ-Mv for bliss@ietf.org; Mon, 02 Apr 2007 16:35:27 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070402203517b1400nnqkre>; Mon, 2 Apr 2007 20:35:17 +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 l32KZGLv011931 for ; Mon, 2 Apr 2007 16:35:16 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l32KZGg1011927; Mon, 2 Apr 2007 16:35:16 -0400 Date: Mon, 2 Apr 2007 16:35:16 -0400 Message-Id: <200704022035.l32KZGg1011927@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <50B1CBA96870A34799A506B2313F26670B5BAF44@ntht201e.siemenscomms.co.uk> (john.elwell@siemens.com) Subject: Re: [BLISS] Fwd: I-D ACTION:draft-johnston-bliss-mla-req-00.txt References: <50B1CBA96870A34799A506B2313F26670B5BAF44@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: "Elwell, John" > Well, we have discussed an alternative model in which instead of the > INVITE being forked to all N endpoints, the endpoints first > get a NOTIFY > from the Appearance Agent. If a UA wants to answer the call, > it sends > some kind of indication to the Appearance Agent which then causes the > INVITE to get sent to the endpoint. Now, this is a major > change to the > way UAs answer calls, but it might help reduce ICE and media > path keying > messaging. [JRE] You say you discussed this, but what was your reason for rejecting it? And why is that reason not documented in the I-D? Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Apr 02 16:40: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 1HYTJv-0000V8-Hc; Mon, 02 Apr 2007 16:40:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTJt-0000Oe-NT for bliss@ietf.org; Mon, 02 Apr 2007 16:40:05 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYTJq-0007gM-C7 for bliss@ietf.org; Mon, 02 Apr 2007 16:40:05 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070402203958m11005idube>; Mon, 2 Apr 2007 20:39:59 +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 l32KdwLv012293 for ; Mon, 2 Apr 2007 16:39:58 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l32KdwSa012289; Mon, 2 Apr 2007 16:39:58 -0400 Date: Mon, 2 Apr 2007 16:39:58 -0400 Message-Id: <200704022039.l32KdwSa012289@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <402F25FC1EB2BD44831F8A4A4F6DF9420185E692@MAIL02.cedarpointcom.com> (gdevine@cedarpointcom.com) Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt References: <402F25FC1EB2BD44831F8A4A4F6DF9420185E692@MAIL02.cedarpointcom.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: "Geoff Devine" In PSTN-land key system emulation, an E.164 number is 1-to-1 with a line appearance button on a station. It's a little stranger than that, though. In the machinery, each line appearance button corresponds to one DN. But as users think about it, often one DN will hunt to a series of other DNs, and they will think of the buttons for all of those DNs as repetitions of the primary DN. I think the latter model is what this I-D (and anil-bla) are trying to implement, where a DN has multiple "sub-lines", each of which is assigned to a separate button, but which (other than by UAs with appearances for that DN) are not individually addressible. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Apr 02 16:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTP5-0006NU-2F; Mon, 02 Apr 2007 16:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTP3-0006NJ-Ty for bliss@ietf.org; Mon, 02 Apr 2007 16:45:25 -0400 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTP2-000420-O8 for bliss@ietf.org; Mon, 02 Apr 2007 16:45:25 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <20070402204524015008m982e>; Mon, 2 Apr 2007 20:45: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 l32KjNLv012724 for ; Mon, 2 Apr 2007 16:45:23 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l32KjNk8012720; Mon, 2 Apr 2007 16:45:23 -0400 Date: Mon, 2 Apr 2007 16:45:23 -0400 Message-Id: <200704022045.l32KjNk8012720@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is large? 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 One aspect of this problem that may need to be addressed is whether an incoming call is expected to be presented on all appearances of the DN. For a key system, people expect that. But a key system usually has less than a dozen stations. If we expect a DN to appear on more than 10 UAs, various scaling problems show up. E.g., consider the hospital system that Geoff Devine described with 192 appearances of each of 16 lines. If an incoming call rings on all 192 appearances, the calling UA will see 192 early dialogs! OTOH, if we want to restrict the number of forks of an incoming call, how is the proxy to decide which UAs should see that call? Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Apr 02 16:50: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 1HYTU2-0007Mk-Mk; Mon, 02 Apr 2007 16:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTU2-0007Mf-5M for bliss@ietf.org; Mon, 02 Apr 2007 16:50:34 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTU0-000585-UR for bliss@ietf.org; Mon, 02 Apr 2007 16:50:34 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070402205032b12008jf1fe>; Mon, 2 Apr 2007 20:50:32 +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 l32KoVLv013086 for ; Mon, 2 Apr 2007 16:50:31 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l32KoVDo013082; Mon, 2 Apr 2007 16:50:31 -0400 Date: Mon, 2 Apr 2007 16:50:31 -0400 Message-Id: <200704022050.l32KoVDo013082@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <50B1CBA96870A34799A506B2313F26670B4F5D99@ntht201e.siemenscomms.co.uk> (john.elwell@siemens.com) Subject: Re: [BLISS] Fwd: I-D ACTION:draft-johnston-bliss-mla-req-00.txt References: <50B1CBA96870A34799A506B2313F26670B4F5D99@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: "Elwell, John" "REQ-5 The mechanism must scale for large numbers of appearances, n, and large numbers of UAs, N, without introducing excessive messaging traffic." One consequence of a large N is, depending on solution, the establishment of N early dialogs towards the UAC and N parallel ICE procedures, N parallel key management procedures, etc.. This might not be important for values of N of the order of 3-5, but with much larger values of N this could certainly be a problem. I assume this requirement is intended to cover this and to include messages in general (such as STUN and whatever in-band key management is used) as well as SIP messaging. And this is trickier than it first appears. From a theoretical point of view, the best that one could hope for is that the messaging scales linearly with the number of appearances of the AOR. And it seems that we can achieve this without a problem. But in practice, even scaling linearly is difficult to support, as the calling UA is likely to have a small and fixed capacity for the number of early dialogs it can negotiate at one time. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Apr 02 17: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 1HYTeS-0002vs-Oi; Mon, 02 Apr 2007 17:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTeQ-0002j7-RY for bliss@ietf.org; Mon, 02 Apr 2007 17:01:18 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTeO-0007xU-IM for bliss@ietf.org; Mon, 02 Apr 2007 17:01:18 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 4652A2005B; Mon, 2 Apr 2007 17:01:16 -0400 (EDT) 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 08133-02-9; Mon, 2 Apr 2007 17:01:14 -0400 (EDT) Received: from LT4GKCG41 (unknown [10.31.8.118]) by smtp.mitel.com (Postfix) with SMTP id CF64920023; Mon, 2 Apr 2007 17:01:12 -0400 (EDT) From: "Jerry Yin" To: , Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is large? Date: Mon, 2 Apr 2007 17:01:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200704022045.l32KjNk8012720@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Dale, The BLF (or the SCA) is a different concept from the ring group. Unless all the UAs registered to the same AOR, the proxy would ring all the UAs. Even with the same AOR, some can subscribe to the BLF state, and others don't. Therefore, even a larger group of UAs subscribed to the same DN state, it doesn't mean all the subscribers need to ring. In your hospital example, I would think it's very strange if all UAs programmed the same AOR. Jerry > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Monday, April 02, 2007 4:45 PM > To: bliss@ietf.org > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is > large? > > > One aspect of this problem that may need to be addressed is whether an > incoming call is expected to be presented on all appearances of the > DN. For a key system, people expect that. But a key system usually > has less than a dozen stations. If we expect a DN to appear on more > than 10 UAs, various scaling problems show up. E.g., consider the > hospital system that Geoff Devine described with 192 appearances of > each of 16 lines. If an incoming call rings on all 192 appearances, > the calling UA will see 192 early dialogs! > > OTOH, if we want to restrict the number of forks of an incoming call, > how is the proxy to decide which UAs should see that call? > > 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 Mon Apr 02 17:11:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYToO-0000Zi-BP; Mon, 02 Apr 2007 17:11:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYToM-0000Z2-MZ for bliss@ietf.org; Mon, 02 Apr 2007 17:11:34 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYToL-0000wg-Cd for bliss@ietf.org; Mon, 02 Apr 2007 17:11:34 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 31BEF20023; Mon, 2 Apr 2007 17:11:33 -0400 (EDT) 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 10078-04-4; Mon, 2 Apr 2007 17:11:32 -0400 (EDT) Received: from LT4GKCG41 (unknown [10.31.8.118]) by smtp.mitel.com (Postfix) with SMTP id 8B83F20057; Mon, 2 Apr 2007 17:11:30 -0400 (EDT) From: "Jerry Yin" To: , Subject: RE: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt Date: Mon, 2 Apr 2007 17:11:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200704022039.l32KdwSa012289@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Please see in-line comments. > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Monday, April 02, 2007 4:40 PM > To: bliss@ietf.org > Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt > > > From: "Geoff Devine" > > In PSTN-land key system emulation, an E.164 number is 1-to-1 with a > line appearance button on a station. > > It's a little stranger than that, though. In the machinery, each line > appearance button corresponds to one DN. But as users think about it, > often one DN will hunt to a series of other DNs, and they will think > of the buttons for all of those DNs as repetitions of the primary DN. > > I think the latter model is what this I-D (and anil-bla) are trying to > implement, where a DN has multiple "sub-lines", each of which is > assigned to a separate button, but which (other than by UAs with > appearances for that DN) are not individually addressible. > > Dale Both Broadsoft and Sylantro softswithes support the latter concept. Each UA should support multiple AORs which represent different Lines. Each Line (AOR) supports multiple calls (or call appearances). The call appearances are addressed by indexes starting from 0 to N (N is usually less than 10). Each appearance is assigned to a soft-key or hard key. The individually appearance is addressable in terms of making calls or pick up a remote held call, since you can identify the call by the call index. But for incoming calls, usually it takes any free call appearance (or index). Jerry > > _______________________________________________ > 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 Tue Apr 03 02:49: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 1HYcpR-0000rC-R6; Tue, 03 Apr 2007 02:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYcpQ-0000qv-8J for bliss@ietf.org; Tue, 03 Apr 2007 02:49: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 1HYcpM-0003qz-OU for bliss@ietf.org; Tue, 03 Apr 2007 02:49:16 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JFW00951TLLO8@siemenscomms.co.uk> for bliss@ietf.org; Tue, 03 Apr 2007 07:48:57 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 03 Apr 2007 07:49:01 +0100 Content-return: allowed Date: Tue, 03 Apr 2007 07:49:00 +0100 From: "Elwell, John" Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? To: Dale.Worley@comcast.net, bliss@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B7815C2@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Exactly, we really must identify some sort of limit to N, where N is the number of UAs to which an INVITE request is forked. It is not just the large number of early dialogs, but the possible need to do ICE checks and key management calculations on each of these. The UAC has no control over the degree of parallel forking. A UAC deployed in a home, say, cannot be expected to cater for large values of N when it calls into an enterprise that has this type of arrangement. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 02 April 2007 21:45 > To: bliss@ietf.org > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > large is large? > > One aspect of this problem that may need to be addressed is whether an > incoming call is expected to be presented on all appearances of the > DN. For a key system, people expect that. But a key system usually > has less than a dozen stations. If we expect a DN to appear on more > than 10 UAs, various scaling problems show up. E.g., consider the > hospital system that Geoff Devine described with 192 appearances of > each of 16 lines. If an incoming call rings on all 192 appearances, > the calling UA will see 192 early dialogs! > > OTOH, if we want to restrict the number of forks of an incoming call, > how is the proxy to decide which UAs should see that call? > > 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 Tue Apr 03 14:48:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYo2q-0007sa-9k; Tue, 03 Apr 2007 14:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYo2o-0007sU-Do for bliss@ietf.org; Tue, 03 Apr 2007 14:47:50 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYo2k-000654-Tq for bliss@ietf.org; Tue, 03 Apr 2007 14:47:50 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 14:47:45 -0400 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] comments on draft-johnston-bliss-mla-req-00.txt Date: Tue, 3 Apr 2007 14:47:45 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94201A4308A@MAIL02.cedarpointcom.com> In-Reply-To: <200704022039.l32KdwSa012289@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt Thread-Index: Acd1ZyXcAQGvvmp0SLmz0E1ArkCYzAAgHKsQ References: <402F25FC1EB2BD44831F8A4A4F6DF9420185E692@MAIL02.cedarpointcom.com> <200704022039.l32KdwSa012289@dragon.ariadne.com> From: "Geoff Devine" To: , X-OriginalArrivalTime: 03 Apr 2007 18:47:45.0118 (UTC) FILETIME=[913E9FE0:01C77620] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Dale, OK. ...but that's not how a legacy 1A2 Key System worked back in the dark ages. You could always layer hunting on top of it back at the central office but the original key system implementation had a copper pair with an E.164 number per line button. I think it's important to capture this 1-1 behavior as a baseline function in the mla-req so any protocol design considers the case. There are then _many_ enhancements and options you can layer on top of the baseline. The 'sub-lines' behavior where a call can hunt to another idle line appearance is one possibility. I'd point out that in a true legacy key system, those 'sub-lines' were indeed individually addressable since they mapped onto a copper pair with a unique DN. That DN needed to be individually addressable to make test calls, if nothing else. In a PBX with Direct Inward Dial or Primary Rate you could make this arrangement logical but not in a true key system with ground start or loop start interfaces. Geoff -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Monday, April 02, 2007 4:40 PM To: bliss@ietf.org Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt From: "Geoff Devine" In PSTN-land key system emulation, an E.164 number is 1-to-1 with a line appearance button on a station. It's a little stranger than that, though. In the machinery, each line appearance button corresponds to one DN. But as users think about it, often one DN will hunt to a series of other DNs, and they will think of the buttons for all of those DNs as repetitions of the primary DN. I think the latter model is what this I-D (and anil-bla) are trying to implement, where a DN has multiple "sub-lines", each of which is assigned to a separate button, but which (other than by UAs with appearances for that DN) are not individually addressible. 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 Tue Apr 03 21:29: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 1HYuJa-0008Ph-1L; Tue, 03 Apr 2007 21:29:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuJY-0008PW-FD for bliss@ietf.org; Tue, 03 Apr 2007 21:29:32 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuJQ-0008DM-II for bliss@ietf.org; Tue, 03 Apr 2007 21:29:32 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070404012923b1400noptbe>; Wed, 4 Apr 2007 01:29:23 +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 l341TJLv008990 for ; Tue, 3 Apr 2007 21:29:19 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l341TJR7008986; Tue, 3 Apr 2007 21:29:19 -0400 Date: Tue, 3 Apr 2007 21:29:19 -0400 Message-Id: <200704040129.l341TJR7008986@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <402F25FC1EB2BD44831F8A4A4F6DF94201A4308A@MAIL02.cedarpointcom.com> (gdevine@cedarpointcom.com) Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt References: <402F25FC1EB2BD44831F8A4A4F6DF9420185E692@MAIL02.cedarpointcom.com> <200704022039.l32KdwSa012289@dragon.ariadne.com> <402F25FC1EB2BD44831F8A4A4F6DF94201A4308A@MAIL02.cedarpointcom.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: "Geoff Devine" I'd point out that in a true legacy key system, those 'sub-lines' were indeed individually addressable since they mapped onto a copper pair with a unique DN. Uh, yes, that's what I said, "In the machinery, each line appearance button corresponds to one DN. But *as users think about it*..." Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Apr 03 22:26:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYvCY-0002to-FS; Tue, 03 Apr 2007 22:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYvCX-0002t0-5t for bliss@ietf.org; Tue, 03 Apr 2007 22:26:21 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYvCV-0000iy-LA for bliss@ietf.org; Tue, 03 Apr 2007 22:26:21 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 604A220034; Tue, 3 Apr 2007 22:26:19 -0400 (EDT) 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 30434-02; Tue, 3 Apr 2007 22:26:18 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id B630A20026; Tue, 3 Apr 2007 22:26:18 -0400 (EDT) In-Reply-To: <50B1CBA96870A34799A506B2313F26670B7815C2@ntht201e.siemenscomms.co.uk> To: "Elwell, John" Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: dan_york@Mitel.com Date: Tue, 3 Apr 2007 22:26:15 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 04/03/2007 10:26:15 PM, Serialize complete at 04/03/2007 10:26:15 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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="===============1890892599==" Errors-To: bliss-bounces@ietf.org This is a multipart message in MIME format. --===============1890892599== Content-Type: multipart/alternative; boundary="=_alternative 000D643B852572B3_=" This is a multipart message in MIME format. --=_alternative 000D643B852572B3_= Content-Type: text/plain; charset="US-ASCII" So how do we get to "N"? What factors need to be considered in arriving at that number? - whether ICE or key management is involved? - capabilities of the UAC initiating the call? - bandwidth on either end? (latency?) - capabilities of intermediary SIP proxy servers? (or SBCs or firewalls?) - ?? Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y. If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines. 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 "Elwell, John" 04/03/2007 02:49 AM To: Dale.Worley@comcast.net, bliss@ietf.org cc: Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Exactly, we really must identify some sort of limit to N, where N is the number of UAs to which an INVITE request is forked. It is not just the large number of early dialogs, but the possible need to do ICE checks and key management calculations on each of these. The UAC has no control over the degree of parallel forking. A UAC deployed in a home, say, cannot be expected to cater for large values of N when it calls into an enterprise that has this type of arrangement. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 02 April 2007 21:45 > To: bliss@ietf.org > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > large is large? > > One aspect of this problem that may need to be addressed is whether an > incoming call is expected to be presented on all appearances of the > DN. For a key system, people expect that. But a key system usually > has less than a dozen stations. If we expect a DN to appear on more > than 10 UAs, various scaling problems show up. E.g., consider the > hospital system that Geoff Devine described with 192 appearances of > each of 16 lines. If an incoming call rings on all 192 appearances, > the calling UA will see 192 early dialogs! > > OTOH, if we want to restrict the number of forks of an incoming call, > how is the proxy to decide which UAs should see that call? > > 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 --=_alternative 000D643B852572B3_= Content-Type: text/html; charset="US-ASCII"
So how do we get to "N"?  What factors need to be considered in arriving at that number?
  - whether ICE or key management is involved?
  - capabilities of the UAC initiating the call?
  - bandwidth on either end?  (latency?)
  - capabilities of intermediary SIP proxy servers?  (or SBCs or firewalls?)
  - ??

Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y.  If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines.

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


"Elwell, John" <john.elwell@siemens.com>

04/03/2007 02:49 AM

       
        To:        Dale.Worley@comcast.net, bliss@ietf.org
        cc:        
        Subject:        RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la        rge?



Exactly, we really must identify some sort of limit to N, where N is the
number of UAs to which an INVITE request is forked. It is not just the large
number of early dialogs, but the possible need to do ICE checks and key
management calculations on each of these. The UAC has no control over the
degree of parallel forking. A UAC deployed in a home, say, cannot be
expected to cater for large values of N when it calls into an enterprise
that has this type of arrangement.

John

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: 02 April 2007 21:45
> To: bliss@ietf.org
> Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how
> large is large?
>
> One aspect of this problem that may need to be addressed is whether an
> incoming call is expected to be presented on all appearances of the
> DN.  For a key system, people expect that.  But a key system usually
> has less than a dozen stations.  If we expect a DN to appear on more
> than 10 UAs, various scaling problems show up.  E.g., consider the
> hospital system that Geoff Devine described with 192 appearances of
> each of 16 lines.  If an incoming call rings on all 192 appearances,
> the calling UA will see 192 early dialogs!
>
> OTOH, if we want to restrict the number of forks of an incoming call,
> how is the proxy to decide which UAs should see that call?
>
> 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
--=_alternative 000D643B852572B3_=-- --===============1890892599== 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 --===============1890892599==-- From bliss-bounces@ietf.org Wed Apr 04 02:21: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 1HYysK-00041Q-V5; Wed, 04 Apr 2007 02:21:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYysJ-00041G-IV for bliss@ietf.org; Wed, 04 Apr 2007 02:21:43 -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 1HYysF-0004M3-PO for bliss@ietf.org; Wed, 04 Apr 2007 02:21:43 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JFY00F67MZOL5@siemenscomms.co.uk> for bliss@ietf.org; Wed, 04 Apr 2007 07:21:24 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 04 Apr 2007 07:21:28 +0100 Content-return: allowed Date: Wed, 04 Apr 2007 07:21:27 +0100 From: "Elwell, John" Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? To: dan_york@Mitel.com Message-id: <50B1CBA96870A34799A506B2313F26670B781DE9@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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="===============0270643085==" Errors-To: bliss-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0270643085== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_B9zoNLZRBZUiLKZRkg5PdA)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_B9zoNLZRBZUiLKZRkg5PdA) Content-type: text/plain Content-transfer-encoding: 7BIT Dan, You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances. I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc. John _____ From: dan_york@Mitel.com [mailto:dan_york@Mitel.com] Sent: 04 April 2007 03:26 To: Elwell, John Cc: bliss@ietf.org; Dale.Worley@comcast.net Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? So how do we get to "N"? What factors need to be considered in arriving at that number? - whether ICE or key management is involved? - capabilities of the UAC initiating the call? - bandwidth on either end? (latency?) - capabilities of intermediary SIP proxy servers? (or SBCs or firewalls?) - ?? Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y. If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines. 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 "Elwell, John" 04/03/2007 02:49 AM To: Dale.Worley@comcast.net, bliss@ietf.org cc: Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Exactly, we really must identify some sort of limit to N, where N is the number of UAs to which an INVITE request is forked. It is not just the large number of early dialogs, but the possible need to do ICE checks and key management calculations on each of these. The UAC has no control over the degree of parallel forking. A UAC deployed in a home, say, cannot be expected to cater for large values of N when it calls into an enterprise that has this type of arrangement. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 02 April 2007 21:45 > To: bliss@ietf.org > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > large is large? > > One aspect of this problem that may need to be addressed is whether an > incoming call is expected to be presented on all appearances of the > DN. For a key system, people expect that. But a key system usually > has less than a dozen stations. If we expect a DN to appear on more > than 10 UAs, various scaling problems show up. E.g., consider the > hospital system that Geoff Devine described with 192 appearances of > each of 16 lines. If an incoming call rings on all 192 appearances, > the calling UA will see 192 early dialogs! > > OTOH, if we want to restrict the number of forks of an incoming call, > how is the proxy to decide which UAs should see that call? > > 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 --Boundary_(ID_B9zoNLZRBZUiLKZRkg5PdA) Content-type: text/html Content-transfer-encoding: 7BIT
Dan,
 
You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances.
 
I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc.
 
John

From: dan_york@Mitel.com [mailto:dan_york@Mitel.com]
Sent: 04 April 2007 03:26
To: Elwell, John
Cc: bliss@ietf.org; Dale.Worley@comcast.net
Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?


So how do we get to "N"?  What factors need to be considered in arriving at that number?
  - whether ICE or key management is involved?
  - capabilities of the UAC initiating the call?
  - bandwidth on either end?  (latency?)
  - capabilities of intermediary SIP proxy servers?  (or SBCs or firewalls?)
  - ??

Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y.  If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines.

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




"Elwell, John" <john.elwell@siemens.com>

04/03/2007 02:49 AM

       
        To:        Dale.Worley@comcast.net, bliss@ietf.org
        cc:        
        Subject:        RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la        rge?



Exactly, we really must identify some sort of limit to N, where N is the
number of UAs to which an INVITE request is forked. It is not just the large
number of early dialogs, but the possible need to do ICE checks and key
management calculations on each of these. The UAC has no control over the
degree of parallel forking. A UAC deployed in a home, say, cannot be
expected to cater for large values of N when it calls into an enterprise
that has this type of arrangement.

John

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: 02 April 2007 21:45
> To: bliss@ietf.org
> Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how
> large is large?
>
> One aspect of this problem that may need to be addressed is whether an
> incoming call is expected to be presented on all appearances of the
> DN.  For a key system, people expect that.  But a key system usually
> has less than a dozen stations.  If we expect a DN to appear on more
> than 10 UAs, various scaling problems show up.  E.g., consider the
> hospital system that Geoff Devine described with 192 appearances of
> each of 16 lines.  If an incoming call rings on all 192 appearances,
> the calling UA will see 192 early dialogs!
>
> OTOH, if we want to restrict the number of forks of an incoming call,
> how is the proxy to decide which UAs should see that call?
>
> 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

--Boundary_(ID_B9zoNLZRBZUiLKZRkg5PdA)-- --===============0270643085== 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 --===============0270643085==-- From bliss-bounces@ietf.org Wed Apr 04 11:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7qN-0006AM-N4; Wed, 04 Apr 2007 11:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7qL-0006AG-UO for bliss@ietf.org; Wed, 04 Apr 2007 11:56:17 -0400 Received: from mail44.opentransfer.com ([71.18.216.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ7qK-0008AY-ET for bliss@ietf.org; Wed, 04 Apr 2007 11:56:17 -0400 Received: (qmail 13610 invoked by uid 399); 4 Apr 2007 15:56:15 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 4 Apr 2007 15:56:15 -0000 Message-ID: <4613CA9F.5030205@sipstation.com> Date: Wed, 04 Apr 2007 10:56:15 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? References: <50B1CBA96870A34799A506B2313F26670B781DE9@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B781DE9@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: bliss@ietf.org, dan_york@Mitel.com 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 We will include a discussion of these issues in the next version. We will also describe how a UA can just subscribe to the Appearance Agent but not register against the AOR and make sure there are no issues with this mode of operation. Thanks, Alan Elwell, John wrote: > Dan, > > You are right, of course, and I wasn't necessarily thinking about > standardising a value of N. But let's have some idea what value of N > we are aiming it. If we consider this value of N to be a huge burden > on the significant population of UACs when an INVITE request is > forked, then we need to rethink the solution. So maybe would need a > recommendation that forked INVITE requests be used only up to a > certain number of appearances and look for alternative solutions to > cover any situations with a much larger number of appearances. > > I would be interested to know whether there is any information from > SIPit concerning the ability of UACs to cope with INVITE requests that > get forked to a large number of UASs and the degree to which this is > impacted by ICE, key management, etc. > > John > > ------------------------------------------------------------------------ > *From:* dan_york@Mitel.com [mailto:dan_york@Mitel.com] > *Sent:* 04 April 2007 03:26 > *To:* Elwell, John > *Cc:* bliss@ietf.org; Dale.Worley@comcast.net > *Subject:* RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > large is la rge? > > > So how do we get to "N"? What factors need to be considered in > arriving at that number? > - whether ICE or key management is involved? > - capabilities of the UAC initiating the call? > - bandwidth on either end? (latency?) > - capabilities of intermediary SIP proxy servers? (or SBCs or > firewalls?) > - ?? > > Given the number of possible network permutations, I wonder if we > can get to a hard number... or if it is more of a sliding scale > based on capabilities, i.e. if ICE is involved N = x, if ICE is > not involved N = y. If it's a sliding scale, it raises the > question to me of whether this is something that can truly be > standardized, or if it is more something for a BCP or some form of > engineering guidelines. > > 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 > > > > > > *"Elwell, John" * > > 04/03/2007 02:49 AM > > > To: Dale.Worley@comcast.net, bliss@ietf.org > cc: > Subject: RE: [BLISS] > draft-johnston-bliss-mla-req-00.txt - how large is la rge? > > > > > Exactly, we really must identify some sort of limit to N, where N > is the > number of UAs to which an INVITE request is forked. It is not just > the large > number of early dialogs, but the possible need to do ICE checks > and key > management calculations on each of these. The UAC has no control > over the > degree of parallel forking. A UAC deployed in a home, say, cannot be > expected to cater for large values of N when it calls into an > enterprise > that has this type of arrangement. > > John > > > -----Original Message----- > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > Sent: 02 April 2007 21:45 > > To: bliss@ietf.org > > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > > large is large? > > > > One aspect of this problem that may need to be addressed is > whether an > > incoming call is expected to be presented on all appearances of the > > DN. For a key system, people expect that. But a key system usually > > has less than a dozen stations. If we expect a DN to appear on more > > than 10 UAs, various scaling problems show up. E.g., consider the > > hospital system that Geoff Devine described with 192 appearances of > > each of 16 lines. If an incoming call rings on all 192 appearances, > > the calling UA will see 192 early dialogs! > > > > OTOH, if we want to restrict the number of forks of an incoming > call, > > how is the proxy to decide which UAs should see that call? > > > > 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 > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Apr 04 12:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ84o-0007qb-OO; Wed, 04 Apr 2007 12:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ84n-0007qP-JE for bliss@ietf.org; Wed, 04 Apr 2007 12:11:13 -0400 Received: from mail44.opentransfer.com ([71.18.216.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ84m-0004au-4p for bliss@ietf.org; Wed, 04 Apr 2007 12:11:13 -0400 Received: (qmail 22947 invoked by uid 399); 4 Apr 2007 16:11:11 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 4 Apr 2007 16:11:11 -0000 Message-ID: <4613CE1D.9030105@sipstation.com> Date: Wed, 04 Apr 2007 11:11:09 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Some comments on draft-johnston-bliss-mla-req-00.txt References: <200704022034.l32KYcEZ011870@dragon.ariadne.com> In-Reply-To: <200704022034.l32KYcEZ011870@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 Dale, Thanks for your comments on the draft. See mine below. Thanks, Alan Dale.Worley@comcast.net wrote: > * The passage: > > group telephony feature commonly known as Bridged Line Appearance > > should be: > > group >of< telephony feature>s< commonly known as Bridged Line Appearance > > Well, that wasn't the intent of the sentence. The intent was to point out that BLA is a group feature - i.e. a feature that is more complicated than a feature that just involves 2 or 3 UAs as most other features we have discussed in the past. We may try to expand this discussion to make this more clear. > I've also seen the term "Shared Call Status" used. > > I'll add it to the list ;-) > * Given this: > > When implemented using the Session Initiation Protocol (SIP), > it is referred to as Multiple Appearances. > > why is the I-D titled "Multiple Line Appearance Feature" rather than > "Multiple Appearances Feature"? > > The use of line in the title was meant to help an unfamiliar reader understand the feature being addressed without having to read the abstract. If it is confusing, we can remove it. > * The introduction reads: > > This specification details a method for implementing a group > telephony feature known in telephony as Bridged Line Appearance (BLA) > or Multiple Line Appearance, [...] > > Different approaches will be discussed including [...] > > Which does this document do, present one method or present several > methods? I expect that it focuses on one approach which can be > implemented in several ways. If so, the I-D needs to clearly specify > the overall approach and distinguish it from the individual methods. > The former is an editing artifact. The intent is to present several approaches and discuss them. > * REQ-2 > > REQ-2 Each UA in the group must be able to learn the call status of > the others in the group for the purpose of rendering this information > to the user. > > Though in a traditional "key system", a UA only knows the status of > each line appearance as available/ringing/in-use, and not the status > of other UAs per se. > Right - a SIP implementation will likely provide more information than a key system would have - it is a user interface issue about which information to render to the user. > * REQ-5 > > REQ-5 The mechanism must scale for large numbers of appearances, n, > and large numbers of UAs, N, without introducing excessive messaging > traffic. > > Better give some idea of how large "large" is. In the computer > science world, people can consider "large" to start at 1,000,000. > Perhaps you want to say that message traffic scales linearly with the > number of appearances. > That is a good suggestion. > * REQ-11 > > REQ-11 The mechanism must have backwards compatibility such that a UA > which is unaware of the feature can still register against the group > AOR and make and receive calls. > > And it should cause only minimal disruption to the MLA UAs. > Specifically, it is permitted that calls that it generates/answers are > not visible or managable by the MLA mechanism, but they must not > interfere with MLA operation for other calls. > I think we can do better than that, but we shall see in the details of the actual mechanism. I agree not interfering is an important requirement. > * REQ-12 > > REQ-12 The mechanism must not allow UAs outside the group to select > or manipulate appearance numbers. > > Particularly, you don't want the UA generating a call to the AOR to be > able to select the appearance number. > Yes - we will highlight this case. > * REQ-15 > > REQ-13 For privacy reasons, there must be a mechanism so that > appearance information is not leaked outside the group of UAs. (e.g. > "So who do you have on line 1?") > > Are the privacy requirements for MLA any more strict than the ordinary > privacy considerations for the dialog event package? > I'm not sure. Are you thinking about privacy within the group of UAs? > * draft-anil-sipping-bla-04 > > How does this I-D relate to draft-anil-sipping-bla-04.txt? Is this > I-D fundamentally a discussion of variations on that I-D? > No, this draft discusses various options while draft-anil-sipping-bla takes one of them and details the mechanism. > * Section 5.1 > > This section discusses and compares multiple methods of implementing, > conveying, and selecting appearances in SIP while meeting the > requirements of Section 4. These approaches are a URI parameter and > a SIP dialog package extension parameter. All the approaches here > assume the common elements and operations of Figure 1. > > This is awkwardly phrased, given that you have only two alternatives. > The phrasing would be more appropriate if there were a large number of > alternatives. > > This section discusses and compares two methods of implementing, > conveying, and selecting appearances in SIP while meeting the > requirements of Section 4. One approach involves a URI parameter > and is discussed in section 5.1.1. The other approach uses a SIP > dialog package extension parameter and is discussed in section > 5.1.2. Both approaches assume the common elements and operations > of Figure 1. > > 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 Wed Apr 04 12:24: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 1HZ8Ho-0002Oj-JW; Wed, 04 Apr 2007 12:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8Hm-0002Nr-Jt for bliss@ietf.org; Wed, 04 Apr 2007 12:24:38 -0400 Received: from mail44.opentransfer.com ([71.18.216.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ8Hl-0000EL-4z for bliss@ietf.org; Wed, 04 Apr 2007 12:24:38 -0400 Received: (qmail 28549 invoked by uid 399); 4 Apr 2007 16:24:35 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 4 Apr 2007 16:24:35 -0000 Message-ID: <4613D144.6020107@sipstation.com> Date: Wed, 04 Apr 2007 11:24:36 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Geoff Devine Subject: Re: [BLISS] comments on draft-johnston-bliss-mla-req-00.txt References: <402F25FC1EB2BD44831F8A4A4F6DF9420185E692@MAIL02.cedarpointcom.com> In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF9420185E692@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 Geoff, Thanks for your comments. See mine below. Thanks, Alan Geoff Devine wrote: > > I think this is a great first cut at requirements. Some comments…. > > REQ-2 Each UA in the group must be able to learn the call status of > > the others in the group for the purpose of rendering this information > > to the user. > > [geoff] I think you at least need to add a requirement REQ-2A to > administratively disable this feature or at least have a mode where > specific UA status is kept private. In 1A2 Key Systems, you convey > “line” status (where “line” maps to an E.164 telephone number or a > private telephone number) to the other “stations” (UA’s). You don’t > necessarily want to convey station status to the other stations that > share a line appearance. > Can you explain a little more what you are looking for? The group will know whatever status the UA publishes to the Appearance Agent. Perhaps this requirement could be met by allowing a UA to not publish certain call state information if it wants to keep it private. > REQ-3 Calls can be joined (also called bridged or conferenced > > together) or can be picked up (taken) by another UA in the group in a > > secure way. > > [geoff] Regulatory issue: In the carrier class universe, there are > parts of the world where you can ring multiple UAs but a bridging > function is forbidden. I suggest a REQ-3A as: “It must be possible to > administratively disable the Call Join (also called bridged or > conferenced together) function.” > Any request for bridging or pickup can be rejected by the UAS or even a proxy server. Perhaps you just want this called out? > REQ-4 The mechanism should require the minimal amount of > > configuration. UAs registering against the group AOR should be able > > to learn about each other and join the appearance group. > > [geoff] This is in conflict with other requirements I’ve been listing > that imply careful administrative control of this feature set. > Perhaps this requirement needs to be reworded - it is about auto discovery. The mechanism should not require that a UA be provisioned with the URIs of the other UAs in the group. > REQ-5 The mechanism must scale for large numbers of appearances, n, > > and large numbers of UAs, N, without introducing excessive messaging > > traffic. > > [geoff] Yes! The first time I built this function for a PBX in 1985, > an early deployment was in a large hospital where they had a dozen > hallways of 16 examination rooms where each examination room had a > feature phone with 16 line appearances. The traffic characteristics of > that switch were about 10x what they would have been without a key > system emulation feature. The engineers called that deployment “The > Baby Killer”. As a practical thing, you will always have a flood of > messaging since you need to line status (Idle, Ringing, Talking, > On-Hold (several flavors of the feature), DND, …) to each station. I > think the requirement is more like “… should minimize messaging traffic.” > Are you OK with Dale's suggestion to reword to say that the mechanism should cause traffic to scale linearly? > REQ-6 Each call or session (incoming or outgoing) must be assigned a > > common "appearance" number from a managed pool administered for the > > AOR group. Once the session has terminated, the appearance number is > > released back into the pool and can be reused by another incoming or > > outgoing session. > > [geoff] Why “appearance number”? Using a small integer is one > possibility but there are other ways you may want to name a line > appearance. You could use E.164 number, a URI, or any unique character > string. > You are correct, we could just use an appearance label instead of a number. However, ordering of appearances is a very important user interface issue. If my application uses appearances "xd3", "k3s", and "82s" what would be the order of rendering if my UI only has a row of buttons? Is your requirement for a human-friendly label for the appearances? If so, we could add this in addition to the appearance number. > [geoff] The wording of the first sentence is a little confusing. A > reader may interpret this as a hunting requirement. In PSTN-land key > system emulation, an E.164 number is 1-to-1 with a line appearance > button on a station. I think this is what you mean. > That is one way to utilize the appearance number but not the only way. Could you help rephrase so that it doesn't imply hunting to you? > Best regards, > > Geoff > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Apr 04 12:26: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 1HZ8K1-0005Dn-65; Wed, 04 Apr 2007 12:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8K0-0005Bd-0X for bliss@ietf.org; Wed, 04 Apr 2007 12:26:56 -0400 Received: from mail44.opentransfer.com ([71.18.216.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ8Jy-0000yA-La for bliss@ietf.org; Wed, 04 Apr 2007 12:26:55 -0400 Received: (qmail 2522 invoked by uid 399); 4 Apr 2007 16:26:52 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 4 Apr 2007 16:26:52 -0000 Message-ID: <4613D1CD.3070708@sipstation.com> Date: Wed, 04 Apr 2007 11:26:53 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "DOLLY, MARTIN C, ATTLABS" Subject: Re: [BLISS] Fwd: I-D ACTION:draft-johnston-bliss-mla-req-00.txt References: <50B1CBA96870A34799A506B2313F26670B4F5D99@ntht201e.siemenscomms.co.uk> <45FE50D9.1010708@sipstation.com> <28F05913385EAC43AF019413F674A017101B77C7@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A017101B77C7@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Martin, I agree that an emergency call should override this behavior. We can put in a note about that. Thanks, Alan DOLLY, MARTIN C, ATTLABS wrote: > Alan > > Section 6.2 "Call Originated by a UA in a BLA group", the first > paragraph states that "the UA just before allowing the user to place a > call, > shall send out a dialog event NOTIFY with state (trying). The User Agent > MUST wait for a 200 OK response from the State Agent, before it proceeds > with sending out the INVITE to the address entered by the end user." > This > places the State Agent in the critical path for whether or not a call > goes > through. In a 911 scenario I don't know if we want to have a dependency > on > the responsiveness of the State Agent (which has to deal with many > SUBSCRIBEs and NOTIFYs as per this draft) before a 911 call (or some > other > type of emergency call) can go through. > > Cheers, > > Martin > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Apr 04 21:03: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 1HZGNt-0005QX-DT; Wed, 04 Apr 2007 21:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGNs-0005Gt-4B for bliss@ietf.org; Wed, 04 Apr 2007 21:03:28 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGNq-0000GJ-SC for bliss@ietf.org; Wed, 04 Apr 2007 21:03:28 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070405010326b1500snm48e>; Thu, 5 Apr 2007 01:03:26 +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 l3513PLv015447 for ; Wed, 4 Apr 2007 21:03:25 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3513Pqu015443; Wed, 4 Apr 2007 21:03:25 -0400 Date: Wed, 4 Apr 2007 21:03:25 -0400 Message-Id: <200704050103.l3513Pqu015443@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4613CE1D.9030105@sipstation.com> (alan@sipstation.com) Subject: Re: [BLISS] Some comments on draft-johnston-bliss-mla-req-00.txt References: <200704022034.l32KYcEZ011870@dragon.ariadne.com> <4613CE1D.9030105@sipstation.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: Alan Johnston Dale.Worley@comcast.net wrote: > * The passage: > > group telephony feature commonly known as Bridged Line Appearance > > should be: > > group >of< telephony feature>s< commonly known as Bridged Line Appearance > > Well, that wasn't the intent of the sentence. The intent was to point out that BLA is a group feature - i.e. a feature that is more complicated than a feature that just involves 2 or 3 UAs as most other features we have discussed in the past. We may try to expand this discussion to make this more clear. OK, that's my mistake -- I didn't know that there was a term "group feature". > * Given this: > > When implemented using the Session Initiation Protocol (SIP), > it is referred to as Multiple Appearances. > > why is the I-D titled "Multiple Line Appearance Feature" rather than > "Multiple Appearances Feature"? The use of line in the title was meant to help an unfamiliar reader understand the feature being addressed without having to read the abstract. If it is confusing, we can remove it. Looking at the comments from others, I think that keeping the terminology consistent is going to be a major problem. And it doesn't help that it sounds like the terminology in the telco world is not consistent, either. > * REQ-15 > > REQ-13 For privacy reasons, there must be a mechanism so that > appearance information is not leaked outside the group of UAs. (e.g. > "So who do you have on line 1?") > > Are the privacy requirements for MLA any more strict than the ordinary > privacy considerations for the dialog event package? I'm not sure. Are you thinking about privacy within the group of UAs? I don't know. I suspect that in previous systems, people haven't worried about privacy much. But it would not be useful to require more privacy protection than is allowed by other features. > * draft-anil-sipping-bla-04 > > How does this I-D relate to draft-anil-sipping-bla-04.txt? Is this > I-D fundamentally a discussion of variations on that I-D? No, this draft discusses various options while draft-anil-sipping-bla takes one of them and details the mechanism. OK, but the major diagram seems to be taken from draft-anil-sipping-bla, so it's not clear to the new reader how this differs from that. Better to explain the relationship carefully. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Apr 05 18:03: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 1HZa3W-0002u9-Nv; Thu, 05 Apr 2007 18:03:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZa3U-0002o5-QO for bliss@ietf.org; Thu, 05 Apr 2007 18:03:44 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZa3C-000666-DK for bliss@ietf.org; Thu, 05 Apr 2007 18:03:44 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG1006B4P9LGK@usaga01-in.huawei.com> for bliss@ietf.org; Thu, 05 Apr 2007 15:03:21 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JG100ILJP9G2E@usaga01-in.huawei.com> for bliss@ietf.org; Thu, 05 Apr 2007 15:03:21 -0700 (PDT) Date: Thu, 05 Apr 2007 17:02:02 -0500 From: Spencer Dawkins Subject: Re: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? To: "Elwell, John" , dan_york@Mitel.com Message-id: <240d01c777ce$0b1c97a0$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal References: <50B1CBA96870A34799A506B2313F26670B781DE9@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.3 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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="===============1646837884==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============1646837884== Content-type: multipart/alternative; boundary="Boundary_(ID_5eTiTNKE0qAMF6tMurBRdg)" This is a multi-part message in MIME format. --Boundary_(ID_5eTiTNKE0qAMF6tMurBRdg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, John, I may have misunderstood your previous note in this thread, but I thought you were saying that the UAC has no control over what engineering guidelines the UAS decides are appropriate - if my limited-capacity UA calls your massively-forking proxy, something fails, and the UAC has no way to determine what works and what fails. Or did I miss your point? Spencer ----- Original Message ----- From: Elwell, John To: dan_york@Mitel.com Cc: bliss@ietf.org Sent: Wednesday, April 04, 2007 1:21 AM Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Dan, You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances. I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc. John ---------------------------------------------------------------------------- From: dan_york@Mitel.com [mailto:dan_york@Mitel.com] Sent: 04 April 2007 03:26 To: Elwell, John Cc: bliss@ietf.org; Dale.Worley@comcast.net Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? So how do we get to "N"? What factors need to be considered in arriving at that number? - whether ICE or key management is involved? - capabilities of the UAC initiating the call? - bandwidth on either end? (latency?) - capabilities of intermediary SIP proxy servers? (or SBCs or firewalls?) - ?? Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y. If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines. 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 "Elwell, John" 04/03/2007 02:49 AM To: Dale.Worley@comcast.net, bliss@ietf.org cc: Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Exactly, we really must identify some sort of limit to N, where N is the number of UAs to which an INVITE request is forked. It is not just the large number of early dialogs, but the possible need to do ICE checks and key management calculations on each of these. The UAC has no control over the degree of parallel forking. A UAC deployed in a home, say, cannot be expected to cater for large values of N when it calls into an enterprise that has this type of arrangement. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 02 April 2007 21:45 > To: bliss@ietf.org > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > large is large? > > One aspect of this problem that may need to be addressed is whether an > incoming call is expected to be presented on all appearances of the > DN. For a key system, people expect that. But a key system usually > has less than a dozen stations. If we expect a DN to appear on more > than 10 UAs, various scaling problems show up. E.g., consider the > hospital system that Geoff Devine described with 192 appearances of > each of 16 lines. If an incoming call rings on all 192 appearances, > the calling UA will see 192 early dialogs! > > OTOH, if we want to restrict the number of forks of an incoming call, > how is the proxy to decide which UAs should see that call? > > 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 ------------------------------------------------------------------------------ _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --Boundary_(ID_5eTiTNKE0qAMF6tMurBRdg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi, John,
 
I may have misunderstood your previous note in this thread, but I thought you were saying that the UAC has no control over what engineering guidelines the UAS decides are appropriate - if my limited-capacity UA calls your massively-forking proxy, something fails, and the UAC has no way to determine what works and what fails.
 
Or did I miss your point?
 
Spencer
----- Original Message -----
Sent: Wednesday, April 04, 2007 1:21 AM
Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?

Dan,
 
You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances.
 
I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc.
 
John

From: dan_york@Mitel.com [mailto:dan_york@Mitel.com]
Sent: 04 April 2007 03:26
To: Elwell, John
Cc: bliss@ietf.org; Dale.Worley@comcast.net
Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?


So how do we get to "N"?  What factors need to be considered in arriving at that number?
  - whether ICE or key management is involved?
  - capabilities of the UAC initiating the call?
  - bandwidth on either end?  (latency?)
  - capabilities of intermediary SIP proxy servers?  (or SBCs or firewalls?)
  - ??

Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y.  If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines.

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




"Elwell, John" <john.elwell@siemens.com>

04/03/2007 02:49 AM

       
        To:        Dale.Worley@comcast.net, bliss@ietf.org
        cc:        
        Subject:        RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la        rge?



Exactly, we really must identify some sort of limit to N, where N is the
number of UAs to which an INVITE request is forked. It is not just the large
number of early dialogs, but the possible need to do ICE checks and key
management calculations on each of these. The UAC has no control over the
degree of parallel forking. A UAC deployed in a home, say, cannot be
expected to cater for large values of N when it calls into an enterprise
that has this type of arrangement.

John

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: 02 April 2007 21:45
> To: bliss@ietf.org
> Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how
> large is large?
>
> One aspect of this problem that may need to be addressed is whether an
> incoming call is expected to be presented on all appearances of the
> DN.  For a key system, people expect that.  But a key system usually
> has less than a dozen stations.  If we expect a DN to appear on more
> than 10 UAs, various scaling problems show up.  E.g., consider the
> hospital system that Geoff Devine described with 192 appearances of
> each of 16 lines.  If an incoming call rings on all 192 appearances,
> the calling UA will see 192 early dialogs!
>
> OTOH, if we want to restrict the number of forks of an incoming call,
> how is the proxy to decide which UAs should see that call?
>
> 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

_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www1.ietf.org/mailman/listinfo/bliss
--Boundary_(ID_5eTiTNKE0qAMF6tMurBRdg)-- --===============1646837884== 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 --===============1646837884==-- From bliss-bounces@ietf.org Fri Apr 06 13:04: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 1HZrr0-0004wO-L3; Fri, 06 Apr 2007 13:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrqz-0004wI-12 for bliss@ietf.org; Fri, 06 Apr 2007 13:04:01 -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 1HZrqu-0001bX-3K for bliss@ietf.org; Fri, 06 Apr 2007 13:04:01 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JG300D8162204@siemenscomms.co.uk> for bliss@ietf.org; Fri, 06 Apr 2007 18:03:38 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 06 Apr 2007 18:03:43 +0100 Content-return: allowed Date: Fri, 06 Apr 2007 18:03:42 +0100 From: "Elwell, John" Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? To: Spencer Dawkins , dan_york@Mitel.com Message-id: <50B1CBA96870A34799A506B2313F26670B7D7814@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc 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="===============2042345265==" Errors-To: bliss-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2042345265== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_NTqGeRjUpJT4bsQtT/9jMg)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_NTqGeRjUpJT4bsQtT/9jMg) Content-type: text/plain Content-transfer-encoding: 7BIT Spencer, My point was that the UAC can get overloaded - it might actually break, or it might operate correctly but very slowly. Even a well-designed UAC with reasonable capacity might not be able to cope with say N=20. So I am asking whether we need some sort of best practice recommendation that limits N. John _____ From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] Sent: 05 April 2007 23:02 To: Elwell, John; dan_york@Mitel.com Cc: bliss@ietf.org Subject: Re: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Hi, John, I may have misunderstood your previous note in this thread, but I thought you were saying that the UAC has no control over what engineering guidelines the UAS decides are appropriate - if my limited-capacity UA calls your massively-forking proxy, something fails, and the UAC has no way to determine what works and what fails. Or did I miss your point? Spencer ----- Original Message ----- From: Elwell, John To: dan_york@Mitel.com Cc: bliss@ietf.org Sent: Wednesday, April 04, 2007 1:21 AM Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Dan, You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances. I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc. John _____ From: dan_york@Mitel.com [mailto:dan_york@Mitel.com] Sent: 04 April 2007 03:26 To: Elwell, John Cc: bliss@ietf.org; Dale.Worley@comcast.net Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? So how do we get to "N"? What factors need to be considered in arriving at that number? - whether ICE or key management is involved? - capabilities of the UAC initiating the call? - bandwidth on either end? (latency?) - capabilities of intermediary SIP proxy servers? (or SBCs or firewalls?) - ?? Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y. If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines. 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 "Elwell, John" 04/03/2007 02:49 AM To: Dale.Worley@comcast.net, bliss@ietf.org cc: Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? Exactly, we really must identify some sort of limit to N, where N is the number of UAs to which an INVITE request is forked. It is not just the large number of early dialogs, but the possible need to do ICE checks and key management calculations on each of these. The UAC has no control over the degree of parallel forking. A UAC deployed in a home, say, cannot be expected to cater for large values of N when it calls into an enterprise that has this type of arrangement. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 02 April 2007 21:45 > To: bliss@ietf.org > Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how > large is large? > > One aspect of this problem that may need to be addressed is whether an > incoming call is expected to be presented on all appearances of the > DN. For a key system, people expect that. But a key system usually > has less than a dozen stations. If we expect a DN to appear on more > than 10 UAs, various scaling problems show up. E.g., consider the > hospital system that Geoff Devine described with 192 appearances of > each of 16 lines. If an incoming call rings on all 192 appearances, > the calling UA will see 192 early dialogs! > > OTOH, if we want to restrict the number of forks of an incoming call, > how is the proxy to decide which UAs should see that call? > > 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 _____ _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --Boundary_(ID_NTqGeRjUpJT4bsQtT/9jMg) Content-type: text/html Content-transfer-encoding: 7BIT
Spencer,
 
My point was that the UAC can get overloaded - it might actually break, or it might operate correctly but very slowly. Even a well-designed UAC with reasonable capacity might not be able to cope with say N=20. So I am asking whether we need some sort of best practice recommendation that limits N.
 
John

From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]
Sent: 05 April 2007 23:02
To: Elwell, John; dan_york@Mitel.com
Cc: bliss@ietf.org
Subject: Re: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?

Hi, John,
 
I may have misunderstood your previous note in this thread, but I thought you were saying that the UAC has no control over what engineering guidelines the UAS decides are appropriate - if my limited-capacity UA calls your massively-forking proxy, something fails, and the UAC has no way to determine what works and what fails.
 
Or did I miss your point?
 
Spencer
----- Original Message -----
Sent: Wednesday, April 04, 2007 1:21 AM
Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?

Dan,
 
You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances.
 
I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc.
 
John

From: dan_york@Mitel.com [mailto:dan_york@Mitel.com]
Sent: 04 April 2007 03:26
To: Elwell, John
Cc: bliss@ietf.org; Dale.Worley@comcast.net
Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?


So how do we get to "N"?  What factors need to be considered in arriving at that number?
  - whether ICE or key management is involved?
  - capabilities of the UAC initiating the call?
  - bandwidth on either end?  (latency?)
  - capabilities of intermediary SIP proxy servers?  (or SBCs or firewalls?)
  - ??

Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y.  If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines.

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




"Elwell, John" <john.elwell@siemens.com>

04/03/2007 02:49 AM

       
        To:        Dale.Worley@comcast.net, bliss@ietf.org
        cc:        
        Subject:        RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la        rge?



Exactly, we really must identify some sort of limit to N, where N is the
number of UAs to which an INVITE request is forked. It is not just the large
number of early dialogs, but the possible need to do ICE checks and key
management calculations on each of these. The UAC has no control over the
degree of parallel forking. A UAC deployed in a home, say, cannot be
expected to cater for large values of N when it calls into an enterprise
that has this type of arrangement.

John

> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: 02 April 2007 21:45
> To: bliss@ietf.org
> Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how
> large is large?
>
> One aspect of this problem that may need to be addressed is whether an
> incoming call is expected to be presented on all appearances of the
> DN.  For a key system, people expect that.  But a key system usually
> has less than a dozen stations.  If we expect a DN to appear on more
> than 10 UAs, various scaling problems show up.  E.g., consider the
> hospital system that Geoff Devine described with 192 appearances of
> each of 16 lines.  If an incoming call rings on all 192 appearances,
> the calling UA will see 192 early dialogs!
>
> OTOH, if we want to restrict the number of forks of an incoming call,
> how is the proxy to decide which UAs should see that call?
>
> 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

_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www1.ietf.org/mailman/listinfo/bliss
--Boundary_(ID_NTqGeRjUpJT4bsQtT/9jMg)-- --===============2042345265== 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 --===============2042345265==-- From bliss-bounces@ietf.org Mon Apr 09 10:51: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 1HavCv-00031x-Ft; Mon, 09 Apr 2007 10:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavCu-00031r-1l for bliss@ietf.org; Mon, 09 Apr 2007 10:51:00 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HavCs-0006Ep-5m for bliss@ietf.org; Mon, 09 Apr 2007 10:51:00 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070409145056m13003hp7ge>; Mon, 9 Apr 2007 14:50:57 +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 l39EotLv020471 for ; Mon, 9 Apr 2007 10:50:55 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l39EotAk020467; Mon, 9 Apr 2007 10:50:55 -0400 Date: Mon, 9 Apr 2007 10:50:55 -0400 Message-Id: <200704091450.l39EotAk020467@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <50B1CBA96870A34799A506B2313F26670B7D7814@ntht201e.siemenscomms.co.uk> (john.elwell@siemens.com) Subject: Re: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge? References: <50B1CBA96870A34799A506B2313F26670B7D7814@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: Elwell, John I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc. I just discovered that a very popular brand of phone doesn't keep track of multiple early dialogs at all. It just blithely considers them all to be the same. (Yes, the dialog events it generates are quite incorrect.) A test for that is going into our interoperability test server soon! Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Apr 11 10:50: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 1Hbe9C-0003cY-Hb; Wed, 11 Apr 2007 10:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULf9-00043x-Ia for bliss@ietf.org; Thu, 22 Mar 2007 07:41:00 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULez-0005UF-Eh for bliss@ietf.org; Thu, 22 Mar 2007 07:40:59 -0400 Received: from DF-BHD-04.exchange.corp.microsoft.com (157.54.63.169) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.85.3; Thu, 22 Mar 2007 04:40:48 -0700 Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([10.255.255.1]) by DF-BHD-04.exchange.corp.microsoft.com ([157.54.63.169]) with mapi; Thu, 22 Mar 2007 04:40:48 -0700 From: Sriram Parameswar To: "bliss@ietf.org" Date: Thu, 22 Mar 2007 04:40:47 -0700 Thread-Topic: Minutes from IETF 68 available Thread-Index: AcdsXfROlngsHGwQQO+11dnt6mpXQwAGIVsQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Wed, 11 Apr 2007 10:50:09 -0400 Subject: [BLISS] Minutes from IETF 68 available 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 On a related note - this is what I was trying to say at the mike at the BLI= SS meeting. Let us take services/applications and chunk them into classes f= or example DND could be chunked into "Presence based Routing" (example clas= s only!!). Then we can say - these are the drafts/SIP messages/payloads tha= t you need to support to solve these problems. This way we do not have to g= o through an exhaustive list of services/applications that exist in the wil= d - with their multitude of variations. Thanks, Sriram Date: Thu, 22 Mar 2007 09:36:24 +0100 From: Ben Campbell Subject: Re: [BLISS] Minutes from IETF 68 available To: Spencer Dawkins Cc: bliss@ietf.org Message-ID: Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; format=3Dflowed On Mar 22, 2007, at 8:47 AM, Spencer Dawkins wrote: > Sigh. Buffer overrun while typing... Thanks for asking, Dale. > > >> From: Spencer Dawkins >> >> I may not have said this clearly at the mike, but I agreed >> pretty strongly >> with Ben that organizing by service sends a message, and >> organizing by >> something technical, including text that says "we have seen the >> following >> services implementing using this header/whatever:" followed by a >> list. >> >> Uh, what? "organizing by service sends a message, and organizing by >> something technical" does what? >> >> Dale > > Organizing by something technical sends a different message. > > My point is TRYING to be that if we have a BCP spec that's called > DND, that's going to be more (semi-)normative than we would like > for it to be, but if we have a spec that says "this is how you > support method X, and we've seen people using method X to do DND > (along with these other services", that will probably be less > "normative". > > Ben - am I totally misunderstanding you on this? I think you understand me perfectly :-) I think the idea is that DND et al are _examples_ of common things that use the various SIP stuff. The important message is what SIP stuff you need to implement for general interoperability in a certain context. If we organize by service, we are putting the focus on the examples rather than the "what stuff I need to worry about as an implementer" info. > > Spencer > ------------------------------ _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss End of BLISS Digest, Vol 3, Issue 49 ************************************ _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Apr 11 17:50:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkiM-0001VJ-D7; Wed, 11 Apr 2007 17:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkiK-0001VB-3h for bliss@ietf.org; Wed, 11 Apr 2007 17:50:52 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbkiI-0002l8-QZ for bliss@ietf.org; Wed, 11 Apr 2007 17:50:52 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <20070411215050013003fcg9e>; Wed, 11 Apr 2007 21:50:50 +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 l3BLonLv008121 for ; Wed, 11 Apr 2007 17:50:49 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3BLonFh008117; Wed, 11 Apr 2007 17:50:49 -0400 Date: Wed, 11 Apr 2007 17:50:49 -0400 Message-Id: <200704112150.l3BLonFh008117@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [BLISS] Glitch in the BLISS mailing list 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 just (on 11 Apr) received a message sent by Sriram on 22 Mar. So beware that something may be malfunctioning in the BLISS mailing list. The headers are: Mail-from: From Sriram.Parameswar@microsoft.com Wed Apr 11 10:55:06 2007 Return-Path: Received: from localhost (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l3BEt5Lv009820 for ; Wed, 11 Apr 2007 10:55:06 -0400 Received: from mail.comcast.net [204.127.228.10] by localhost with POP3 (fetchmail-6.2.0) for worley@localhost (single-drop); Wed, 11 Apr 2007 10:55:06 -0400 (EDT) Received: from megatron.ietf.org ([156.154.16.145]) by alnrmxc24.comcast.net (alnrmxc24) with ESMTP id <20070411145011a2400jgdkue>; Wed, 11 Apr 2007 14:50:11 +0000 X-Originating-IP: [156.154.16.145] Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbe9C-0003cY-Hb; Wed, 11 Apr 2007 10:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULf9-00043x-Ia for bliss@ietf.org; Thu, 22 Mar 2007 07:41:00 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULez-0005UF-Eh for bliss@ietf.org; Thu, 22 Mar 2007 07:40:59 -0400 Received: from DF-BHD-04.exchange.corp.microsoft.com (157.54.63.169) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.85.3; Thu, 22 Mar 2007 04:40:48 -0700 Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([10.255.255.1]) by DF-BHD-04.exchange.corp.microsoft.com ([157.54.63.169]) with mapi; Thu, 22 Mar 2007 04:40:48 -0700 From: Sriram Parameswar To: "bliss@ietf.org" Date: Thu, 22 Mar 2007 04:40:47 -0700 Thread-Topic: Minutes from IETF 68 available Thread-Index: AcdsXfROlngsHGwQQO+11dnt6mpXQwAGIVsQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Wed, 11 Apr 2007 10:50:09 -0400 Subject: [BLISS] Minutes from IETF 68 available 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dragon.ariadne.com id l3BEt5Lv009820 It looks like the time was spent at megatron.ietf.org, but the Received header in question claims to have received the message from stiedprmman1.va.neustar.com, which is not the host in the previous Received. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Apr 11 18:35: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 1HblPu-0005Xn-IZ; Wed, 11 Apr 2007 18:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HblPs-0005XY-Vb for bliss@ietf.org; Wed, 11 Apr 2007 18:35:52 -0400 Received: from [2001:418:1:0:230:48ff:fe82:537e] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HblPn-0001bN-EC for bliss@ietf.org; Wed, 11 Apr 2007 18:35:52 -0400 Received: from [192.103.16.81] ([192.103.16.81]) (authenticated bits=0) by nagasaki.bogus.com (8.13.8/8.13.8) with ESMTP id l3BMZNam095628; Wed, 11 Apr 2007 22:35:23 GMT (envelope-from joelja@bogus.com) Message-ID: <461D62A1.8020105@bogus.com> Date: Wed, 11 Apr 2007 15:35:13 -0700 From: Joel Jaeggli User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Glitch in the BLISS mailing list References: <200704112150.l3BLonFh008117@dragon.ariadne.com> In-Reply-To: <200704112150.l3BLonFh008117@dragon.ariadne.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/3074/Wed Apr 11 21:35:22 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Dale.Worley@comcast.net wrote: > I just (on 11 Apr) received a message sent by Sriram on 22 Mar. So > beware that something may be malfunctioning in the BLISS mailing list. In general if you see a message stopped at megatron for several days it's an indication that it was flagged for moderation . If this happens regularly or for long periods of time I would encourage you to provide feedback to the iad and or the iaoc who are responsible for contract with neustar who provides this service. joel > The headers are: > > Mail-from: From Sriram.Parameswar@microsoft.com Wed Apr 11 10:55:06 2007 > Return-Path: > Received: from localhost (dragon.ariadne.com [127.0.0.1]) > by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l3BEt5Lv009820 > for ; Wed, 11 Apr 2007 10:55:06 -0400 > Received: from mail.comcast.net [204.127.228.10] > by localhost with POP3 (fetchmail-6.2.0) > for worley@localhost (single-drop); Wed, 11 Apr 2007 10:55:06 -0400 (EDT) > Received: from megatron.ietf.org ([156.154.16.145]) > by alnrmxc24.comcast.net (alnrmxc24) with ESMTP > id <20070411145011a2400jgdkue>; Wed, 11 Apr 2007 14:50:11 +0000 > X-Originating-IP: [156.154.16.145] > Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) > by megatron.ietf.org with esmtp (Exim 4.43) > id 1Hbe9C-0003cY-Hb; Wed, 11 Apr 2007 10:50:10 -0400 > Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) > by megatron.ietf.org with esmtp (Exim 4.43) id 1HULf9-00043x-Ia > for bliss@ietf.org; Thu, 22 Mar 2007 07:41:00 -0400 > Received: from mail7.exchange.microsoft.com ([131.107.1.27] > helo=mail.exchange.microsoft.com) > by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULez-0005UF-Eh > for bliss@ietf.org; Thu, 22 Mar 2007 07:40:59 -0400 > Received: from DF-BHD-04.exchange.corp.microsoft.com (157.54.63.169) by > DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft > SMTP Server (TLS) id 8.1.85.3; Thu, 22 Mar 2007 04:40:48 -0700 > Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([10.255.255.1]) by > DF-BHD-04.exchange.corp.microsoft.com ([157.54.63.169]) with mapi; > Thu, 22 Mar 2007 04:40:48 -0700 > From: Sriram Parameswar > To: "bliss@ietf.org" > Date: Thu, 22 Mar 2007 04:40:47 -0700 > Thread-Topic: Minutes from IETF 68 available > Thread-Index: AcdsXfROlngsHGwQQO+11dnt6mpXQwAGIVsQ > Message-ID: > References: > In-Reply-To: > Accept-Language: en-US > Content-Language: en-US > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > acceptlanguage: en-US > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > X-Spam-Score: 0.5 (/) > X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 > X-Mailman-Approved-At: Wed, 11 Apr 2007 10:50:09 -0400 > Subject: [BLISS] Minutes from IETF 68 available > 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 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by dragon.ariadne.com id l3BEt5Lv009820 > > It looks like the time was spent at megatron.ietf.org, but the > Received header in question claims to have received the message from > stiedprmman1.va.neustar.com, which is not the host in the previous > Received. > > 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 Wed Apr 11 21:50: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 1HboSc-0003h8-3r; Wed, 11 Apr 2007 21:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HboSa-0003ge-74 for bliss@ietf.org; Wed, 11 Apr 2007 21:50:52 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HboSX-00018A-VA for bliss@ietf.org; Wed, 11 Apr 2007 21:50:52 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070412015048m1400inicoe>; Thu, 12 Apr 2007 01:50:49 +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 l3C1olLv025689 for ; Wed, 11 Apr 2007 21:50:47 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3C1olnO025685; Wed, 11 Apr 2007 21:50:47 -0400 Date: Wed, 11 Apr 2007 21:50:47 -0400 Message-Id: <200704120150.l3C1olnO025685@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <461D62A1.8020105@bogus.com> (joelja@bogus.com) Subject: Re: [BLISS] Glitch in the BLISS mailing list References: <200704112150.l3BLonFh008117@dragon.ariadne.com> <461D62A1.8020105@bogus.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: Joel Jaeggli In general if you see a message stopped at megatron for several days it's an indication that it was flagged for moderation . If this happens regularly or for long periods of time I would encourage you to provide feedback to the iad and or the iaoc who are responsible for contract with neustar who provides this service. I'll look into that. BTW, do you know why neustar doesn't appear in any of the Received headers? As they seem to be one of the most important processing steps, they should be properly logged. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Apr 11 22:40: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 1HbpEK-0004Im-6N; Wed, 11 Apr 2007 22:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbpEJ-0004Ih-04 for bliss@ietf.org; Wed, 11 Apr 2007 22:40:11 -0400 Received: from [2001:418:1:0:230:48ff:fe82:537e] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbpEG-0000SK-I7 for bliss@ietf.org; Wed, 11 Apr 2007 22:40:10 -0400 Received: from [192.168.1.101] (c-69-181-75-16.hsd1.ca.comcast.net [69.181.75.16]) (authenticated bits=0) by nagasaki.bogus.com (8.13.8/8.13.8) with ESMTP id l3C2e6l1096983; Thu, 12 Apr 2007 02:40:06 GMT (envelope-from joelja@bogus.com) Message-ID: <461D9C01.8050702@bogus.com> Date: Wed, 11 Apr 2007 19:40:01 -0700 From: Joel Jaeggli User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Glitch in the BLISS mailing list References: <200704112150.l3BLonFh008117@dragon.ariadne.com> <461D62A1.8020105@bogus.com> <200704120150.l3C1olnO025685@dragon.ariadne.com> In-Reply-To: <200704120150.l3C1olnO025685@dragon.ariadne.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/3078/Thu Apr 12 00:44:59 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Dale.Worley@comcast.net wrote: > From: Joel Jaeggli > > In general if you see a message stopped at megatron for several days > it's an indication that it was flagged for moderation . If this happens > regularly or for long periods of time I would encourage you to provide > feedback to the iad and or the iaoc who are responsible for contract > with neustar who provides this service. > > I'll look into that. BTW, do you know why neustar doesn't appear in > any of the Received headers? As they seem to be one of the most > important processing steps, they should be properly logged. The ietf secretariat servers (I believe there are 9 in total) are hosted by neustar secretariat services (formerly fortec) a subsidiary of neustar. > 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 Apr 13 09:00:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLOP-0002Uf-Un; Fri, 13 Apr 2007 09:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLOO-0002UM-9I for bliss@ietf.org; Fri, 13 Apr 2007 09:00:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLOM-0008CU-LN for bliss@ietf.org; Fri, 13 Apr 2007 09:00:44 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2007 06:00:42 -0700 X-IronPort-AV: i="4.14,407,1170662400"; d="scan'208"; a="369729135:sNHT47760760" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3DD0g0K023690; Fri, 13 Apr 2007 06:00:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3DD0XZT007998; Fri, 13 Apr 2007 13:00:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 06:00:33 -0700 Received: from [64.101.174.161] ([64.101.174.161]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 06:00:33 -0700 Message-ID: <461F7EEF.6090004@cisco.com> Date: Fri, 13 Apr 2007 09:00:31 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Jaeggli Subject: Re: [BLISS] Glitch in the BLISS mailing list References: <200704112150.l3BLonFh008117@dragon.ariadne.com> <461D62A1.8020105@bogus.com> <200704120150.l3C1olnO025685@dragon.ariadne.com> <461D9C01.8050702@bogus.com> In-Reply-To: <461D9C01.8050702@bogus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 13:00:33.0388 (UTC) FILETIME=[B8B262C0:01C77DCB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1791; t=1176469242; x=1177333242; c=relaxed/simple; s=sjdkim4002; 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]=20Glitch=20in=20the=20BLISS=20mailing=20list |Sender:=20; bh=FHuR/XznX1ZybZ8iGESA3onpkV3geWM365xzYd7u4bg=; b=E1Jm/REktJmsrDhs8UANsoPFHP7d+pmV3jdX7Qh3HgNKMGmCOuGlKu+L2WJh5lNkcIEkOPeA F8bdOcVBYhDMkuiXnHhEC/CXiHlP5MMkz86d4H6N+CzoIYKm5QVj6f1z; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Sorry guys - this was my fault. This mail got flagged for moderator approval. The email letting me know there is a problem ended up in my 'unclassified' folder that I seldom look at. So, it sat there for a while. I've added a filter for these bounce notices so I will see them right away now. -Jonathan R. Joel Jaeggli wrote: > Dale.Worley@comcast.net wrote: > >> From: Joel Jaeggli >> >> In general if you see a message stopped at megatron for several days >> it's an indication that it was flagged for moderation . If this happens >> regularly or for long periods of time I would encourage you to provide >> feedback to the iad and or the iaoc who are responsible for contract >> with neustar who provides this service. >> >>I'll look into that. BTW, do you know why neustar doesn't appear in >>any of the Received headers? As they seem to be one of the most >>important processing steps, they should be properly logged. > > > The ietf secretariat servers (I believe there are 9 in total) are hosted > by neustar secretariat services (formerly fortec) a subsidiary of neustar. > > >>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 > -- 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