From ecrit-bounces@ietf.org Tue Jan 03 11:50:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpMG-0004rh-OS; Tue, 03 Jan 2006 11:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpMD-0004qL-Cd for ecrit@megatron.ietf.org; Tue, 03 Jan 2006 11:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22083 for ; Tue, 3 Jan 2006 11:48:43 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtpRW-00024O-RQ for ecrit@ietf.org; Tue, 03 Jan 2006 11:55:27 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2006 08:35:41 -0800 X-IronPort-AV: i="3.99,326,1131350400"; d="scan'208"; a="386524977:sNHT999926968" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k03GZdZg007719; Tue, 3 Jan 2006 08:35:40 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 11:35:39 -0500 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: [Ecrit] Issue 10: Design of Non-Emergency Components Date: Tue, 3 Jan 2006 11:35:38 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3EF3312@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 10: Design of Non-Emergency Components Thread-Index: AcYMg/vSSLU1vrkUQSS4v/8JYO90OQD/q4lw From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" , "Roger Marshall" X-OriginalArrivalTime: 03 Jan 2006 16:35:39.0654 (UTC) FILETIME=[BB588A60:01C61083] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This statement is rather cryptic and should be rewritten. I could take this to mean that, while call routing has been designed to give priority to emergency calls in call processing, there is no priority given to processing of location lookups of emergency versus Starbucks. Or is it just saying, if the functional element is not labeled "emergency", it is not guaranteed to work? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Andrew Newton > Sent: Thursday, December 29, 2005 9:25 AM > To: Roger Marshall > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components >=20 >=20 > On Dec 28, 2005, at 7:20 PM, Roger Marshall wrote: >=20 > > Andy: > > > > Issue 10: Design of Non-Emergency Components > > (http://www.ietf-ecrit.org:8080/ecrit-req/issue10) > > > > "There are no requirements regarding the resilience of the=20 > emergency=20 > > call routing process as it relates to inputs that have not been=20 > > designed for the purpose of emergency call routing." > > > > I'm not exactly sure what this issue is getting at... a couple of=20 > > thoughts, 1. are we talking about resilience against inadvertant or=20 > > on-purpose mis-use, (in which case it seems like a security=20 > concern),=20 > > or 2. do you mean, that the MP should be resilient in order=20 > to support=20 > > other types of use, besides just emergency use? >=20 > I think I just need to completely restate the concern. >=20 > Location information services and sighting services will be=20 > present in the network for more than just emergency services,=20 > such as the much talked about "Where is the nearest=20 > Starbucks?" service. While the mapping service may only be=20 > used and present for emergency call routing, these location=20 > information services it relies upon have multiple uses.=20 > Therefore, the mapping protocol should not require addresses=20 > in these services to be contorted or transmogrified in any =20 > way that would reasonably conflict with these other services. =20 > Thinking this through, perhaps this only applies to civic=20 > addresses as geo-spatial addresses can be algorithmically=20 > converted from one format to another. >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 03 17:44:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtutJ-0004Jq-Ss; Tue, 03 Jan 2006 17:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ett6b-0003Wp-Ip; Tue, 03 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28580; Tue, 3 Jan 2006 15:48:51 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EttBu-0003B1-4Q; Tue, 03 Jan 2006 15:55:35 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ett6X-00005E-Ik; Tue, 03 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Tue, 03 Jan 2006 17:44:28 -0500 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-02.txt Pages : 27 Date : 2006-1-3 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-3104505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-3104505.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Wed Jan 04 09:13:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9O7-0007ol-RM; Wed, 04 Jan 2006 09:13:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9O5-0007oc-Oc for ecrit@megatron.ietf.org; Wed, 04 Jan 2006 09:13:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04994 for ; Wed, 4 Jan 2006 09:11:57 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu9TZ-0001Ol-J5 for ecrit@ietf.org; Wed, 04 Jan 2006 09:18:54 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 04 Jan 2006 09:12:35 -0500 id 0158802C.43BBD7D3.00007405 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3EF3312@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3EF3312@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C04C624-9777-4323-8675-36E628FCF42E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components Date: Wed, 4 Jan 2006 09:12:30 -0500 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jan 3, 2006, at 11:35 AM, Michael Hammer ((mhammer)) wrote: > This statement is rather cryptic and should be rewritten. > > I could take this to mean that, while call routing has been > designed to > give priority to emergency calls in call processing, there is no > priority given to processing of location lookups of emergency versus > Starbucks. > > Or is it just saying, if the functional element is not labeled > "emergency", it is not guaranteed to work? I wasn't trying to say that at all. Essentially, there are databases of civic addresses within location information servers. These databases may be used for multiple purposes and multiple applications. The mapping protocol should not require that data within these databases be transformed or modified in any unusual or unreasonable way just so the mapping protocol may use the data. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 04 09:38:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9mQ-0004vy-7f; Wed, 04 Jan 2006 09:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9mN-0004vh-Un for ecrit@megatron.ietf.org; Wed, 04 Jan 2006 09:38:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08237 for ; Wed, 4 Jan 2006 09:37:03 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu9rr-0002LV-DL for ecrit@ietf.org; Wed, 04 Jan 2006 09:44:00 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Eu9mJ-0003EH-9Q; Wed, 04 Jan 2006 08:38:15 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components Date: Wed, 4 Jan 2006 09:35:09 -0500 Message-ID: <03c101c6113c$128342e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8C04C624-9777-4323-8675-36E628FCF42E@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYROTguqnJYvwZuSi+FPcVVi++ohQAAP3Sg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am full agreement with this, and it's pretty important. What is interesting is that it represents a change from what is now done. In North America, and in some other areas, the form of address used in the emergency system is DIFFERENT from the form commonly used for other purposes. There are mostly historical reasons for much of the differences. We have had quite a bit of resistance within the NENA community for the idea that if we are to have a really effective system for all kinds of new services based on IP, then the location information must be useful beyond just emergency calls. Location is commercially valuable, but only if the information is not obscured in some way. The current systems do. We've started making this transition in the NENA i2 standard. Location as used within the IP world is a new form that is closer to common usage. We have translation to the existing form because we can't change out the current systems wholesale (in fact i2 is designed to not require any changes at the PSAP). I do have to point out that you can't equate this with postal addresses; the address for postal delivery is NOT always the address for dispatch of emergency responders. The database SHOULD be able to store enough data so that translations are possible, because when you ask someone for a location, they often respond with a postal address. Specifically, for North America, we need to have the jurisdictional community name (actual city/town/...), which may be different from the post office name. The database should store both. The mapping protocol only needs the jurisdictional community name. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Wednesday, January 04, 2006 9:12 AM To: Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components On Jan 3, 2006, at 11:35 AM, Michael Hammer ((mhammer)) wrote: > This statement is rather cryptic and should be rewritten. > > I could take this to mean that, while call routing has been > designed to > give priority to emergency calls in call processing, there is no > priority given to processing of location lookups of emergency versus > Starbucks. > > Or is it just saying, if the functional element is not labeled > "emergency", it is not guaranteed to work? I wasn't trying to say that at all. Essentially, there are databases of civic addresses within location information servers. These databases may be used for multiple purposes and multiple applications. The mapping protocol should not require that data within these databases be transformed or modified in any unusual or unreasonable way just so the mapping protocol may use the data. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 04 10:05:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuACY-0002sE-UL; Wed, 04 Jan 2006 10:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuACY-0002s9-A0 for ecrit@megatron.ietf.org; Wed, 04 Jan 2006 10:05:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11627 for ; Wed, 4 Jan 2006 10:04:08 -0500 (EST) 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 1EuAI0-0003MY-6O for ecrit@ietf.org; Wed, 04 Jan 2006 10:11:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2006 07:05:09 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k04F57Zk004142; Wed, 4 Jan 2006 07:05:08 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 10:05:07 -0500 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: [Ecrit] Issue 10: Design of Non-Emergency Components Date: Wed, 4 Jan 2006 10:05:06 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3EF35B9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 10: Design of Non-Emergency Components Thread-Index: AcYROTguqnJYvwZuSi+FPcVVi++ohQAAP3SgAAFfn7A= From: "Michael Hammer \(mhammer\)" To: , "Andrew Newton" X-OriginalArrivalTime: 04 Jan 2006 15:05:07.0769 (UTC) FILETIME=[401A6A90:01C61140] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Interesting. I would have never got this out of the current wording. Furthermore, I would support making this a clear statement. Someone needs to point out to the NENA community that specialized software/hardware designed specifically for government use *** COSTS MORE ***. General purpose off the shelf (commonly called COTS) is known to be more generally useful and less expensive because it is mass produced by the competitive marketplace. Perhaps you could add words to that effect in the justification. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, January 04, 2006 9:35 AM > To: 'Andrew Newton'; Michael Hammer (mhammer) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components >=20 > I am full agreement with this, and it's pretty important. =20 > What is interesting is that it represents a change from what=20 > is now done. > In North America, and in some other areas, the form of=20 > address used in the emergency system is DIFFERENT from the=20 > form commonly used for other purposes. There are mostly=20 > historical reasons for much of the differences. > We have had quite a bit of resistance within the NENA=20 > community for the idea that if we are to have a really=20 > effective system for all kinds of new services based on IP,=20 > then the location information must be useful beyond just=20 > emergency calls. Location is commercially valuable, but only=20 > if the information is not obscured in some way. The current=20 > systems do. >=20 > We've started making this transition in the NENA i2 standard.=20 > Location as used within the IP world is a new form that is=20 > closer to common usage. We have translation to the existing=20 > form because we can't change out the current systems=20 > wholesale (in fact i2 is designed to not require any changes=20 > at the PSAP). >=20 > I do have to point out that you can't equate this with postal=20 > addresses; the address for postal delivery is NOT always the=20 > address for dispatch of emergency responders. The database=20 > SHOULD be able to store enough data so that translations are=20 > possible, because when you ask someone for a location, they=20 > often respond with a postal address. Specifically, for North=20 > America, we need to have the jurisdictional community name=20 > (actual city/town/...), which may be different from the post=20 > office name. The database should store both. The mapping=20 > protocol only needs the jurisdictional community name. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Andrew Newton > Sent: Wednesday, January 04, 2006 9:12 AM > To: Michael Hammer (mhammer) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components >=20 >=20 > On Jan 3, 2006, at 11:35 AM, Michael Hammer ((mhammer)) wrote: >=20 > > This statement is rather cryptic and should be rewritten. > > > > I could take this to mean that, while call routing has been=20 > designed=20 > > to give priority to emergency calls in call processing, there is no=20 > > priority given to processing of location lookups of=20 > emergency versus=20 > > Starbucks. > > > > Or is it just saying, if the functional element is not labeled=20 > > "emergency", it is not guaranteed to work? >=20 > I wasn't trying to say that at all. >=20 > Essentially, there are databases of civic addresses within=20 > location information servers. These databases may be used=20 > for multiple purposes and multiple applications. The mapping=20 > protocol should not require that data within these databases=20 > be transformed or modified in any unusual or unreasonable way=20 > just so the mapping protocol may use the data. >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 04 10:09:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAGn-0003mB-AD; Wed, 04 Jan 2006 10:09:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAGl-0003m2-Jc for ecrit@megatron.ietf.org; Wed, 04 Jan 2006 10:09:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12319 for ; Wed, 4 Jan 2006 10:08:28 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuAME-0003Wq-On for ecrit@ietf.org; Wed, 04 Jan 2006 10:15:24 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 04 Jan 2006 10:09:04 -0500 id 01588001.43BBE510.00000277 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] WG: ECRIT Interim Meeting Date: Wed, 4 Jan 2006 10:09:28 -0500 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Dec 30, 2005, at 2:12 PM, Tschofenig, Hannes wrote: > 5) Architectural Aspects > ------------------------ > > Location-to-URL Mapping Architecture and Framework > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping- > arch > -00.txt I'd like to see this discussed before items in #3 as it drastically affects the outcome of any technical proposal. > Emergency Context Routing of Internet Technologies Architecture > Considerations > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch- > conside > rations-01.txt Though I haven't discussed this with my co-author, I'm not sure we need to discuss this draft at the interim. My understanding of the feedback from the last IETF meeting was that people found this valuable as a draft that attempts to explain how the parts are glued together but did not find the issues raised within it very valuable. Hence, it could stand some rewriting and the issues within it should really be dealt with in the other documents. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 04 13:44:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDcg-00063V-IE; Wed, 04 Jan 2006 13:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDce-000635-HP for ecrit@megatron.ietf.org; Wed, 04 Jan 2006 13:44:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11781 for ; Wed, 4 Jan 2006 13:43:17 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuDiA-0003uQ-U4 for ecrit@ietf.org; Wed, 04 Jan 2006 13:50:16 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k04IiFGt009393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jan 2006 13:44:24 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k04Ii64N017820; Wed, 4 Jan 2006 13:44:11 -0500 Message-ID: <43BC1797.5070507@cs.columbia.edu> Date: Wed, 04 Jan 2006 13:44:39 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] WG: ECRIT Interim Meeting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My intention is to update -mapping-arch- a bit to include the generic aspects as well (the ones that simply involve the role of mapping in the call flow for emergency calls, as discussed on the ecrit list). I hope that these are less controversial... I agree that having an architecture discussion first would be helpful, as we seem to have somewhat different perspectives that tend to inform our mental protocol pictures. Andrew Newton wrote: > > On Dec 30, 2005, at 2:12 PM, Tschofenig, Hannes wrote: >> 5) Architectural Aspects >> ------------------------ >> >> Location-to-URL Mapping Architecture and Framework >> http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch >> -00.txt > > I'd like to see this discussed before items in #3 as it drastically > affects the outcome of any technical proposal. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 05 04:25:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRMx-0002Dj-Oi; Thu, 05 Jan 2006 04:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRMw-0002De-P9 for ecrit@megatron.ietf.org; Thu, 05 Jan 2006 04:25:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16559 for ; Thu, 5 Jan 2006 04:23:58 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRSY-0002Eu-9n for ecrit@ietf.org; Thu, 05 Jan 2006 04:31:05 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k059OvMg015742; Thu, 5 Jan 2006 10:24:57 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k059Ot51018538; Thu, 5 Jan 2006 10:24:57 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 10:24:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] WG: ECRIT Interim Meeting Date: Thu, 5 Jan 2006 10:24:55 +0100 Message-ID: Thread-Topic: [Ecrit] WG: ECRIT Interim Meeting Thread-Index: AcYRQN8colU3bGYiQgG3Wm0nyphhzQAEcueQ From: "Tschofenig, Hannes" To: "Andrew Newton" X-OriginalArrivalTime: 05 Jan 2006 09:24:55.0467 (UTC) FILETIME=[E3D60FB0:01C611D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy thanks for the feedback.=20 i think that everyone agrees that we need to focus on the requirements = and the security draft. hopefully we make good progress to to discuss = the other aspects as well. for me it seems to be ok to discuss = architectural aspects before getting to the solution specific = components.=20 james suggested that we have discussions about requirements and security = on both days. the second day can be used to summarize and rethink what = we concluded on the first day.=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Andrew Newton [mailto:andy@hxr.us]=20 > Gesendet: Mittwoch, 4. Januar 2006 16:09 > An: Tschofenig, Hannes > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] WG: ECRIT Interim Meeting=20 >=20 >=20 > On Dec 30, 2005, at 2:12 PM, Tschofenig, Hannes wrote: > > 5) Architectural Aspects > > ------------------------ > > > > Location-to-URL Mapping Architecture and Framework > >=20 > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-=20 > > arch > > -00.txt >=20 > I'd like to see this discussed before items in #3 as it drastically =20 > affects the outcome of any technical proposal. >=20 > > Emergency Context Routing of Internet Technologies Architecture > > Considerations > > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-=20 > > conside > > rations-01.txt >=20 > Though I haven't discussed this with my co-author, I'm not sure we =20 > need to discuss this draft at the interim. My understanding of the =20 > feedback from the last IETF meeting was that people found this =20 > valuable as a draft that attempts to explain how the parts are glued =20 > together but did not find the issues raised within it very=20 > valuable. =20 > Hence, it could stand some rewriting and the issues within it should =20 > really be dealt with in the other documents. >=20 > -andy >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 14 00:32:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exe1R-0001Fv-AS; Sat, 14 Jan 2006 00:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exe1O-0001EP-KV for ecrit@megatron.ietf.org; Sat, 14 Jan 2006 00:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19480 for ; Sat, 14 Jan 2006 00:30:51 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exe8p-0007RC-Ga for ecrit@ietf.org; Sat, 14 Jan 2006 00:39:57 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 13 Jan 2006 21:31:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components Date: Fri, 13 Jan 2006 21:31:54 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750401BB92@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 10: Design of Non-Emergency Components Thread-Index: AcYROTguqnJYvwZuSi+FPcVVi++ohQAAP3SgAAFfn7AB4e0vkA== From: "Roger Marshall" To: "Michael Hammer \(mhammer\)" , , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Issue 10 (ref. http://www.ietf-ecrit.org:8080/ecrit-req/issue10) In reference to the thread below, how then should the proposed text be worded? Consider the following attempt at capturing what Andy is suggesting: "Rxx. No Modification of Location Databases: Databases containing civic location data MAY be used for multiple purposes multiple applications, in addition to the purpose of routing E9-1-1 calls. Motivation: The mapping protocol should not require that data within these databases be transformed or modified in any unusual or unreasonable way in order for the mapping protocol to use the data." Comments welcomed, of course. Roger. =20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Michael Hammer (mhammer) >Sent: Wednesday, January 04, 2006 7:05 AM >To: br@brianrosen.net; Andrew Newton >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components > >Interesting. I would have never got this out of the current wording. >Furthermore, I would support making this a clear statement. =20 >Someone needs to point out to the NENA community that=20 >specialized software/hardware designed specifically for=20 >government use *** COSTS MORE ***. General purpose off the=20 >shelf (commonly called COTS) is known to be more generally=20 >useful and less expensive because it is mass produced by the=20 >competitive marketplace. Perhaps you could add words to that=20 >effect in the justification. > >Mike > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Wednesday, January 04, 2006 9:35 AM >> To: 'Andrew Newton'; Michael Hammer (mhammer) >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components >>=20 >> I am full agreement with this, and it's pretty important. =20 >> What is interesting is that it represents a change from what is now=20 >> done. >> In North America, and in some other areas, the form of=20 >address used in=20 >> the emergency system is DIFFERENT from the form commonly used for=20 >> other purposes. There are mostly historical reasons for much of the=20 >> differences. >> We have had quite a bit of resistance within the NENA community for=20 >> the idea that if we are to have a really effective system for all=20 >> kinds of new services based on IP, then the location=20 >information must=20 >> be useful beyond just emergency calls. Location is commercially=20 >> valuable, but only if the information is not obscured in some way. =20 >> The current systems do. >>=20 >> We've started making this transition in the NENA i2 standard.=20 >> Location as used within the IP world is a new form that is=20 >closer to=20 >> common usage. We have translation to the existing form because we=20 >> can't change out the current systems wholesale (in fact i2=20 >is designed=20 >> to not require any changes at the PSAP). >>=20 >> I do have to point out that you can't equate this with postal=20 >> addresses; the address for postal delivery is NOT always the address=20 >> for dispatch of emergency responders. The database SHOULD=20 >be able to=20 >> store enough data so that translations are possible, because=20 >when you=20 >> ask someone for a location, they often respond with a postal=20 >address. =20 >> Specifically, for North America, we need to have the jurisdictional=20 >> community name (actual city/town/...), which may be=20 >different from the=20 >> post office name. The database should store both. The mapping=20 >> protocol only needs the jurisdictional community name. >>=20 >> Brian >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Andrew Newton >> Sent: Wednesday, January 04, 2006 9:12 AM >> To: Michael Hammer (mhammer) >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components >>=20 >>=20 >> On Jan 3, 2006, at 11:35 AM, Michael Hammer ((mhammer)) wrote: >>=20 >> > This statement is rather cryptic and should be rewritten. >> > >> > I could take this to mean that, while call routing has been >> designed >> > to give priority to emergency calls in call processing,=20 >there is no=20 >> > priority given to processing of location lookups of >> emergency versus >> > Starbucks. >> > >> > Or is it just saying, if the functional element is not labeled=20 >> > "emergency", it is not guaranteed to work? >>=20 >> I wasn't trying to say that at all. >>=20 >> Essentially, there are databases of civic addresses within location=20 >> information servers. These databases may be used for multiple=20 >> purposes and multiple applications. The mapping protocol should not=20 >> require that data within these databases be transformed or=20 >modified in=20 >> any unusual or unreasonable way just so the mapping protocol may use=20 >> the data. >>=20 >> -andy >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 14 00:51:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeKP-00062h-7M; Sat, 14 Jan 2006 00:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExeKM-00062c-Vm for ecrit@megatron.ietf.org; Sat, 14 Jan 2006 00:51:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20525 for ; Sat, 14 Jan 2006 00:50:27 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExeRo-00080V-Il for ecrit@ietf.org; Sat, 14 Jan 2006 00:59:33 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 13 Jan 2006 21:51:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Text for I7 Date: Fri, 13 Jan 2006 21:51:38 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750401BB94@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Text for I7 Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyx5UwR0gEPJfGtA= From: "Roger Marshall" To: "Brian Rosen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Hannes.Tschofenig@siemens.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Issue 17 (ref. http://www.ietf-ecrit.org:8080/ecrit-req/issue17).=20 (previous numbering at time issue was created) I7. Traceable resolution: The entity requesting mapping SHOULD be able to determine the entity or entities who provided the emergency address resolution information. (current numbering as of requirements draft version -02) Ma9. Traceable resolution: The entity requesting mapping SHOULD be able to determine the entity or entities who provided the emergency address resolution information. Motivation: To provide operational traceability in case of errors. =20 The original issue as entered: (Hannes:) We should be a bit more specific about this requirement. What is the=20 impact of this requirement? Is it sufficient to add an attribute to the=20 returned object that the mapping was provided by X or do we require a digital=20 signature of the entity that created the mapping?=20 I welcome comments from the list in order to see if we can flesh out the outstanding request for additional explanation for Ma9. I'd like to get to a resolution, otherwise, without more clarification, is there support to delete Ma9 altogether? Thanks. Roger Marshall. >-----Original Message----- >From: Roger Marshall=20 >Sent: Wednesday, October 19, 2005 4:18 PM >To: 'Brian Rosen'; ecrit@ietf.org >Subject: RE: [Ecrit] Text for I7 > >Brian: >Please reference issue #17 on the issue tracker, at:=20 >http://www.ietf-ecrit.org:8080/ecrit-req/ > >Can you specify some add'l detail for this requirement? > > >Roger Marshall. > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Brian Rosen >>Sent: Wednesday, May 18, 2005 6:47 AM >>To: ecrit@ietf.org >>Subject: [Ecrit] Text for I7 >> >>I7. Traceable resolution: The entity requesting mapping=20 >SHOULD be able=20 >>to definitively and securely determine the entity or entities who=20 >>provided the emergency address resolution information. >> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 11:01:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAJC-0006TF-Vq; Sun, 15 Jan 2006 11:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAJA-0006Sv-L5 for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 11:00:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24307 for ; Sun, 15 Jan 2006 10:58:39 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ext0T-00038v-2V for ecrit@ietf.org; Sat, 14 Jan 2006 16:32:20 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 15:24:06 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 14 Jan 2006 15:24:05 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 15:24:05 -0600 Message-ID: From: "Winterbottom, James" To: "Roger Marshall" , "Ted Hardie" , , "James M. Polk" , Date: Sat, 14 Jan 2006 15:24:01 -0600 Subject: RE: [Ecrit] Issue 15 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 14 Jan 2006 21:24:05.0543 (UTC) FILETIME=[D900E370:01C61950] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 15 Thread-Index: AcYIAOEj38/Ie52JR5qJWhi1Z4Zc1wQ2q5ZwAB02CSA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger, I am still unconvinced that this is anything other than a provisioning requirement, that aside, I think that if the requirement is to stand it should be clear in the requirement itself what you are validating it for. The current requirement simply says that it need to be done before a call, which is a when and not a what. So I think I would add to the requirement something like: "to ensure that the location can be mapped to a PSAP". Cheers James > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Saturday, 14 January 2006 6:30 PM > To: Ted Hardie; br@brianrosen.net; Winterbottom, James; James M. Polk; > ecrit@ietf.org > Subject: RE: [Ecrit] Issue 15 >=20 > Issue 15, (http://www.ietf-ecrit.org:8080/ecrit-req/issue15): >=20 > Changing subject line to include the issue number (15), for tracking. > We've generated lots of discussion on this subject, and from what I can > tell, as a result it looks like most folks think that there is a place > for validation under certain (maybe alternate) circumstances. I'm > therefore leaving the following requirement intact: >=20 > Lo1. Validation of Civic Location: It MUST be possible to validate a > civic location prior to its use in an actual emergency call. >=20 > Motivation: Location validation provides an opportunity to help > assure ahead of time, whether successful mapping to the > appropriate PSAP will likely occur when it is required. > Validation may also help to avoid delays during emergency call > setup due to invalid locations. >=20 > If there is disagreement with leaving this in, please comment. >=20 > Thanks. >=20 > Roger Marshall. >=20 > >-----Original Message----- > >From: Ted Hardie [mailto:hardie@qualcomm.com] > >Sent: Friday, December 23, 2005 12:38 PM > >To: br@brianrosen.net; 'Winterbottom, James'; 'James M. Polk'; > >Roger Marshall; ecrit@ietf.org > >Subject: RE: [Ecrit] Issue > > > >At 8:22 AM -0500 12/23/05, Brian Rosen wrote: > >>This is not a provisioning issue, at least not a provisioning > >issue for > >>the mapping database. In some circumstances, it's a > >provisioning issue > >>for a LIS, but with respect to the mapping protocol, it's an > >>operational requirement. > >> > >>Repeating myself, the requirement is that ecrit provides a > >mechanism to > >>confirm the validity of an address. Validity in this case means: > >> If the address was to be used for an emergency call, it > >would be > >>recognized in the database and a valid mapping would be returned > >> If the address was used for dispatch, it is an address that the > >>responders would recognize and be able to send help > > > >Thanks for very clearly separating those two out. The first > >actually breaks into two cases: 1) there is enough data > >provide a mapping, but the data are incomplete or incorrect in > >some way known to the system; 2) the data are correct and > >complete and in some way known. > > > >How often case one happens depends a lot on the way in which > >the locality has organized its PSAPs. If a municipality has > >a single PSAP, a correct mapping can be returned if there is a > >municipality in the location object, even if no other data is present. > >There are lots of other cases where partial information or > >partially correct information can still be sufficient to > >generate a good mapping; as long as you do not presume that > >the query is hamstrung to be exact-match only, good results > >can come from incomplete data in non-trivial numbers of cases. > > > >What you want to return to a query in the case of "available > >mapping, but a location object that is incomplete" depends on > >whether the query is associated with an actual emergency or is > >specific to validation. > > > >If the query being made is specifically a validation query, it > >should return the mapping and an indication that the data is > >not complete (or elements are not correct); if the query is an > >emergency query, it should simply return the mapping. > >Distinguishing between the two cases with a query flag is an > >obvious choice, and I think most of us believe that's a good > >thing to do. > > > >Going beyond that to your second case, there is a question > >about whether what validation query is testing against is the > >address's correctness/completeness for dispatch. I think it is > >logical to assume it is. > > > >I *think* then, what the requirement boils down to is that the > >error results for negative returns to validation queries > >should distinguish among location objects that are too > >incomplete for dispatch, those that are complete but appear to > >have data that is not in the database, and those in which the > >data are known to be wrong (cites a floor in a building higher > >than is possible, for example). > > > >We could go beyond that, to citing which data elements are > >known to be wrong, and there are cases where we might be able > >to cite which data elements are missing (though this gets > >complicated fast, as you will run into lots of "Must include > >either municipality or county name with a street address). I > >personally suspect punting that level of specificity to a free > >text field is okay; you'll only get it when validating an > >address, and the most valuable data may actually be who to > >call to work out the problem (rather than possibly difficult > >to interpret data). > > > > regards, > > Ted Hardie > > ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 11:17:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAZI-0003S0-7t; Sun, 15 Jan 2006 11:17:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAZ8-0003JI-3U for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 11:17:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29635 for ; Sun, 15 Jan 2006 11:13:05 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExpAj-0003kf-JE for ecrit@ietf.org; Sat, 14 Jan 2006 12:26:39 -0500 Received: (qmail invoked by alias); 14 Jan 2006 17:18:38 -0000 Received: from p54985FF7.dip.t-dialin.net (EHLO [192.168.2.100]) [84.152.95.247] by mail.gmx.net (mp017) with SMTP; 14 Jan 2006 18:18:38 +0100 X-Authenticated: #29516787 Message-ID: <43C9326D.7060904@gmx.net> Date: Sat, 14 Jan 2006 18:18:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Ecrit] SIP Location Conveyance X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, draft-ietf-sip-location-conveyance-01.txt is an important document for our work in ecrit. unfortunately, the document has not yet seen a lot of review. please read http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-01.txt and send your feedback. it might also be useful to discuss open issues during the interim meeting. thoughts? james, brian: what are the open issues with the document? is section 11 up-to-date? ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 11:38:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAtt-0001dP-Uz; Sun, 15 Jan 2006 11:38:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAtZ-0001Fp-IA for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 11:38:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01031 for ; Sun, 15 Jan 2006 11:17:23 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExoID-0005VC-Jd for ecrit@ietf.org; Sat, 14 Jan 2006 11:30:19 -0500 Received: (qmail invoked by alias); 14 Jan 2006 16:22:18 -0000 Received: from p54985FF7.dip.t-dialin.net (EHLO [192.168.2.100]) [84.152.95.247] by mail.gmx.net (mp032) with SMTP; 14 Jan 2006 17:22:18 +0100 X-Authenticated: #29516787 Message-ID: <43C92539.6070101@gmx.net> Date: Sat, 14 Jan 2006 17:22:17 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org, Andrew Newton Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy, hi all, in order to close a few open issues i would to discuss issue#8. here is the text from the issue tracker: " Requirements A1a and A1b specify a universal identifier. These requirements specify "one or more." What are the requirements regarding adding new emergency identifiers? " currently there are no requirements regarding the registration or regarding future enhancements. can you think of something that should go into a requirements document? ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 11:53:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyB2E-0004io-BH; Sun, 15 Jan 2006 11:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAyY-00030v-45 for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 11:43:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29476 for ; Sun, 15 Jan 2006 11:13:02 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Exp56-000370-Pb for ecrit@ietf.org; Sat, 14 Jan 2006 12:20:50 -0500 Received: (qmail invoked by alias); 14 Jan 2006 17:12:50 -0000 Received: from p54985FF7.dip.t-dialin.net (EHLO [192.168.2.100]) [84.152.95.247] by mail.gmx.net (mp033) with SMTP; 14 Jan 2006 18:12:50 +0100 X-Authenticated: #29516787 Message-ID: <43C93110.4080603@gmx.net> Date: Sat, 14 Jan 2006 18:12:48 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Status of the Open Issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, we maintain a list of open issues of the requirements document at http://www.ietf-ecrit.org:8080/ecrit-req - issue 14: Missing References http://www.ietf-ecrit.org:8080/ecrit-req/issue14 i proposed text and the issue can be closed. - issue 8: Addition of New Emergency Identifiers http://www.ietf-ecrit.org:8080/ecrit-req/issue8 see my previous mail. it is not clear to me what text has to be added. - issue 10: Design of Non-Emergency Components http://www.ietf-ecrit.org:8080/ecrit-req/issue10 roger posted a mail. - issue 9: Static vs. Dynamic Mapping http://www.ietf-ecrit.org:8080/ecrit-req/issue9 roger posted a mail. - issue 25: Pre-Call routing http://www.ietf-ecrit.org:8080/ecrit-req/issue25 this issue is still open. text proposals are desired. - issue 24: LCMS works with anonymous location-by-value only http://www.ietf-ecrit.org:8080/ecrit-req/issue24 issue resolved but text for the draft has to be provided by james winterbottom. - issue 30: Requirements regarding Emergency Identifiers http://www.ietf-ecrit.org:8080/ecrit-req/issue30 i posted a mail with regard to this new issue. it is also related to issue 26. - issue 26: Mapping from local emergency number to univeral id http://www.ietf-ecrit.org:8080/ecrit-req/issue26 this issue is open and related to issue 30. - issue 17: I7: Who provides the address resolution? http://www.ietf-ecrit.org:8080/ecrit-req/issue17 i personally would like to close the issue without making modifications to the draft. - issue 15: Validation of civic location address http://www.ietf-ecrit.org:8080/ecrit-req/issue15 roger posted a mail. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 12:39:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBpZ-0000YR-Gd; Sun, 15 Jan 2006 12:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBoy-0000KB-KB for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 12:37:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20872 for ; Sun, 15 Jan 2006 12:36:16 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExgV6-00015A-Mf for ecrit@ietf.org; Sat, 14 Jan 2006 03:11:05 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 13 Jan 2006 23:30:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Issue 15 Date: Fri, 13 Jan 2006 23:30:27 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750401BB9E@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Issue 15 Thread-Index: AcYIAOEj38/Ie52JR5qJWhi1Z4Zc1wQ2q5Zw From: "Roger Marshall" To: "Ted Hardie" , , "Winterbottom, James" , "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Issue 15, (http://www.ietf-ecrit.org:8080/ecrit-req/issue15): Changing subject line to include the issue number (15), for tracking. We've generated lots of discussion on this subject, and from what I can tell, as a result it looks like most folks think that there is a place for validation under certain (maybe alternate) circumstances. I'm therefore leaving the following requirement intact: Lo1. Validation of Civic Location: It MUST be possible to validate a civic location prior to its use in an actual emergency call. Motivation: Location validation provides an opportunity to help assure ahead of time, whether successful mapping to the appropriate PSAP will likely occur when it is required. Validation may also help to avoid delays during emergency call setup due to invalid locations. If there is disagreement with leaving this in, please comment. Thanks. Roger Marshall. >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com]=20 >Sent: Friday, December 23, 2005 12:38 PM >To: br@brianrosen.net; 'Winterbottom, James'; 'James M. Polk';=20 >Roger Marshall; ecrit@ietf.org >Subject: RE: [Ecrit] Issue > >At 8:22 AM -0500 12/23/05, Brian Rosen wrote: >>This is not a provisioning issue, at least not a provisioning=20 >issue for=20 >>the mapping database. In some circumstances, it's a=20 >provisioning issue=20 >>for a LIS, but with respect to the mapping protocol, it's an=20 >>operational requirement. >> >>Repeating myself, the requirement is that ecrit provides a=20 >mechanism to=20 >>confirm the validity of an address. Validity in this case means: >> If the address was to be used for an emergency call, it=20 >would be=20 >>recognized in the database and a valid mapping would be returned >> If the address was used for dispatch, it is an address that the=20 >>responders would recognize and be able to send help > >Thanks for very clearly separating those two out. The first=20 >actually breaks into two cases: 1) there is enough data=20 >provide a mapping, but the data are incomplete or incorrect in=20 >some way known to the system; 2) the data are correct and=20 >complete and in some way known. > >How often case one happens depends a lot on the way in which=20 >the locality has organized its PSAPs. If a municipality has=20 >a single PSAP, a correct mapping can be returned if there is a=20 >municipality in the location object, even if no other data is present. >There are lots of other cases where partial information or=20 >partially correct information can still be sufficient to=20 >generate a good mapping; as long as you do not presume that=20 >the query is hamstrung to be exact-match only, good results=20 >can come from incomplete data in non-trivial numbers of cases. >=20 >What you want to return to a query in the case of "available=20 >mapping, but a location object that is incomplete" depends on=20 >whether the query is associated with an actual emergency or is=20 >specific to validation. > >If the query being made is specifically a validation query, it=20 >should return the mapping and an indication that the data is=20 >not complete (or elements are not correct); if the query is an=20 >emergency query, it should simply return the mapping. =20 >Distinguishing between the two cases with a query flag is an=20 >obvious choice, and I think most of us believe that's a good=20 >thing to do. > >Going beyond that to your second case, there is a question=20 >about whether what validation query is testing against is the=20 >address's correctness/completeness for dispatch. I think it is=20 >logical to assume it is.=20 > >I *think* then, what the requirement boils down to is that the=20 >error results for negative returns to validation queries=20 >should distinguish among location objects that are too=20 >incomplete for dispatch, those that are complete but appear to=20 >have data that is not in the database, and those in which the=20 >data are known to be wrong (cites a floor in a building higher=20 >than is possible, for example).=20 > >We could go beyond that, to citing which data elements are=20 >known to be wrong, and there are cases where we might be able=20 >to cite which data elements are missing (though this gets=20 >complicated fast, as you will run into lots of "Must include=20 >either municipality or county name with a street address). I=20 >personally suspect punting that level of specificity to a free=20 >text field is okay; you'll only get it when validating an=20 >address, and the most valuable data may actually be who to=20 >call to work out the problem (rather than possibly difficult=20 >to interpret data). > > regards, > Ted Hardie > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 12:50:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC0b-00073C-Js; Sun, 15 Jan 2006 12:49:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC0F-0006Yk-TC for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 12:49:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00587 for ; Sun, 15 Jan 2006 11:16:44 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExoE1-0000Tg-DS for ecrit@ietf.org; Sat, 14 Jan 2006 11:26:00 -0500 Received: (qmail invoked by alias); 14 Jan 2006 16:17:58 -0000 Received: from p54985FF7.dip.t-dialin.net (EHLO [192.168.2.100]) [84.152.95.247] by mail.gmx.net (mp023) with SMTP; 14 Jan 2006 17:17:58 +0100 X-Authenticated: #29516787 Message-ID: <43C9242F.2010309@gmx.net> Date: Sat, 14 Jan 2006 17:17:51 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Text for I7 References: <8C837214C95C864C9F34F3635C2A65750401BB94@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750401BB94@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: Hannes.Tschofenig@siemens.com, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi marc, hi all, i have no problem with the requirement as it is written since the motivation is related to debugging. with regard to the security document we might, however, need to discuss potential requirements regarding authenticating the source of the returned data. ciao hannes Roger Marshall wrote: > Issue 17 (ref. http://www.ietf-ecrit.org:8080/ecrit-req/issue17). > > (previous numbering at time issue was created) > I7. Traceable resolution: The entity requesting mapping SHOULD be > able to determine the entity or entities who provided the > emergency address resolution information. > > (current numbering as of requirements draft version -02) > Ma9. Traceable resolution: The entity requesting mapping SHOULD be > able to determine the entity or entities who provided the > emergency address resolution information. > > Motivation: To provide operational traceability in case of errors. > > > The original issue as entered: > > (Hannes:) We should be a bit more specific about this requirement. What > is the > impact of this requirement? Is it sufficient to add an attribute to the > returned object that the mapping was provided by X or do we require a > digital > signature of the entity that created the mapping? > > > I welcome comments from the list in order to see if we can flesh out the > outstanding request for additional explanation for Ma9. I'd like to get > to a resolution, otherwise, without more clarification, is there support > to delete Ma9 altogether? > > Thanks. > > Roger Marshall. > > > >>-----Original Message----- >>From: Roger Marshall >>Sent: Wednesday, October 19, 2005 4:18 PM >>To: 'Brian Rosen'; ecrit@ietf.org >>Subject: RE: [Ecrit] Text for I7 >> >>Brian: >>Please reference issue #17 on the issue tracker, at: >>http://www.ietf-ecrit.org:8080/ecrit-req/ >> >>Can you specify some add'l detail for this requirement? >> >> >>Roger Marshall. >> >> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >>On Behalf >> >>>Of Brian Rosen >>>Sent: Wednesday, May 18, 2005 6:47 AM >>>To: ecrit@ietf.org >>>Subject: [Ecrit] Text for I7 >>> >>>I7. Traceable resolution: The entity requesting mapping >> >>SHOULD be able >> >>>to definitively and securely determine the entity or entities who >>>provided the emergency address resolution information. >>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 12:52:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC30-000109-Am; Sun, 15 Jan 2006 12:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC2k-0008P8-Rg for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 12:51:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29653 for ; Sun, 15 Jan 2006 11:13:32 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Exp5Y-00037y-Tc for ecrit@ietf.org; Sat, 14 Jan 2006 12:21:17 -0500 Received: (qmail invoked by alias); 14 Jan 2006 17:13:18 -0000 Received: from p54985FF7.dip.t-dialin.net (EHLO [192.168.2.100]) [84.152.95.247] by mail.gmx.net (mp033) with SMTP; 14 Jan 2006 18:13:18 +0100 X-Authenticated: #29516787 Message-ID: <43C9312C.6040106@gmx.net> Date: Sat, 14 Jan 2006 18:13:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Subject: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, Section 6 of discusses requirements related to emergency identifiers. draft-ietf-sipping-sos-01.txt also lists requirements and they should be removed from sipping-sos draft and incorporated into the requirements document. Here is an attempt to merge these requirements. The following requirements should be discussed in context of the ecrit requirements document. They are extracted from http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-01.txt 3. Requirements o It should be possible for devices to provide user interfaces that can directly cause an emergency call, without the user having to "dial" or type a specific address. [hannes] user interface specific requirement and therefore not relevant for the requirements document. o Even as each country is likely to operate their emergency calling infrastructure differently, SIP devices should be able to reach emergency help and, if possible, be located in any country. [hannes] this is not an identifier specific requirement. o While traveling, users should be able to use their familiar "home" emergency number. [hannes] this says that a large number of country specific emergency numbers must be understood. Users must also be able to dial the local emergency number in the country they are visiting. [hannes] i am not sure that this requirement means (particularly in relationship to the previous sentence). does it mean that the user must be able to dial the familar home number or the number that is recognized in the visited country. in the latter case there is only the question how the end host / user learns this information. o Any mechanism must be deployable incrementally and work even if not all SIP entities support emergency calling. User agents conforming to the SIP specification [RFC3261], but unaware of this document, must be able to place emergency calls, possibly with restricted functionality. [hannes] there might be some usefulness in providing a description of the different approaches (as it is done with the first paragraphs of section 5 and section 7 of the requirements draft. there are two aspects: - sip proxies understand / do not understand the emergency identifiers - end hosts understand / do not understand the emergency identifiers requirement Id9 might go a little bit into this direction but seems to conflict with requirement Id8. o Given incremental deployment, emergency call functionality should be testable by the user without causing an emergency response. [hannes] this is not a requirement regarding the emergency identifiers. o Emergency calling mechanisms must support existing emergency call centers based on circuit-switched technology as well as future ECC that are SIP-capable. [hannes] not relevant. --- User agents SHOULD allow users and/or administrators to configure additional emergency numbers. [hannes] this requirement is not yet there. it might be better to write: " Mechanisms for configuring user agents with emergency numbers SHOULD be provided. " this is, however, just a different wording than in requirement Id6. User agents SHOULD attempt to ascertain the set of emergency numbers that are valid in the geographic region that the user agent is currently located in. [hannes] this requirement is not yet there. in some sense it relates to the ability for user agents to be configured with emergency numbers. If and only if an end system is unable to determine the emergency numbers valid in its current geographical location, it SHOULD recognize any of the number 000, 08, 110, 999, 118 and 119 as emergency numbers. [hannes] if this requirements refers to sip proxies then it relates to requirement Id4. the text might, however, give the impression that it relates to end systems only. it therefore only relates to implementation specific end host requirement. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 13:55:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD2N-0004kC-EM; Sun, 15 Jan 2006 13:55:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD2C-0004NV-2C for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 13:55:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15070 for ; Sun, 15 Jan 2006 12:09:39 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExgV7-00015A-Da for ecrit@ietf.org; Sat, 14 Jan 2006 03:11:05 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 13 Jan 2006 23:52:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Requirements draft status update. Date: Fri, 13 Jan 2006 23:52:38 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750401BB9F@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Requirements draft status update. Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyx5UwR0gEPJfGtAABC6LgA== From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: Hannes.Tschofenig@siemens.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org =20 Status update: ECRIT Requirements Draft=20 I-D: draft-ietf-ecrit-requirements-02.txt Everyone should read this before the interim meeting in Wash D.C. on Feb 1 & 2. (http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.tx t) I've updated the issue tracker based on recent discussions and agreements either at IETF 64 or on the list. Please reference http://www.ietf-ecrit.org:8080/ecrit-req/ for the detail status. There are a few yet unresolved issues, those I've posted to the list. Additionally, there are a few other issues, which Hannes has agreed to take on, namely those related to requirements represented within Henning's sipping-sos draft. I hope that we can reach a satisfactory conclusion to each of these outstanding issues before the next interim meeting, in which case my job would be easy (I suspect it won't happen entirely that way). In any case, I will be unavailable for the next two weeks, on vacation from now until Jan 28, so I will catch up at the interim meeting. Thanks all for your good work and input. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 15 14:03:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD9x-0000UC-6B; Sun, 15 Jan 2006 14:03:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD5F-00065N-ES for ecrit@megatron.ietf.org; Sun, 15 Jan 2006 13:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16802 for ; Sun, 15 Jan 2006 12:15:17 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExfDV-00049C-U5 for ecrit@ietf.org; Sat, 14 Jan 2006 01:48:53 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 13 Jan 2006 22:40:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 22:40:49 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750401BB9A@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: Ecrit issue 9 - lack of static vs. dynamic Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyx5UwR0gEPJfGtAAAf5PIA== From: "Roger Marshall" To: "Andrew Newton" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: Hannes.Tschofenig@siemens.com Subject: [Ecrit] Ecrit issue 9 - lack of static vs. dynamic X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Issue 9 (ref. http://www.ietf-ecrit.org:8080/ecrit-req/issue9), states:=20 "There are no requirements for static vs. dynamic routing as specified by draft- polk-newton-ecrit-arch-considerations-00.txt." I question why it is necessary that this is addressed in the requirements document. I propose that this issue be marked resolved unless the group pursues additional discussion/clarification/contributions around this topic. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 16 01:57:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOJA-0000Xr-6b; Mon, 16 Jan 2006 01:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOJ8-0000Xj-Bv for ecrit@megatron.ietf.org; Mon, 16 Jan 2006 01:57:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17782 for ; Mon, 16 Jan 2006 01:56:13 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyOQz-0005Di-Hu for ecrit@ietf.org; Mon, 16 Jan 2006 02:05:46 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0G6vT4f025165Mon, 16 Jan 2006 06:57:29 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EyOIz-000MPR-00; Mon, 16 Jan 2006 06:57:29 +0000 Date: Mon, 16 Jan 2006 06:57:29 +0000 From: "Clive D.W. Feather" To: Hannes Tschofenig Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Message-ID: <20060116065729.GB84282@finch-staff-1.thus.net> References: <43C9312C.6040106@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C9312C.6040106@gmx.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > If and only if an end system is unable to determine the emergency > numbers valid in its current geographical location, it SHOULD > recognize any of the number 000, 08, 110, 999, 118 and 119 as > emergency numbers. I recognise exactly one of those as being emergency numbers. Why aren't 112 and 911 on the list? I believe they cover far more people than the above 6. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 16 02:44:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyP2q-0001cE-DE; Mon, 16 Jan 2006 02:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyP2o-0001ae-Fw for ecrit@megatron.ietf.org; Mon, 16 Jan 2006 02:44:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20127 for ; Mon, 16 Jan 2006 02:43:25 -0500 (EST) Received: from bay106-dav12.bay106.hotmail.com ([65.54.161.84] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyPAg-0006Ls-Ca for ecrit@ietf.org; Mon, 16 Jan 2006 02:52:59 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 15 Jan 2006 23:44:39 -0800 Message-ID: Received: from 70.59.25.22 by BAY106-DAV12.phx.gbl with DAV; Mon, 16 Jan 2006 07:44:39 +0000 X-Originating-IP: [70.59.25.22] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Clive D.W. Feather'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Mon, 16 Jan 2006 00:44:34 -0700 Message-ID: <000301c61a70$b15eb0b0$0300a8c0@TimDunn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060116065729.GB84282@finch-staff-1.thus.net> Thread-Index: AcYaap44mrgS89wDQI6OJnsTc3kAAgABdfQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-OriginalArrivalTime: 16 Jan 2006 07:44:39.0705 (UTC) FILETIME=[B4B4E090:01C61A70] X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A larger, pretty exhaustive list of worldwide emergency numbers can be found at http://www.sccfd.org/travel.html Should all of these be included? Tim Dunn -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Clive D.W. Feather Sent: Sunday, January 15, 2006 11:57 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers > If and only if an end system is unable to determine the emergency > numbers valid in its current geographical location, it SHOULD > recognize any of the number 000, 08, 110, 999, 118 and 119 as > emergency numbers. I recognise exactly one of those as being emergency numbers. Why aren't 112 and 911 on the list? I believe they cover far more people than the above 6. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 16 09:15:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyV93-0000vz-P5; Mon, 16 Jan 2006 09:15:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyV92-0000vu-6X for ecrit@megatron.ietf.org; Mon, 16 Jan 2006 09:15:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15762 for ; Mon, 16 Jan 2006 09:14:15 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVGx-0002wM-F3 for ecrit@ietf.org; Mon, 16 Jan 2006 09:23:52 -0500 Received: from [192.168.0.41] (pool-138-89-39-108.mad.east.verizon.net [138.89.39.108]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0GEFYxg006485 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 16 Jan 2006 09:15:34 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DD98B73-BC46-4A5F-B19B-A9CB63087FD0@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Mon, 16 Jan 2006 09:15:31 -0500 To: "Tim Dunn" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't know why 911 and 112 somehow got omitted from the list, but including all emergency numbers is probably not such a great idea as some of these are also used for non-emergency services elsewhere and are popular for various PBX functions. Most seriously, many PBX use 2- digit to 4-digit dialing for internal extensions. All extensions listed in the "recognize as emergency numbers" list would then suddenly cease to work or dial the local fire department. Not a good thing. The list (000, 08, ...) is borrowed from the current wireless (GSM) conventions. GSM phones obviously don't have to worry about PBX extensions. Given the PBX extensions issue, it might be necessary to restrict the list to 112 and 911 only. BTW, I particularly like the entry for S. Georgia Is./ S. Sandwich Is. in the table. On Jan 16, 2006, at 2:44 AM, Tim Dunn wrote: > A larger, pretty exhaustive list of worldwide emergency numbers can > be found > at > > http://www.sccfd.org/travel.html > > Should all of these be included? > > Tim Dunn > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Clive D.W. Feather > Sent: Sunday, January 15, 2006 11:57 PM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency > Identifiers > >> If and only if an end system is unable to determine the emergency >> numbers valid in its current geographical location, it SHOULD >> recognize any of the number 000, 08, 110, 999, 118 and 119 as >> emergency numbers. > > I recognise exactly one of those as being emergency numbers. Why > aren't 112 > and 911 on the list? I believe they cover far more people than the > above 6. > > -- > Clive D.W. Feather | Work: | Tel: +44 20 > 8495 6138 > Internet Expert | Home: | Fax: +44 870 > 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 > 377646 > Thus plc | | > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 16 19:27:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyegy-0007kc-Hz; Mon, 16 Jan 2006 19:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyegu-0007j1-Ua for ecrit@megatron.ietf.org; Mon, 16 Jan 2006 19:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28162 for ; Mon, 16 Jan 2006 19:25:52 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyeot-0002x4-Ak for ecrit@ietf.org; Mon, 16 Jan 2006 19:35:34 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0H0QoZk010538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jan 2006 16:26:51 -0800 Received: from [129.46.225.69] (dhcp-campbell-23.qualcomm.com [129.46.225.69]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0H0Qjgu000016; Mon, 16 Jan 2006 16:26:46 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 16 Jan 2006 16:26:44 -0800 To: "Winterbottom, James" , "Roger Marshall" , , "James M. Polk" , From: Ted Hardie Subject: RE: [Ecrit] Issue 15 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 3:24 PM -0600 1/14/06, Winterbottom, James wrote: >Roger, > >I am still unconvinced that this is anything other than a provisioning >requirement, that aside, I think that if the requirement is to stand it >should be clear in the requirement itself what you are validating it >for. The current requirement simply says that it need to be done before >a call, which is a when and not a what. > >So I think I would add to the requirement something like: >"to ensure that the location can be mapped to a PSAP". > >Cheers >James While I think it likely that any proposed protocol will go further than this, I think James's addition captures the bit that is actually required. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 08:21:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyqmU-0005KU-Pt; Tue, 17 Jan 2006 08:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyqmR-0005IM-EE for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 08:21:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15379 for ; Tue, 17 Jan 2006 08:20:21 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyquX-00085f-6s for ecrit@ietf.org; Tue, 17 Jan 2006 08:30:11 -0500 Received: (qmail invoked by alias); 17 Jan 2006 13:21:34 -0000 Received: from xdsl-87-78-65-47.netcologne.de (EHLO [192.168.1.67]) [87.78.65.47] by mail.gmx.net (mp031) with SMTP; 17 Jan 2006 14:21:34 +0100 X-Authenticated: #29516787 Message-ID: <43CCEF56.4040805@gmx.net> Date: Tue, 17 Jan 2006 14:21:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <5DD98B73-BC46-4A5F-B19B-A9CB63087FD0@cs.columbia.edu> In-Reply-To: <5DD98B73-BC46-4A5F-B19B-A9CB63087FD0@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, i think that the following issues need to be determined: 1) do we want to support the usage of country specific emergency numbers? 2) if we say yes in (1) then we need to provide a story for 2a) roaming users to learn emergency numbers supported in the network they visit 2b) sip proxies that potentially receive emergency calls with emergency numbers used in other countries. the underlying question is: what migration scenarios do we want to support? * sip proxies that do not understand (but end host do) * end hosts that do not understand but end host understand draft-ietf-sipping-sos-01.txt. * end host understand neighter draft-ietf-sipping-sos-01.txt nor draft-schulzrinne-sipping-service-01.txt ciao hannes Henning Schulzrinne wrote: > I don't know why 911 and 112 somehow got omitted from the list, but > including all emergency numbers is probably not such a great idea as > some of these are also used for non-emergency services elsewhere and > are popular for various PBX functions. Most seriously, many PBX use 2- > digit to 4-digit dialing for internal extensions. All extensions listed > in the "recognize as emergency numbers" list would then suddenly cease > to work or dial the local fire department. Not a good thing. > > The list (000, 08, ...) is borrowed from the current wireless (GSM) > conventions. GSM phones obviously don't have to worry about PBX > extensions. > > Given the PBX extensions issue, it might be necessary to restrict the > list to 112 and 911 only. > > BTW, I particularly like the entry for S. Georgia Is./ S. Sandwich Is. > in the table. > > On Jan 16, 2006, at 2:44 AM, Tim Dunn wrote: > >> A larger, pretty exhaustive list of worldwide emergency numbers can >> be found >> at >> >> http://www.sccfd.org/travel.html >> >> Should all of these be included? >> >> Tim Dunn >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> Clive D.W. Feather >> Sent: Sunday, January 15, 2006 11:57 PM >> To: Hannes Tschofenig >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency >> Identifiers >> >>> If and only if an end system is unable to determine the emergency >>> numbers valid in its current geographical location, it SHOULD >>> recognize any of the number 000, 08, 110, 999, 118 and 119 as >>> emergency numbers. >> >> >> I recognise exactly one of those as being emergency numbers. Why >> aren't 112 >> and 911 on the list? I believe they cover far more people than the >> above 6. >> >> -- >> Clive D.W. Feather | Work: | Tel: +44 20 >> 8495 6138 >> Internet Expert | Home: | Fax: +44 870 >> 051 9937 >> Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 >> 377646 >> Thus plc | | >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 08:46:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrAN-0004ka-L4; Tue, 17 Jan 2006 08:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrAK-0004h5-HQ for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 08:46:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16915 for ; Tue, 17 Jan 2006 08:45:03 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyrIS-00011T-SU for ecrit@ietf.org; Tue, 17 Jan 2006 08:54:53 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EyrA7-0001ZU-7q; Tue, 17 Jan 2006 07:46:15 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 08:44:32 -0500 Message-ID: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <43CCEF56.4040805@gmx.net> Thread-Index: AcYbaP4VhskPAa1CQEmS2Q4Q+NaiJwAAbpEQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In the "big picture" sense, this is an absolute requirement. Nations spend untold millions of dollars/euros/yen/... teaching their citizens, especially children, what the local emergency number is. We cannot change the dialing sequence. Therefore, we have to, in one way or another, support local emergency numbers. The way I have always thought this would happen is that the local dialing plan would translate the local emergency number into the universal emergency URN. To do so, some element may have to learn the local emergency number. We need a mechanism for it to do so. As we know, while often place for dial plan interpretation is the endpoint, in some systems, a proxy does it. Roaming phones need to learn the local number. Proxies serving roaming phones need to learn the local emergency number. The former seems relatively easy. Some local mechanism (dare I say DHCP?) could inform it. The mapping function could provide it, and if the phone did mapping at boot (or some entity in the location determination path did it) it could get the local emergency number from the mapping protocol. The proxy has a more difficult problem because in general, it can't query any local infrastructure at the endpoint, and prior to an emergency call, it does not have the location of the phone. This would drive us towards either having some new mechanism for the phone to tell the proxy what the local emergency number is, or requiring that the phone recognize the local number regardless of whether it does any other dial plan interpretation. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, January 17, 2006 8:21 AM To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers hi all, i think that the following issues need to be determined: 1) do we want to support the usage of country specific emergency numbers? 2) if we say yes in (1) then we need to provide a story for 2a) roaming users to learn emergency numbers supported in the network they visit 2b) sip proxies that potentially receive emergency calls with emergency numbers used in other countries. the underlying question is: what migration scenarios do we want to support? * sip proxies that do not understand (but end host do) * end hosts that do not understand but end host understand draft-ietf-sipping-sos-01.txt. * end host understand neighter draft-ietf-sipping-sos-01.txt nor draft-schulzrinne-sipping-service-01.txt ciao hannes Henning Schulzrinne wrote: > I don't know why 911 and 112 somehow got omitted from the list, but > including all emergency numbers is probably not such a great idea as > some of these are also used for non-emergency services elsewhere and > are popular for various PBX functions. Most seriously, many PBX use 2- > digit to 4-digit dialing for internal extensions. All extensions listed > in the "recognize as emergency numbers" list would then suddenly cease > to work or dial the local fire department. Not a good thing. > > The list (000, 08, ...) is borrowed from the current wireless (GSM) > conventions. GSM phones obviously don't have to worry about PBX > extensions. > > Given the PBX extensions issue, it might be necessary to restrict the > list to 112 and 911 only. > > BTW, I particularly like the entry for S. Georgia Is./ S. Sandwich Is. > in the table. > > On Jan 16, 2006, at 2:44 AM, Tim Dunn wrote: > >> A larger, pretty exhaustive list of worldwide emergency numbers can >> be found >> at >> >> http://www.sccfd.org/travel.html >> >> Should all of these be included? >> >> Tim Dunn >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> Clive D.W. Feather >> Sent: Sunday, January 15, 2006 11:57 PM >> To: Hannes Tschofenig >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency >> Identifiers >> >>> If and only if an end system is unable to determine the emergency >>> numbers valid in its current geographical location, it SHOULD >>> recognize any of the number 000, 08, 110, 999, 118 and 119 as >>> emergency numbers. >> >> >> I recognise exactly one of those as being emergency numbers. Why >> aren't 112 >> and 911 on the list? I believe they cover far more people than the >> above 6. >> >> -- >> Clive D.W. Feather | Work: | Tel: +44 20 >> 8495 6138 >> Internet Expert | Home: | Fax: +44 870 >> 051 9937 >> Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 >> 377646 >> Thus plc | | >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 09:11:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrYs-0005ZD-BS; Tue, 17 Jan 2006 09:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrYq-0005Yx-HZ for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 09:11:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18689 for ; Tue, 17 Jan 2006 09:10:22 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyrgx-0001xV-AR for ecrit@ietf.org; Tue, 17 Jan 2006 09:20:13 -0500 Received: from [192.168.0.41] (pool-138-89-39-108.mad.east.verizon.net [138.89.39.108]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0HEBgbC029646 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 17 Jan 2006 09:11:42 -0500 (EST) In-Reply-To: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> References: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C53D896-8D4E-48C3-9D0D-CF3B9BC30B08@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 09:11:39 -0500 To: X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jan 17, 2006, at 8:44 AM, Brian Rosen wrote: > In the "big picture" sense, this is an absolute requirement. > Nations spend > untold millions of dollars/euros/yen/... teaching their citizens, > especially > children, what the local emergency number is. We cannot change the > dialing > sequence. Therefore, we have to, in one way or another, support local > emergency numbers. > > The way I have always thought this would happen is that the local > dialing > plan would translate the local emergency number into the universal > emergency > URN. To do so, some element may have to learn the local emergency > number. > We need a mechanism for it to do so. I agree that this is vitally important. Unfortunately, the normal SIP configuration mechanism that is being discussed in SIPPING is unlikely to be appropriate, as it does not take location into account. The goal should be that, at least for mobile devices, both my "home" emergency number and my "visited" emergency number work. Having recently visited India, I made an effort to find the local emergency number (100, plus others), but it required significant effort and I suspect that most visitors wouldn't know what to dial if an emergency occurred. > > As we know, while often place for dial plan interpretation is the > endpoint, > in some systems, a proxy does it. Roaming phones need to learn the > local > number. Proxies serving roaming phones need to learn the local > emergency > number. They need to learn the emergency number(s) local to the caller, given that the first-hop proxy may well be in another continent from the mobile device, for example. This is why I have proposed a mechanism in the LUMP work to leverage the mapping infrastructure; it is almost trivial to solve the problem once you have a location mapping protocol. > > The former seems relatively easy. Some local mechanism (dare I say > DHCP?) > could inform it. The mapping function could provide it, and if the > phone DHCP, unfortunately, does not satisfy the "home" number requirement that I think we should strive for. It also requires yet another protocol machinery. > did mapping at boot (or some entity in the location determination > path did > it) it could get the local emergency number from the mapping > protocol. The > proxy has a more difficult problem because in general, it can't > query any > local infrastructure at the endpoint, and prior to an emergency > call, it > does not have the location of the phone. It can easily cache location-to-number mappings, as these are long- term stable and national. Indeed, it could simply walk through all country codes and get the mappings ahead of time. > > This would drive us towards either having some new mechanism for > the phone > to tell the proxy what the local emergency number is, or requiring > that the > phone recognize the local number regardless of whether it does any > other > dial plan interpretation. I don't think either is necessary. This is simply a location-to- identifier mapping problem, which we are already solving. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 09:31:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyrrd-0004hD-EV; Tue, 17 Jan 2006 09:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyrra-0004h0-5y for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 09:31:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19806 for ; Tue, 17 Jan 2006 09:29:44 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyrzj-0002dV-13 for ecrit@ietf.org; Tue, 17 Jan 2006 09:39:35 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EyrrW-00064v-9G; Tue, 17 Jan 2006 08:31:06 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 09:29:09 -0500 Message-ID: <0ded01c61b72$647c0970$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7C53D896-8D4E-48C3-9D0D-CF3B9BC30B08@cs.columbia.edu> Thread-Index: AcYbb/FIsPRR1DYfTiC+SMTA4zKAdAAALuAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >> did mapping at boot (or some entity in the location determination >> path did >> it) it could get the local emergency number from the mapping >> protocol. The >> proxy has a more difficult problem because in general, it can't >> query any >> local infrastructure at the endpoint, and prior to an emergency >> call, it >> does not have the location of the phone. > >It can easily cache location-to-number mappings, as these are long- >term stable and national. Indeed, it could simply walk through all >country codes and get the mappings ahead of time. The proxy doesn't have the location of the caller until a call the phone recognizes as an emergency call is placed. If the proxy does dial plan interpretation, then the phone won't know it's an emergency call, and won't send location when the local emergency number is dialed. The proxy has to learn BEFORE an emergency call is placed, what the local emergency number is. That's pretty tough now. We would have to have the phone send it's location in advance, which is unacceptable. There are privacy considerations in the proxy knowing what the local emergency number is (it may tell you what country the phone is in), but I think that's unavoidable. People worried about that level of privacy would need to have a phone that did it's own recognition of the local emergency number. Caching the HOME emergency number is conceivable, for either the phone or the proxy, but only if there was some indication of where home was. I am unaware of any mechanism that would tell you that. You could conceivably configure that, I guess, but you probably can't learn it. Caching in the phone assumes some non-volatile, but endpoint writable storage. Dunno if that is an acceptable requirement. Probably, it's okay. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, January 17, 2006 9:12 AM To: br@brianrosen.net Cc: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers On Jan 17, 2006, at 8:44 AM, Brian Rosen wrote: > In the "big picture" sense, this is an absolute requirement. > Nations spend > untold millions of dollars/euros/yen/... teaching their citizens, > especially > children, what the local emergency number is. We cannot change the > dialing > sequence. Therefore, we have to, in one way or another, support local > emergency numbers. > > The way I have always thought this would happen is that the local > dialing > plan would translate the local emergency number into the universal > emergency > URN. To do so, some element may have to learn the local emergency > number. > We need a mechanism for it to do so. I agree that this is vitally important. Unfortunately, the normal SIP configuration mechanism that is being discussed in SIPPING is unlikely to be appropriate, as it does not take location into account. The goal should be that, at least for mobile devices, both my "home" emergency number and my "visited" emergency number work. Having recently visited India, I made an effort to find the local emergency number (100, plus others), but it required significant effort and I suspect that most visitors wouldn't know what to dial if an emergency occurred. > > As we know, while often place for dial plan interpretation is the > endpoint, > in some systems, a proxy does it. Roaming phones need to learn the > local > number. Proxies serving roaming phones need to learn the local > emergency > number. They need to learn the emergency number(s) local to the caller, given that the first-hop proxy may well be in another continent from the mobile device, for example. This is why I have proposed a mechanism in the LUMP work to leverage the mapping infrastructure; it is almost trivial to solve the problem once you have a location mapping protocol. > > The former seems relatively easy. Some local mechanism (dare I say > DHCP?) > could inform it. The mapping function could provide it, and if the > phone DHCP, unfortunately, does not satisfy the "home" number requirement that I think we should strive for. It also requires yet another protocol machinery. > did mapping at boot (or some entity in the location determination > path did > it) it could get the local emergency number from the mapping > protocol. The > proxy has a more difficult problem because in general, it can't > query any > local infrastructure at the endpoint, and prior to an emergency > call, it > does not have the location of the phone. It can easily cache location-to-number mappings, as these are long- term stable and national. Indeed, it could simply walk through all country codes and get the mappings ahead of time. > > This would drive us towards either having some new mechanism for > the phone > to tell the proxy what the local emergency number is, or requiring > that the > phone recognize the local number regardless of whether it does any > other > dial plan interpretation. I don't think either is necessary. This is simply a location-to- identifier mapping problem, which we are already solving. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 09:59:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EysJL-0006Hb-7t; Tue, 17 Jan 2006 09:59:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EysJI-0006HU-Ts for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 09:59:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21637 for ; Tue, 17 Jan 2006 09:58:22 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EysRO-0003XU-Of for ecrit@ietf.org; Tue, 17 Jan 2006 10:08:14 -0500 Received: (qmail invoked by alias); 17 Jan 2006 14:59:35 -0000 Received: from xdsl-87-78-65-47.netcologne.de (EHLO [192.168.1.67]) [87.78.65.47] by mail.gmx.net (mp036) with SMTP; 17 Jan 2006 15:59:35 +0100 X-Authenticated: #29516787 Message-ID: <43CD0654.9030405@gmx.net> Date: Tue, 17 Jan 2006 15:59:32 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> <7C53D896-8D4E-48C3-9D0D-CF3B9BC30B08@cs.columbia.edu> In-Reply-To: <7C53D896-8D4E-48C3-9D0D-CF3B9BC30B08@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning, please find some comments inline: Henning Schulzrinne wrote: > > On Jan 17, 2006, at 8:44 AM, Brian Rosen wrote: > >> In the "big picture" sense, this is an absolute requirement. Nations >> spend >> untold millions of dollars/euros/yen/... teaching their citizens, >> especially >> children, what the local emergency number is. We cannot change the >> dialing >> sequence. Therefore, we have to, in one way or another, support local >> emergency numbers. >> >> The way I have always thought this would happen is that the local >> dialing >> plan would translate the local emergency number into the universal >> emergency >> URN. To do so, some element may have to learn the local emergency >> number. >> We need a mechanism for it to do so. > > > I agree that this is vitally important. Unfortunately, the normal SIP > configuration mechanism that is being discussed in SIPPING is unlikely > to be appropriate, as it does not take location into account. The goal > should be that, at least for mobile devices, both my "home" emergency > number and my "visited" emergency number work. Having recently visited > India, I made an effort to find the local emergency number (100, plus > others), but it required significant effort and I suspect that most > visitors wouldn't know what to dial if an emergency occurred. one question that comes into my mind would then be: if you can update your sip user agent implementation with this configuration/discovery mechanism then why cannot you just update the UA to support, let's say, draft-ietf-sipping-sos-01.txt and/or draft-schulzrinne-sipping-service-01.txt. your "home" emergency number can be mapped at the end host to an identifier described in these documents. do i understand you right that you would like to provide a configuration mechanism for the end host so that the user can dial a local emergency number and then this local emergency number is mapped to a global emergency identifer at the end host. right? ciao hannes > > >> >> As we know, while often place for dial plan interpretation is the >> endpoint, >> in some systems, a proxy does it. Roaming phones need to learn the >> local >> number. Proxies serving roaming phones need to learn the local >> emergency >> number. > > > They need to learn the emergency number(s) local to the caller, given > that the first-hop proxy may well be in another continent from the > mobile device, for example. > > This is why I have proposed a mechanism in the LUMP work to leverage > the mapping infrastructure; it is almost trivial to solve the problem > once you have a location mapping protocol. > > >> >> The former seems relatively easy. Some local mechanism (dare I say >> DHCP?) >> could inform it. The mapping function could provide it, and if the >> phone > > > DHCP, unfortunately, does not satisfy the "home" number requirement > that I think we should strive for. It also requires yet another > protocol machinery. > > >> did mapping at boot (or some entity in the location determination >> path did >> it) it could get the local emergency number from the mapping >> protocol. The >> proxy has a more difficult problem because in general, it can't query >> any >> local infrastructure at the endpoint, and prior to an emergency call, it >> does not have the location of the phone. > > > It can easily cache location-to-number mappings, as these are long- term > stable and national. Indeed, it could simply walk through all country > codes and get the mappings ahead of time. > > >> >> This would drive us towards either having some new mechanism for the >> phone >> to tell the proxy what the local emergency number is, or requiring >> that the >> phone recognize the local number regardless of whether it does any other >> dial plan interpretation. > > > I don't think either is necessary. This is simply a location-to- > identifier mapping problem, which we are already solving. > > Henning > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 10:01:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EysKY-0006pW-Ja; Tue, 17 Jan 2006 10:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EysKX-0006pH-9v for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 10:01:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21740 for ; Tue, 17 Jan 2006 09:59:39 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EysSf-0003aL-HF for ecrit@ietf.org; Tue, 17 Jan 2006 10:09:30 -0500 Received: (qmail invoked by alias); 17 Jan 2006 15:00:53 -0000 Received: from xdsl-87-78-65-47.netcologne.de (EHLO [192.168.1.67]) [87.78.65.47] by mail.gmx.net (mp001) with SMTP; 17 Jan 2006 16:00:53 +0100 X-Authenticated: #29516787 Message-ID: <43CD069F.5000609@gmx.net> Date: Tue, 17 Jan 2006 16:00:47 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> In-Reply-To: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi brian, Brian Rosen wrote: > In the "big picture" sense, this is an absolute requirement. Nations spend > untold millions of dollars/euros/yen/... teaching their citizens, especially > children, what the local emergency number is. We cannot change the dialing > sequence. Therefore, we have to, in one way or another, support local > emergency numbers. this is certainly true. there is, however, a user interface issue here too. the number the user dials does not necessarily need to appear on the wire. so, if you always use the same emergency number but internally the sip implementation uses, for example, draft-schulzrinne-sipping-service-01.txt to represent the emergency call on the wire then there is no need to define a mechanism for the end host to dynamically retrieve country specific emergency numbers while abroad. > > The way I have always thought this would happen is that the local dialing > plan would translate the local emergency number into the universal emergency > URN. To do so, some element may have to learn the local emergency number. > We need a mechanism for it to do so. it is a good question of who has to translate a locally known emergency number to a such a global emergency identifier. if it is the end host then there is probably no problem (or?). if this mapping is provided by the sip proxy then every sip proxy theoretically needs to understand all emergency numbers used in the world. there is no need to dynamically configure these proxies since these numbers do not change frequently. > > As we know, while often place for dial plan interpretation is the endpoint, > in some systems, a proxy does it. Roaming phones need to learn the local > number. Proxies serving roaming phones need to learn the local emergency > number. i am not sure that this is actually true. see above. hence, the solution are not necessary. > > The former seems relatively easy. Some local mechanism (dare I say DHCP?) > could inform it. The mapping function could provide it, and if the phone > did mapping at boot (or some entity in the location determination path did > it) it could get the local emergency number from the mapping protocol. The > proxy has a more difficult problem because in general, it can't query any > local infrastructure at the endpoint, and prior to an emergency call, it > does not have the location of the phone. > > This would drive us towards either having some new mechanism for the phone > to tell the proxy what the local emergency number is, or requiring that the > phone recognize the local number regardless of whether it does any other > dial plan interpretation. > > Brian ciao hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, January 17, 2006 8:21 AM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers > > hi all, > > i think that the following issues need to be determined: > > 1) do we want to support the usage of country specific emergency numbers? > > 2) if we say yes in (1) > then we need to provide a story for > > 2a) roaming users to learn emergency numbers supported in the network > they visit > > 2b) sip proxies that potentially receive emergency calls with emergency > numbers used in other countries. > > the underlying question is: what migration scenarios do we want to support? > * sip proxies that do not understand > (but end host do) > * end hosts that do not understand > but end host understand > draft-ietf-sipping-sos-01.txt. > * end host understand neighter draft-ietf-sipping-sos-01.txt nor > draft-schulzrinne-sipping-service-01.txt > > ciao > hannes > > Henning Schulzrinne wrote: > >>I don't know why 911 and 112 somehow got omitted from the list, but >>including all emergency numbers is probably not such a great idea as >>some of these are also used for non-emergency services elsewhere and >>are popular for various PBX functions. Most seriously, many PBX use 2- >>digit to 4-digit dialing for internal extensions. All extensions listed >>in the "recognize as emergency numbers" list would then suddenly cease >>to work or dial the local fire department. Not a good thing. >> >>The list (000, 08, ...) is borrowed from the current wireless (GSM) >>conventions. GSM phones obviously don't have to worry about PBX >>extensions. >> >>Given the PBX extensions issue, it might be necessary to restrict the >>list to 112 and 911 only. >> >>BTW, I particularly like the entry for S. Georgia Is./ S. Sandwich Is. >>in the table. >> >>On Jan 16, 2006, at 2:44 AM, Tim Dunn wrote: >> >> >>>A larger, pretty exhaustive list of worldwide emergency numbers can >>>be found >>>at >>> >>>http://www.sccfd.org/travel.html >>> >>>Should all of these be included? >>> >>>Tim Dunn >>> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>Behalf Of >>>Clive D.W. Feather >>>Sent: Sunday, January 15, 2006 11:57 PM >>>To: Hannes Tschofenig >>>Cc: ecrit@ietf.org >>>Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency >>>Identifiers >>> >>> >>>> If and only if an end system is unable to determine the emergency >>>> numbers valid in its current geographical location, it SHOULD >>>> recognize any of the number 000, 08, 110, 999, 118 and 119 as >>>> emergency numbers. >>> >>> >>>I recognise exactly one of those as being emergency numbers. Why >>>aren't 112 >>>and 911 on the list? I believe they cover far more people than the >>>above 6. >>> >>>-- >>>Clive D.W. Feather | Work: | Tel: +44 20 >>>8495 6138 >>>Internet Expert | Home: | Fax: +44 870 >>>051 9937 >>>Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 >>>377646 >>>Thus plc | | >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 10:49:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyt5B-0005FS-45; Tue, 17 Jan 2006 10:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyt59-0005ER-Nd for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 10:49:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25877 for ; Tue, 17 Jan 2006 10:47:51 -0500 (EST) 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 1EytDG-0005C1-7V for ecrit@ietf.org; Tue, 17 Jan 2006 10:57:41 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2006 07:49:02 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0HFmxk3009654; Tue, 17 Jan 2006 07:49:01 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 10:48:59 -0500 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: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 10:48:58 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3FC796D@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] issue 8: Addition of New Emergency Identifiers Thread-Index: AcYZ8lfy8X8YU5NmRyWkDtrkHFfupQBiuyBg From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" , , "Andrew Newton" X-OriginalArrivalTime: 17 Jan 2006 15:48:59.0404 (UTC) FILETIME=[880CCCC0:01C61B7D] X-Spam-Score: 2.2 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org BTW, if there is more than one identifier, then any identifier is no longer "universal". The "one or more" universal requirement is an oxymoron. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Saturday, January 14, 2006 11:22 AM > To: ecrit@ietf.org; Andrew Newton > Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers >=20 > hi andy, > hi all, >=20 > in order to close a few open issues i would to discuss issue#8. > here is the text from the issue tracker: >=20 > " > Requirements A1a and A1b specify a universal identifier. =20 > These requirements specify "one or more." What are the=20 > requirements regarding adding new emergency identifiers? > " >=20 > currently there are no requirements regarding the=20 > registration or regarding future enhancements. can you think=20 > of something that should go into a requirements document? >=20 > ciao > hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 11:04:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytKJ-0001S5-8T; Tue, 17 Jan 2006 11:04:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytKH-0001S0-Rh for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 11:04:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26772 for ; Tue, 17 Jan 2006 11:03:29 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EytSQ-0005eh-4S for ecrit@ietf.org; Tue, 17 Jan 2006 11:13:19 -0500 Received: (qmail invoked by alias); 17 Jan 2006 16:04:42 -0000 Received: from xdsl-87-78-65-47.netcologne.de (EHLO [192.168.1.67]) [87.78.65.47] by mail.gmx.net (mp030) with SMTP; 17 Jan 2006 17:04:42 +0100 X-Authenticated: #29516787 Message-ID: <43CD1597.8060108@gmx.net> Date: Tue, 17 Jan 2006 17:04:39 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers References: <072C5B76F7CEAB488172C6F64B30B5E3FC796D@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3FC796D@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi mike, there is actually more than one "universal" identifier. i don't know which term we should use to refer to urn:service:sos urn:service:sos.fire urn:service:sos.police urn:service:sos.marine urn:service:sos.mountain urn:service:sos.rescue urn:service:sos.poison urn:service:sos.suicide urn:service:sos.mental-health (copy-and-paste from draft-schulzrinne-sipping-service-01.txt). the urn:service:sos.police identifier would be the "universal" identifier denoting a desire to place an emergency call to the police. ciao hannes Michael Hammer (mhammer) wrote: > BTW, if there is more than one identifier, then any identifier is no > longer "universal". > > The "one or more" universal requirement is an oxymoron. > > Mike > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Hannes Tschofenig >>Sent: Saturday, January 14, 2006 11:22 AM >>To: ecrit@ietf.org; Andrew Newton >>Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers >> >>hi andy, >>hi all, >> >>in order to close a few open issues i would to discuss issue#8. >>here is the text from the issue tracker: >> >>" >>Requirements A1a and A1b specify a universal identifier. >>These requirements specify "one or more." What are the >>requirements regarding adding new emergency identifiers? >>" >> >>currently there are no requirements regarding the >>registration or regarding future enhancements. can you think >>of something that should go into a requirements document? >> >>ciao >>hannes >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 11:12:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytRm-0002dG-Mg; Tue, 17 Jan 2006 11:12:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytRk-0002cx-LJ for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 11:12:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27357 for ; Tue, 17 Jan 2006 11:11:12 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EytZs-0005u4-9g for ecrit@ietf.org; Tue, 17 Jan 2006 11:21:02 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Jan 2006 11:12:24 -0500 X-IronPort-AV: i="3.99,377,1131339600"; d="scan'208"; a="80401073:sNHT3558862912" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0HGC9Jj028931; Tue, 17 Jan 2006 11:12:21 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 11:12:20 -0500 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: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 11:12:20 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3FC798D@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] issue 8: Addition of New Emergency Identifiers Thread-Index: AcYbf75bVQJ9hR27RzSACy1zVa1WVQAAMElw From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 17 Jan 2006 16:12:20.0358 (UTC) FILETIME=[CB156A60:01C61B80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ok, it wasn't clear if that referred to just the "universal emergency service scheme" or the 911, 112, ad nauseum numbering. The former is desirable, the latter tower of babel is not and should be relegated to being a user interface issue. Mike =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Tuesday, January 17, 2006 11:05 AM > To: Michael Hammer (mhammer) > Cc: ecrit@ietf.org; Andrew Newton > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers >=20 > hi mike, >=20 > there is actually more than one "universal" identifier. i=20 > don't know which term we should use to refer to >=20 > urn:service:sos > urn:service:sos.fire > urn:service:sos.police > urn:service:sos.marine > urn:service:sos.mountain > urn:service:sos.rescue > urn:service:sos.poison > urn:service:sos.suicide > urn:service:sos.mental-health >=20 > (copy-and-paste from draft-schulzrinne-sipping-service-01.txt). >=20 > the urn:service:sos.police identifier would be the "universal"=20 > identifier denoting a desire to place an emergency call to the police. >=20 > ciao > hannes >=20 > Michael Hammer (mhammer) wrote: > > BTW, if there is more than one identifier, then any=20 > identifier is no=20 > > longer "universal". > >=20 > > The "one or more" universal requirement is an oxymoron. > >=20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > >>Of Hannes Tschofenig > >>Sent: Saturday, January 14, 2006 11:22 AM > >>To: ecrit@ietf.org; Andrew Newton > >>Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers > >> > >>hi andy, > >>hi all, > >> > >>in order to close a few open issues i would to discuss issue#8. > >>here is the text from the issue tracker: > >> > >>" > >>Requirements A1a and A1b specify a universal identifier. =20 > >>These requirements specify "one or more." What are the=20 > requirements=20 > >>regarding adding new emergency identifiers? > >>" > >> > >>currently there are no requirements regarding the registration or=20 > >>regarding future enhancements. can you think of something=20 > that should=20 > >>go into a requirements document? > >> > >>ciao > >>hannes > >> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > >> > >=20 > >=20 > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 11:29:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytiI-0008MI-Kq; Tue, 17 Jan 2006 11:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytiG-0008MD-P9 for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 11:29:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28585 for ; Tue, 17 Jan 2006 11:28:15 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EytqP-0006Rf-7s for ecrit@ietf.org; Tue, 17 Jan 2006 11:38:06 -0500 Received: (qmail invoked by alias); 17 Jan 2006 16:29:29 -0000 Received: from xdsl-87-78-65-47.netcologne.de (EHLO [192.168.1.67]) [87.78.65.47] by mail.gmx.net (mp019) with SMTP; 17 Jan 2006 17:29:29 +0100 X-Authenticated: #29516787 Message-ID: <43CD1B5D.6080406@gmx.net> Date: Tue, 17 Jan 2006 17:29:17 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers References: <072C5B76F7CEAB488172C6F64B30B5E3FC798D@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3FC798D@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi mike i agree with you that the identifiers introduced in the sipping-service or sipping-sos drafts are not particularly attractive for the user interface. the good thing: the user interface are outside the scope of ecrit. we care for the stuff that travels over the wire. ciao hannes Michael Hammer (mhammer) wrote: > Ok, it wasn't clear if that referred to just the "universal emergency > service scheme" or the 911, 112, ad nauseum numbering. The former is > desirable, the latter tower of babel is not and should be relegated to > being a user interface issue. > > Mike > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Tuesday, January 17, 2006 11:05 AM >>To: Michael Hammer (mhammer) >>Cc: ecrit@ietf.org; Andrew Newton >>Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers >> >>hi mike, >> >>there is actually more than one "universal" identifier. i >>don't know which term we should use to refer to >> >> urn:service:sos >> urn:service:sos.fire >> urn:service:sos.police >> urn:service:sos.marine >> urn:service:sos.mountain >> urn:service:sos.rescue >> urn:service:sos.poison >> urn:service:sos.suicide >> urn:service:sos.mental-health >> >>(copy-and-paste from draft-schulzrinne-sipping-service-01.txt). >> >>the urn:service:sos.police identifier would be the "universal" >>identifier denoting a desire to place an emergency call to the police. >> >>ciao >>hannes >> >>Michael Hammer (mhammer) wrote: >> >>>BTW, if there is more than one identifier, then any >> >>identifier is no >> >>>longer "universal". >>> >>>The "one or more" universal requirement is an oxymoron. >>> >>>Mike >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: ecrit-bounces@ietf.org >> >>[mailto:ecrit-bounces@ietf.org] On Behalf >> >>>>Of Hannes Tschofenig >>>>Sent: Saturday, January 14, 2006 11:22 AM >>>>To: ecrit@ietf.org; Andrew Newton >>>>Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers >>>> >>>>hi andy, >>>>hi all, >>>> >>>>in order to close a few open issues i would to discuss issue#8. >>>>here is the text from the issue tracker: >>>> >>>>" >>>>Requirements A1a and A1b specify a universal identifier. >>>>These requirements specify "one or more." What are the >> >>requirements >> >>>>regarding adding new emergency identifiers? >>>>" >>>> >>>>currently there are no requirements regarding the registration or >>>>regarding future enhancements. can you think of something >> >>that should >> >>>>go into a requirements document? >>>> >>>>ciao >>>>hannes >>>> >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >>> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 11:45:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyty1-0004A6-5Z; Tue, 17 Jan 2006 11:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyty0-0004A1-6O for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 11:45:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29549 for ; Tue, 17 Jan 2006 11:44:31 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyu69-0006vr-Cw for ecrit@ietf.org; Tue, 17 Jan 2006 11:54:22 -0500 Received: from lion.cs.columbia.edu (IDENT:BZoXQ/lRYTfG7kag27Ws8fGGaaoiGN4E@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0HGjMGt014761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 17 Jan 2006 11:45:38 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0HGjLnE025381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jan 2006 11:45:22 -0500 Message-ID: <43CD1E97.2010009@cs.columbia.edu> Date: Tue, 17 Jan 2006 11:43:03 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers References: <072C5B76F7CEAB488172C6F64B30B5E3FC796D@xmb-rtp-20b.amer.cisco.com> <43CD1597.8060108@gmx.net> In-Reply-To: <43CD1597.8060108@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think the definition of universal ("including or covering all or a whole collectively or distributively without limit or exception") requires there to be just one identifier. The idea is that they are location-independent or globally valid. I don't know if substituting either of these terms would minimize confusion. Hannes Tschofenig wrote: > hi mike, > > there is actually more than one "universal" identifier. i don't know > which term we should use to refer to > > urn:service:sos > urn:service:sos.fire > urn:service:sos.police > urn:service:sos.marine > urn:service:sos.mountain > urn:service:sos.rescue > urn:service:sos.poison > urn:service:sos.suicide > urn:service:sos.mental-health > > (copy-and-paste from draft-schulzrinne-sipping-service-01.txt). > > the urn:service:sos.police identifier would be the "universal" > identifier denoting a desire to place an emergency call to the police. > > ciao > hannes > > Michael Hammer (mhammer) wrote: >> BTW, if there is more than one identifier, then any identifier is no >> longer "universal". >> >> The "one or more" universal requirement is an oxymoron. >> >> Mike >> >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Hannes Tschofenig >>> Sent: Saturday, January 14, 2006 11:22 AM >>> To: ecrit@ietf.org; Andrew Newton >>> Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers >>> >>> hi andy, >>> hi all, >>> >>> in order to close a few open issues i would to discuss issue#8. >>> here is the text from the issue tracker: >>> >>> " >>> Requirements A1a and A1b specify a universal identifier. These >>> requirements specify "one or more." What are the requirements >>> regarding adding new emergency identifiers? >>> " >>> >>> currently there are no requirements regarding the registration or >>> regarding future enhancements. can you think of something that should >>> go into a requirements document? >>> >>> ciao >>> hannes >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 11:54:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyu6a-00069z-2h; Tue, 17 Jan 2006 11:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyu6Y-00069j-J0 for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 11:54:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00024 for ; Tue, 17 Jan 2006 11:53:21 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyuEi-0007Ar-Lt for ecrit@ietf.org; Tue, 17 Jan 2006 12:03:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Eyu6U-0003rK-P4; Tue, 17 Jan 2006 10:54:43 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 11:52:41 -0500 Message-ID: <0e1601c61b86$717a5cd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <43CD069F.5000609@gmx.net> Thread-Index: AcYbdtFo318WCLtFTVC8zg8lS8b8/QADhV7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >this is certainly true. there is, however, a user interface issue here >too. the number the user dials does not necessarily need to appear on >the wire. Yes, that is the entire issue here. From the entity that does dial plan interpretation towards the proxy that does routing, we would see the universal URN. If the endpoint does dial plan interpretation, then the endpoint needs to know the local emergency dialing string to know when to substitute the universal URN. If a downstream proxy does dial plan interpretation, it needs to know the emergency number dial string for each of its clients (and we would see the dialstring on the wire) to do the same thing. Put this in concrete terms: I visit Chicago (where the dialstring is 911) from London (where the dialstring is 999). If my phone does dial plan interpretation, I dial 9-1-1 on my phone. The phone has to know that I'm in Chicago, and it has to know that in Chicago, the emergency dial string is 9-1-1. If the same phone visits Australia, it has to know it's in Australia, and it has to find out that the dialstring in Australia is 000. If my phone does not do dialplan interpretation, but my IP-PBX (in London) does, then my IP-PBX would have to figure out that I was in Chicago, and use some new mechanism to find out that 911 is the emergency dialstring. And so on... >so, if you always use the same emergency number but internally the sip >implementation uses, for example, >draft-schulzrinne-sipping-service-01.txt to represent the emergency call >on the wire then there is no need to define a mechanism for the end host >to dynamically retrieve country specific emergency numbers while abroad. No, see above, either the endpoint or a proxy needs to know the local dialstring so it can detect it, and put the universal URN on the INVITE. .... >it is a good question of who has to translate a locally known emergency >number to a such a global emergency identifier. if it is the end host >then there is probably no problem (or?). if this mapping is provided by >the sip proxy then every sip proxy theoretically needs to understand all >emergency numbers used in the world. there is no need to dynamically >configure these proxies since these numbers do not change frequently. If the end host does the dial plan interpretation, it needs to somehow determine what the local emergency dialstring is. If the proxy does it, it has to determine what the location of the endpoint is, and then use that to determine what the dialstring should be. There are no mechanisms for any of this. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 11:55:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyu7S-0006Fd-4w; Tue, 17 Jan 2006 11:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyu7Q-0006FQ-BB for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 11:55:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00096 for ; Tue, 17 Jan 2006 11:54:15 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyuFZ-0007C3-G8 for ecrit@ietf.org; Tue, 17 Jan 2006 12:04:06 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Jan 2006 08:55:30 -0800 X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="392671370:sNHT31489436" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0HGtTWF015079; Tue, 17 Jan 2006 08:55:29 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 08:55:29 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 08:55:28 -0800 From: "Marc Linsner" To: Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 11:55:28 -0500 Message-ID: <024801c61b86$d2503fc0$290d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcYbb/FIsPRR1DYfTiC+SMTA4zKAdAAALuAwAAUjkhA= In-Reply-To: <0ded01c61b72$647c0970$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 17 Jan 2006 16:55:29.0115 (UTC) FILETIME=[D21A62B0:01C61B86] X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, > The proxy has to learn BEFORE an emergency call is placed, > what the local emergency number is. That's pretty tough now. I realize ECRIT is dealing with emergency calling, but this problem pertains to all applications with roamers that use site-local numbers such as 211, 311, 411, etc. in North America. What is a SIP proxy located in Paris going to do with a UA located in Texas that invites tel:211 ? My point is this issue needs looked at outside of ECRIT. Whoever created site-local numbers now needs to figure this out....(kinda sounds like private addressing....) > Caching the HOME emergency number is conceivable, for either > the phone or the proxy, but only if there was some indication > of where home was. I am unaware of any mechanism that would > tell you that. You could conceivably configure that, I > guess, but you probably can't learn it. Caching in the phone > assumes some non-volatile, but endpoint writable storage. > Dunno if that is an acceptable requirement. Probably, it's okay. This is all based on the assumption that the user will know/attempt to dial the local emergency number vs. their HOME emergency number. As you state, the HOME emergency number is easy to cache/map, the local emergency number is difficult at best. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 12:01:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuDB-0007JO-Ps; Tue, 17 Jan 2006 12:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuD9-0007JJ-Lx for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 12:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00552 for ; Tue, 17 Jan 2006 12:00:10 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyuLG-0007Mk-ML for ecrit@ietf.org; Tue, 17 Jan 2006 12:10:02 -0500 Received: from [10.0.1.102] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 17 Jan 2006 12:00:39 -0500 id 01588001.43CD22B7.00002B76 In-Reply-To: <43CD1B5D.6080406@gmx.net> References: <072C5B76F7CEAB488172C6F64B30B5E3FC798D@xmb-rtp-20b.amer.cisco.com> <43CD1B5D.6080406@gmx.net> Mime-Version: 1.0 Message-Id: <407B244F-3DD5-4078-9D13-1895048AF43B@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 12:00:53 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1260816620==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1260816620== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-11130-1137517261-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-11130-1137517261-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 17, 2006, at 11:29 AM, Hannes Tschofenig wrote: > the good thing: the user interface are outside the scope of ecrit. > we care for the stuff that travels over the wire. I find it odd that in the IETF we usually consider the needs of network operators but we get to ignore the needs of network users. The "user interfaces are out of scope" mentality is a wholesale excuse for not pondering the problem closely enough. From a user interface perspective, I think more than 3 identifiers is overkill. Do we really want users to have scroll through a menu "types of emergency" just to make an emergency phone call? Anyway, Henning's draft is fine by me. And if it states how to add new identifiers, good (because it should). But that still doesn't mean we need a requirement that the system should be able to have new identifiers added to it when necessary. Henning's draft is just an implementation of the requirement. -andy --=_zeke.ecotroph.net-11130-1137517261-0001-2 Content-Type: text/html; charset=iso-8859-1 X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.52.1 Content-Transfer-Encoding: quoted-printable
On Jan 17, 2006, at 1= 1:29 AM, Hannes Tschofenig wrote:

the good thing: the user interface are outside the scope of ecrit. we= care for the stuff that travels over the wire.

=

I find it odd that in the IETF we usually consider the ne= eds of network operators but we get to ignore the needs of network users= .=A0 The "user interfaces are out of scope" mentality is a wholesale exc= use for not pondering the problem closely enough.

From a user interface perspective, = I think more than 3 identifiers is overkill.=A0 Do we really want users = to have scroll through a menu "types of emergency" just to make an emerg= ency phone call?

<= DIV>Anyway, Henning's draft is fine by me.=A0 And if it states how to ad= d new identifiers, good (because it should).=A0 But that still doesn't m= ean we need a requirement that the system should be able to have new ide= ntifiers added to it when necessary.=A0 Henning's draft is just an imple= mentation of the requirement.


-andy<= /DIV> --=_zeke.ecotroph.net-11130-1137517261-0001-2-- --===============1260816620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1260816620==-- From ecrit-bounces@ietf.org Tue Jan 17 12:21:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuWQ-0006LP-J1; Tue, 17 Jan 2006 12:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuWP-0006KB-0W for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 12:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02186 for ; Tue, 17 Jan 2006 12:20:04 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyueZ-00082D-Gg for ecrit@ietf.org; Tue, 17 Jan 2006 12:29:55 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EyuWJ-0005iF-RB; Tue, 17 Jan 2006 11:21:26 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 12:19:23 -0500 Message-ID: <0e2a01c61b8a$2c05c410$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <407B244F-3DD5-4078-9D13-1895048AF43B@hxr.us> Thread-Index: AcYbiGKTiorfCX9fQOy0n1ox/bO71gAALP1g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You never see the universal identifiers in a user interface. You map a local dialstring to them. If your local fire number is 877-0000 and your local police number is 878-0000 then those strings map to urn:service:sos.fire and usn:service:sos.police And, if a proxy does dial plan interpretation, then those dialstrings WILL be on the wire. They won't hit the mapping system; someone has to interpret sip:8770000;user=dialstring into urn:service:sos.fire first, but they appear on the wire between the phone and the proxy. The issue at hand is how does the dialplan interpreter find out what the local dialstrings are? I, for one, care a whole lot about how we get good user interfaces. I tend to be very vocal when I don't see how to do that. Brian ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Tuesday, January 17, 2006 12:01 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers On Jan 17, 2006, at 11:29 AM, Hannes Tschofenig wrote: the good thing: the user interface are outside the scope of ecrit. we care for the stuff that travels over the wire. I find it odd that in the IETF we usually consider the needs of network operators but we get to ignore the needs of network users. The "user interfaces are out of scope" mentality is a wholesale excuse for not pondering the problem closely enough. >From a user interface perspective, I think more than 3 identifiers is overkill. Do we really want users to have scroll through a menu "types of emergency" just to make an emergency phone call? Anyway, Henning's draft is fine by me. And if it states how to add new identifiers, good (because it should). But that still doesn't mean we need a requirement that the system should be able to have new identifiers added to it when necessary. Henning's draft is just an implementation of the requirement. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 12:59:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyv7A-0008ML-2w; Tue, 17 Jan 2006 12:59:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyv77-0008Lm-Sa for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 12:59:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04943 for ; Tue, 17 Jan 2006 12:57:59 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyvFE-0000ld-MM for ecrit@ietf.org; Tue, 17 Jan 2006 13:07:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 19:00:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4793@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] issue 8: Addition of New Emergency Identifiers Thread-Index: AcYZ8lfy8X8YU5NmRyWkDtrkHFfupQBiuyBgAASpBUI= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Hannes Tschofenig" , , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Mike, =20 >BTW, if there is more than one identifier, then any identifier is no >longer "universal". >The "one or more" universal requirement is an oxymoron. =20 I think you are confusing "universal" and "unique" If both 112 and 911 work on every SIP client and/or proxy, they are both "universal" =20 Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) Gesendet: Di 17.01.2006 16:48 An: Hannes Tschofenig; ecrit@ietf.org; Andrew Newton Betreff: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers BTW, if there is more than one identifier, then any identifier is no longer "universal". The "one or more" universal requirement is an oxymoron. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Saturday, January 14, 2006 11:22 AM > To: ecrit@ietf.org; Andrew Newton > Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers > > hi andy, > hi all, > > in order to close a few open issues i would to discuss issue#8. > here is the text from the issue tracker: > > " > Requirements A1a and A1b specify a universal identifier.=20 > These requirements specify "one or more." What are the > requirements regarding adding new emergency identifiers? > " > > currently there are no requirements regarding the > registration or regarding future enhancements. can you think > of something that should go into a requirements document? > > ciao > hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:17:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvOc-0004SH-Ji; Tue, 17 Jan 2006 13:17:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvOa-0004Rp-6l for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:17:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06152 for ; Tue, 17 Jan 2006 13:16:03 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvWi-0001JY-O3 for ecrit@ietf.org; Tue, 17 Jan 2006 13:25:55 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0HIHDkL015017 for ; Tue, 17 Jan 2006 12:17:13 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Jan 2006 18:17:12 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB011BDD7F1@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifier s Date: Tue, 17 Jan 2006 18:17:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In order to make sure that none of this is lost, can I quote the 3GPP requirements that need to be met: Subclause 10.1.1 of 3GPP TS 22.101 The ME shall identify a number or other identifier dialled by the end user as a valid emergency number/identifier and initiate emergency call establishment if it occurs under one or more of the following conditions. If it occurs outside of the following conditions, the ME should not initiate emergency call establishment but normal call establishment. a) 112, 911 and a global SIP URI reserved for emergency calls shall always be available. These numbers and identifiers shall be stored on the ME. b) Any emergency call number stored on a SIM/USIM when the SIM/USIM is present. c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME. d) Additional emergency call numbers that may have been downloaded by the serving network when the SIM/USIM is present. Subclause 10.1 (extract) of 3GPP TS 22.101 It shall be possible to initiate emergency calls to different emergency call centers, depending on the type of emergency. The following types of emergency calls shall be possible: - Police - Ambulance - Fire Brigade - Marine Guard - Mountain Rescue - Spare, at least [three] different types Henning took these into account in the documents he prepared for SIPPING,b ut ECRIT needs to be fully aware of them as well. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > Marc Linsner > Sent: 17 January 2006 16:55 > To: br@brianrosen.net > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency > Identifiers > > > Brian, > > > The proxy has to learn BEFORE an emergency call is placed, > > what the local emergency number is. That's pretty tough now. > > I realize ECRIT is dealing with emergency calling, but this > problem pertains > to all applications with roamers that use site-local numbers > such as 211, > 311, 411, etc. in North America. What is a SIP proxy located > in Paris going > to do with a UA located in Texas that invites tel:211 ? My > point is this > issue needs looked at outside of ECRIT. Whoever created > site-local numbers > now needs to figure this out....(kinda sounds like private > addressing....) > > > Caching the HOME emergency number is conceivable, for either > > the phone or the proxy, but only if there was some indication > > of where home was. I am unaware of any mechanism that would > > tell you that. You could conceivably configure that, I > > guess, but you probably can't learn it. Caching in the phone > > assumes some non-volatile, but endpoint writable storage. > > Dunno if that is an acceptable requirement. Probably, it's okay. > > This is all based on the assumption that the user will > know/attempt to dial > the local emergency number vs. their HOME emergency number. > As you state, > the HOME emergency number is easy to cache/map, the local > emergency number > is difficult at best. > > -Marc- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:20:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvR2-0004kF-0C; Tue, 17 Jan 2006 13:20:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvR0-0004i5-8l for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:19:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06358 for ; Tue, 17 Jan 2006 13:18:33 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvZ9-0001Ol-SO for ecrit@ietf.org; Tue, 17 Jan 2006 13:28:25 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2006 10:19:47 -0800 X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="1767368762:sNHT33004680" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0HIJfWP018275; Tue, 17 Jan 2006 10:19:47 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 13:19:46 -0500 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: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 13:19:45 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3FC7A34@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] issue 8: Addition of New Emergency Identifiers Thread-Index: AcYZ8lfy8X8YU5NmRyWkDtrkHFfupQBiuyBgAASpBUIAAJUJoA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Hannes Tschofenig" , , "Andrew Newton" X-OriginalArrivalTime: 17 Jan 2006 18:19:46.0721 (UTC) FILETIME=[98ABD110:01C61B92] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No, to me universal means it works anywhere in the universe. When an identifier only works in one geographic area and not other, it is no longer universal. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, January 17, 2006 1:01 PM > To: Michael Hammer (mhammer); Hannes Tschofenig;=20 > ecrit@ietf.org; Andrew Newton > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers >=20 > Hi Mike, > =20 > >BTW, if there is more than one identifier, then any identifier is no=20 > >longer "universal". >=20 > >The "one or more" universal requirement is an oxymoron. >=20 > =20 > I think you are confusing "universal" and "unique" >=20 > If both 112 and 911 work on every SIP client and/or proxy,=20 > they are both "universal" > =20 > Richard >=20 > ________________________________ >=20 > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > Gesendet: Di 17.01.2006 16:48 > An: Hannes Tschofenig; ecrit@ietf.org; Andrew Newton > Betreff: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers >=20 >=20 >=20 > BTW, if there is more than one identifier, then any=20 > identifier is no longer "universal". >=20 > The "one or more" universal requirement is an oxymoron. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Hannes Tschofenig > > Sent: Saturday, January 14, 2006 11:22 AM > > To: ecrit@ietf.org; Andrew Newton > > Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > > hi andy, > > hi all, > > > > in order to close a few open issues i would to discuss issue#8. > > here is the text from the issue tracker: > > > > " > > Requirements A1a and A1b specify a universal identifier.=20 > > These requirements specify "one or more." What are the=20 > requirements=20 > > regarding adding new emergency identifiers? > > " > > > > currently there are no requirements regarding the registration or=20 > > regarding future enhancements. can you think of something=20 > that should=20 > > go into a requirements document? > > > > ciao > > hannes > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:20:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvRi-0004xu-IY; Tue, 17 Jan 2006 13:20:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvRh-0004xn-5W for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:20:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06450 for ; Tue, 17 Jan 2006 13:19:16 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvZq-0001Rt-KT for ecrit@ietf.org; Tue, 17 Jan 2006 13:29:08 -0500 Received: from [10.0.1.102] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 17 Jan 2006 13:19:59 -0500 id 0158801C.43CD354F.00003C3C In-Reply-To: <0e2a01c61b8a$2c05c410$640fa8c0@cis.neustar.com> References: <0e2a01c61b8a$2c05c410$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D9F13AF-F958-4E6B-AE13-F75EB94FE0C8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 13:20:20 -0500 To: br@brianrosen.net X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am not at all sure this discussion is entirely about dialplans. Surely, they are part of the problem. To be truthful, I was focusing on the "emergency button" which I am told UAs are starting to have or will have. I have actually never seen one on a phone, though I have seen them on alarm systems. In those cases, it has always been "police", "fire", and "medical". But getting to the dialplan issue. In North American, why would I be dialing 877-0000 instead of 911? And when I dial 911, who do I get? The police? The fire department? I suspect it is a call center that can dispatch both based on what information I convey via voice. I was also under the impression a large part of the problem is the mobility of the UA. If I take my North American phone to the UK and dial 911, shouldn't it convert 911 to urn:service:sos? Would it being doing the right thing by converting 911 to urn:service:sos:police? What if I am trying to report a fire? As to the issue of the proxy, I don't get it. If I'm in the habit of dialing 911 in both Wichita and London and the proxy is in the habit of converting that number to urn:service:sos, what is the issue? Do we actually have a problem statement written on this requirement? That might help. -andy On Jan 17, 2006, at 12:19 PM, Brian Rosen wrote: > You never see the universal identifiers in a user interface. You > map a > local dialstring to them. If your local fire number is 877-0000 > and your > local police number is 878-0000 then those strings map to > urn:service:sos.fire and usn:service:sos.police > > And, if a proxy does dial plan interpretation, then those > dialstrings WILL > be on the wire. They won't hit the mapping system; someone has to > interpret > sip:8770000;user=dialstring into urn:service:sos.fire first, but > they appear > on the wire between the phone and the proxy. > > The issue at hand is how does the dialplan interpreter find out > what the > local dialstrings are? > > I, for one, care a whole lot about how we get good user > interfaces. I tend > to be very vocal when I don't see how to do that. > > Brian > > ________________________________________ > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Andrew Newton > Sent: Tuesday, January 17, 2006 12:01 PM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > On Jan 17, 2006, at 11:29 AM, Hannes Tschofenig wrote: > > > the good thing: the user interface are outside the scope of ecrit. > we care > for the stuff that travels over the wire. > > I find it odd that in the IETF we usually consider the needs of > network > operators but we get to ignore the needs of network users. The "user > interfaces are out of scope" mentality is a wholesale excuse for not > pondering the problem closely enough. > > From a user interface perspective, I think more than 3 identifiers is > overkill. Do we really want users to have scroll through a menu > "types of > emergency" just to make an emergency phone call? > > Anyway, Henning's draft is fine by me. And if it states how to add new > identifiers, good (because it should). But that still doesn't mean > we need a > requirement that the system should be able to have new identifiers > added to > it when necessary. Henning's draft is just an implementation of the > requirement. > > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:27:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvYF-00068X-II; Tue, 17 Jan 2006 13:27:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvYC-00067N-Sx for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:27:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06872 for ; Tue, 17 Jan 2006 13:25:59 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvgJ-0001fh-3m for ecrit@ietf.org; Tue, 17 Jan 2006 13:35:52 -0500 Received: from lion.cs.columbia.edu (IDENT:P+rpgpVAJWafR7so/npMblhxraGnzCFr@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0HIQwGt010376 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 17 Jan 2006 13:27:16 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0HIQvnE031673 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jan 2006 13:26:58 -0500 Message-ID: <43CD3667.6040700@cs.columbia.edu> Date: Tue, 17 Jan 2006 13:24:39 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifier s References: <475FF955A05DD411980D00508B6D5FB011BDD7F1@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB011BDD7F1@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Keith, unfortunately, given that SIP devices may need to work in enterprise environments, this approach of hard-coding two- and three-digit extensions is going to run into practical problems. Clearly, IMS devices can use a configuration mechanism to provide such numbers, but it may not be generalizable to all SIP devices. Henning Drage, Keith (Keith) wrote: > In order to make sure that none of this is lost, can I quote the 3GPP requirements that need to be met: > > Subclause 10.1.1 of 3GPP TS 22.101 > > The ME shall identify a number or other identifier dialled by the end user as a valid emergency number/identifier and initiate emergency call establishment if it occurs under one or more of the following conditions. If it occurs outside of the following conditions, the ME should not initiate emergency call establishment but normal call establishment. > a) 112, 911 and a global SIP URI reserved for emergency calls shall always be available. These numbers and identifiers shall be stored on the ME. > b) Any emergency call number stored on a SIM/USIM when the SIM/USIM is present. > c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME. > d) Additional emergency call numbers that may have been downloaded by the serving network when the SIM/USIM is present. > > Subclause 10.1 (extract) of 3GPP TS 22.101 > > It shall be possible to initiate emergency calls to different emergency call centers, depending on the type of emergency. The following types of emergency calls shall be possible: > - Police > - Ambulance > - Fire Brigade > - Marine Guard > - Mountain Rescue > - Spare, at least [three] different types > > Henning took these into account in the documents he prepared for SIPPING,b ut ECRIT needs to be fully aware of them as well. > > regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org]On Behalf Of >> Marc Linsner >> Sent: 17 January 2006 16:55 >> To: br@brianrosen.net >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency >> Identifiers >> >> >> Brian, >> >>> The proxy has to learn BEFORE an emergency call is placed, >>> what the local emergency number is. That's pretty tough now. >> I realize ECRIT is dealing with emergency calling, but this >> problem pertains >> to all applications with roamers that use site-local numbers >> such as 211, >> 311, 411, etc. in North America. What is a SIP proxy located >> in Paris going >> to do with a UA located in Texas that invites tel:211 ? My >> point is this >> issue needs looked at outside of ECRIT. Whoever created >> site-local numbers >> now needs to figure this out....(kinda sounds like private >> addressing....) >> >>> Caching the HOME emergency number is conceivable, for either >>> the phone or the proxy, but only if there was some indication >>> of where home was. I am unaware of any mechanism that would >>> tell you that. You could conceivably configure that, I >>> guess, but you probably can't learn it. Caching in the phone >>> assumes some non-volatile, but endpoint writable storage. >>> Dunno if that is an acceptable requirement. Probably, it's okay. >> This is all based on the assumption that the user will >> know/attempt to dial >> the local emergency number vs. their HOME emergency number. >> As you state, >> the HOME emergency number is easy to cache/map, the local >> emergency number >> is difficult at best. >> >> -Marc- >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:32:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvdJ-0007hr-Fe; Tue, 17 Jan 2006 13:32:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvdI-0007hm-FO for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:32:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07170 for ; Tue, 17 Jan 2006 13:31:15 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyvlS-0001p5-9a for ecrit@ietf.org; Tue, 17 Jan 2006 13:41:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 19:34:15 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4794@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] issue 8: Addition of New Emergency Identifiers Thread-Index: AcYZ8lfy8X8YU5NmRyWkDtrkHFfupQBiuyBgAASpBUIAAJUJoAAAmHxv From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Hannes Tschofenig" , , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >From issue30 (Keith 3GPP req) =20 > a) 112, 911 and a global SIP URI reserved for emergency calls shall = always be available. These numbers and identifiers shall be stored >on = the ME. =20 Thats what I meant with "Universal" (although I do not know if it works on Mars ;-) Richard =20 ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Di 17.01.2006 19:19 An: Stastny Richard; Hannes Tschofenig; ecrit@ietf.org; Andrew Newton Betreff: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers No, to me universal means it works anywhere in the universe. When an identifier only works in one geographic area and not other, it is no longer universal. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, January 17, 2006 1:01 PM > To: Michael Hammer (mhammer); Hannes Tschofenig; > ecrit@ietf.org; Andrew Newton > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers > > Hi Mike, >=20 > >BTW, if there is more than one identifier, then any identifier is no > >longer "universal". > > >The "one or more" universal requirement is an oxymoron. > >=20 > I think you are confusing "universal" and "unique" > > If both 112 and 911 work on every SIP client and/or proxy, > they are both "universal" >=20 > Richard > > ________________________________ > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > Gesendet: Di 17.01.2006 16:48 > An: Hannes Tschofenig; ecrit@ietf.org; Andrew Newton > Betreff: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > > BTW, if there is more than one identifier, then any > identifier is no longer "universal". > > The "one or more" universal requirement is an oxymoron. > > Mike > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Saturday, January 14, 2006 11:22 AM > > To: ecrit@ietf.org; Andrew Newton > > Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > > hi andy, > > hi all, > > > > in order to close a few open issues i would to discuss issue#8. > > here is the text from the issue tracker: > > > > " > > Requirements A1a and A1b specify a universal identifier. > > These requirements specify "one or more." What are the > requirements > > regarding adding new emergency identifiers? > > " > > > > currently there are no requirements regarding the registration or > > regarding future enhancements. can you think of something > that should > > go into a requirements document? > > > > ciao > > hannes > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:43:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyvnq-0001fJ-AZ; Tue, 17 Jan 2006 13:43:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyvnn-0001f8-UD for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:43:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07950 for ; Tue, 17 Jan 2006 13:42:06 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyvvy-0002Ah-Ti for ecrit@ietf.org; Tue, 17 Jan 2006 13:51:59 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2006 10:43:22 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="19895594:sNHT25299324" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0HIhH6J000431; Tue, 17 Jan 2006 13:43:20 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 13:43:15 -0500 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: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 13:43:14 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3FC7A54@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] issue 8: Addition of New Emergency Identifiers Thread-Index: AcYZ8lfy8X8YU5NmRyWkDtrkHFfupQBiuyBgAASpBUIAAJUJoAAAmHxvAAAiF8A= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Hannes Tschofenig" , , "Andrew Newton" X-OriginalArrivalTime: 17 Jan 2006 18:43:15.0838 (UTC) FILETIME=[E09201E0:01C61B95] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I would agree that if all SIP UA would take those dial patterns and translate to an "sos" urn on the wire understood by all infrastructure, then it would be universal. One thing I have not seen on these threads is the issue that there are collisions of those digit patterns, i.e. where 112 means emergency in one location, but directory (or some other) service in another location. Perhaps the button or icon/munu item approach would overcome the legacy stimulus input approach. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, January 17, 2006 1:34 PM > To: Michael Hammer (mhammer); Hannes Tschofenig;=20 > ecrit@ietf.org; Andrew Newton > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers >=20 > From issue30 (Keith 3GPP req) > =20 > > a) 112, 911 and a global SIP URI reserved for emergency=20 > calls shall always be available. These numbers and=20 > identifiers shall be stored >on the ME. > =20 > Thats what I meant with "Universal" >=20 >=20 > (although I do not know if it works on Mars ;-) >=20 >=20 >=20 > Richard > =20 >=20 > ________________________________ >=20 > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Gesendet: Di 17.01.2006 19:19 > An: Stastny Richard; Hannes Tschofenig; ecrit@ietf.org; Andrew Newton > Betreff: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers >=20 >=20 >=20 > No, to me universal means it works anywhere in the universe. >=20 > When an identifier only works in one geographic area and not=20 > other, it is no longer universal. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, January 17, 2006 1:01 PM > > To: Michael Hammer (mhammer); Hannes Tschofenig; ecrit@ietf.org;=20 > > Andrew Newton > > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > > Hi Mike, > >=20 > > >BTW, if there is more than one identifier, then any=20 > identifier is no=20 > > >longer "universal". > > > > >The "one or more" universal requirement is an oxymoron. > > > >=20 > > I think you are confusing "universal" and "unique" > > > > If both 112 and 911 work on every SIP client and/or proxy, they are=20 > > both "universal" > >=20 > > Richard > > > > ________________________________ > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > Gesendet: Di 17.01.2006 16:48 > > An: Hannes Tschofenig; ecrit@ietf.org; Andrew Newton > > Betreff: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > > > > > > BTW, if there is more than one identifier, then any=20 > identifier is no=20 > > longer "universal". > > > > The "one or more" universal requirement is an oxymoron. > > > > Mike > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Hannes Tschofenig > > > Sent: Saturday, January 14, 2006 11:22 AM > > > To: ecrit@ietf.org; Andrew Newton > > > Subject: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > > > > hi andy, > > > hi all, > > > > > > in order to close a few open issues i would to discuss issue#8. > > > here is the text from the issue tracker: > > > > > > " > > > Requirements A1a and A1b specify a universal identifier. > > > These requirements specify "one or more." What are the > > requirements > > > regarding adding new emergency identifiers? > > > " > > > > > > currently there are no requirements regarding the registration or=20 > > > regarding future enhancements. can you think of something > > that should > > > go into a requirements document? > > > > > > ciao > > > hannes > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 13:49:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyvts-00031C-Io; Tue, 17 Jan 2006 13:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyvtr-00030b-9z for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 13:49:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08387 for ; Tue, 17 Jan 2006 13:48:22 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyw22-0002OU-I9 for ecrit@ietf.org; Tue, 17 Jan 2006 13:58:14 -0500 Received: from lion.cs.columbia.edu (IDENT:ifHsIUYEbQisNYTO2Uu3aYrRd1lnS/mr@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0HIjcGt015349 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 17 Jan 2006 13:49:33 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0HIjcnE000406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jan 2006 13:45:38 -0500 Message-ID: <43CD3AC8.50900@cs.columbia.edu> Date: Tue, 17 Jan 2006 13:43:20 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <024801c61b86$d2503fc0$290d0d0a@amer.cisco.com> In-Reply-To: <024801c61b86$d2503fc0$290d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > I realize ECRIT is dealing with emergency calling, but this problem pertains > to all applications with roamers that use site-local numbers such as 211, > 311, 411, etc. in North America. What is a SIP proxy located in Paris going > to do with a UA located in Texas that invites tel:211 ? My point is this > issue needs looked at outside of ECRIT. Whoever created site-local numbers > now needs to figure this out....(kinda sounds like private addressing....) Note that tel:211 (or tel:911) are *not* valid tel URIs. They would only be valid with a context parameter. I will note that the mechanism I describe in http://www.cs.columbia.edu/sip/draft/lump/draft-schulzrinne-ecrit-lump-01.html#anchor3 is generalizable to other services. The solution assumes that the dial string representation in draft-rosen-iptel-dialstring-02 is invertible, i.e., a device can take something like sip:911@somewhere;user=dialstring and recognize that it matches the digits "9" "1" "1" dialed by a user. Alternatively, the protocol would have to convey dial strings formatted as, say, KPML or MGCP. > >> Caching the HOME emergency number is conceivable, for either >> the phone or the proxy, but only if there was some indication >> of where home was. I am unaware of any mechanism that would >> tell you that. You could conceivably configure that, I >> guess, but you probably can't learn it. Caching in the phone >> assumes some non-volatile, but endpoint writable storage. >> Dunno if that is an acceptable requirement. Probably, it's okay. > > This is all based on the assumption that the user will know/attempt to dial > the local emergency number vs. their HOME emergency number. As you state, > the HOME emergency number is easy to cache/map, the local emergency number > is difficult at best. I suspect the right behavior is something like: - Device gets configured manually or by the user's home provider with one or more "home" emergency numbers, e.g., using the SIP configuration mechanism. This could be based on the customer's billing address or some user selection. IMS devices not used in a corporate PBX setting will also acquire the list of "default" identifiers that way. All devices will have non-volatile storage, if only to store the user credentials, so I can't see that as a problem. - When roaming, the device uses its location to ask for the local dialplan entries (dial string -> service URN pairs, to be precise). If a user dials one of the strings, the device emits a service URN. - Proxies also create a mapping table from (SIP dialstring URLs, location) tuples to service URNs. As noted, proxies can pre-populate these tables as long as the granularity for the mappings is based on countries. Even Quebec or the French-speaking part of Belgium seem to have decided to stick with the overall national emergency number(s). Leaving aside the mechanisms needed, would this work? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 14:02:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyw6U-0006WF-Hl; Tue, 17 Jan 2006 14:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyw6S-0006WA-Il for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 14:02:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09505 for ; Tue, 17 Jan 2006 14:01:23 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EywEb-0002rI-Vw for ecrit@ietf.org; Tue, 17 Jan 2006 14:11:16 -0500 Received: from lion.cs.columbia.edu (IDENT:ckK+POgCUVeuMBKJoY8A8/dfHwwB/IFy@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0HIwWGt018338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 17 Jan 2006 14:02:37 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0HIwVnE001068 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jan 2006 13:58:32 -0500 Message-ID: <43CD3DCD.3080507@cs.columbia.edu> Date: Tue, 17 Jan 2006 13:56:13 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <0de101c61b6c$27568f80$640fa8c0@cis.neustar.com> <7C53D896-8D4E-48C3-9D0D-CF3B9BC30B08@cs.columbia.edu> <43CD0654.9030405@gmx.net> In-Reply-To: <43CD0654.9030405@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > do i understand you right that you would like to provide a configuration > mechanism for the end host so that the user can dial a local emergency > number and then this local emergency number is mapped to a global > emergency identifer at the end host. right? Yes. (I'm assuming "local" here means the valid emergency telephone number used in the geographic vicinity the user finds himself in.) There are two reasons: - Naturally, if somebody visits a foreign country and sees a firetruck with 999 on the side, he or she expects to be able to dial that number and summon that fire truck (or its cousin); - There's the "tourist collapses, good samaritan finds tourist cell phone and dials local emergency number" case. This has to work whether there's an outbound proxy in the visited country or the tourist's home country. (I suspect localized outbound proxies will be rare, but nevertheless.) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 14:31:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EywYQ-0004Aw-T1; Tue, 17 Jan 2006 14:31:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EywYP-0004Ar-6z for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 14:31:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11725 for ; Tue, 17 Jan 2006 14:30:15 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eywga-0003i4-Pr for ecrit@ietf.org; Tue, 17 Jan 2006 14:40:09 -0500 Received: from [10.0.1.102] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 17 Jan 2006 14:30:49 -0500 id 0158801C.43CD45EA.00004B73 In-Reply-To: <43CD3AC8.50900@cs.columbia.edu> References: <024801c61b86$d2503fc0$290d0d0a@amer.cisco.com> <43CD3AC8.50900@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <8973D738-E6B9-48E4-9440-57B883ECA3A2@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 14:31:05 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2132301298==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============2132301298== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-19318-1137526269-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-19318-1137526269-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I must be missing a large part of the context. On Jan 17, 2006, at 1:43 PM, Henning Schulzrinne wrote: > - Device gets configured manually or by the user's home provider > with one or more "home" emergency numbers, e.g., using the SIP > configuration mechanism. This could be based on the customer's > billing address or some user selection. What do you mean my "home" emergency number? Is it 911? Or is it +1-212-555-1234? If is something like 911, then it could just be configured with that information based upon where you bought the phone. > IMS devices not used in a corporate PBX setting will also acquire > the list of "default" identifiers that way. > > All devices will have non-volatile storage, if only to store the > user credentials, so I can't see that as a problem. > > - When roaming, the device uses its location to ask for the local > dialplan entries (dial string -> service URN pairs, to be precise). > If a user dials one of the strings, the device emits a service URN. What was the point of being configured with a "home" emergency number if the device is translating location-specific emergency numbers into URNs? > - Proxies also create a mapping table from (SIP dialstring URLs, > location) tuples to service URNs. As noted, proxies can pre- > populate these tables as long as the granularity for the mappings > is based on countries. Even Quebec or the French-speaking part of > Belgium seem to have decided to stick with the overall national > emergency number(s). Shouldn't the proxy be translating the "home" emergency number to a URN? Isn't that the number the user will dial? What about? 1) Device gets configured as you stated above. 2) Device translates all configured emergency numbers to URN. 3) URN is handed to the mapping service (along with location), which then hands back a PSAP URI. -andy --=_zeke.ecotroph.net-19318-1137526269-0001-2 Content-Type: text/html; charset=iso-8859-1 X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.52.1 Content-Transfer-Encoding: quoted-printable
I must be missing a large part= of the context.

On Jan 17, 2006, at 1:43 PM, Henning= Schulzrinne wrote:

- Device ge= ts configured manually or by the user's home provider with one or more "= home" emergency numbers, e.g., using the SIP configuration mechanism. Th= is could be based on the customer's billing address or some user selecti= on.


<= /DIV>
What do you mean my "home" emergency number?=A0 Is it 911?=A0 = Or is it +1-212-555-1234?

If is something like 911, then it could just be configured = with that information based upon where you bought the phone.

IMS de= vices not used in a corporate PBX setting will also acquire the list of = "default" identifiers that way.


All devices will have non-volatile = storage, if only to store the user credentials, so I can't see that as a= problem.


- When roaming, the device uses its location to ask for= the local dialplan entries (dial string -> service URN pairs, to be = precise). If a user dials one of the strings, the device emits a service= URN.


What was the point of being configured with a "home" emergen= cy number if the device is translating location-specific emergency numbe= rs into URNs?

- Proxies also create a mapping table from (SIP dials= tring URLs, location) tuples to service URNs. As noted, proxies can pre-= populate these tables as long as the granularity for the mappings is bas= ed on countries. Even Quebec or the French-speaking part of Belgium seem= to have decided to stick with the overall national emergency number(s).=


Shouldn't the proxy be translati= ng the "home" emergency number to a URN?=A0 Isn't that the number the us= er will dial?

What about?
1) Device gets configured as you stated above.
2) Device translates all configured emergency numbers to URN.
3) URN is handed to the mapping service (along with location), w= hich then hands back a PSAP URI.

-andy
--=_zeke.ecotroph.net-19318-1137526269-0001-2-- --===============2132301298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2132301298==-- From ecrit-bounces@ietf.org Tue Jan 17 14:42:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eywiu-000679-3c; Tue, 17 Jan 2006 14:42:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eywit-00066h-2g for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 14:42:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12303 for ; Tue, 17 Jan 2006 14:41:05 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eywr4-00040h-NV for ecrit@ietf.org; Tue, 17 Jan 2006 14:50:59 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Eywik-0008D4-GB; Tue, 17 Jan 2006 13:42:23 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 14:40:15 -0500 Message-ID: <0e5b01c61b9d$da1dcf80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7D9F13AF-F958-4E6B-AE13-F75EB94FE0C8@hxr.us> Thread-Index: AcYbkrOo1mGpMDrDQsSaE+Oa8xEwtwACaK4w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Generally, the emergency services guys don't like emergency buttons. They were common on cellphones for a while, but have been completely eliminated because of too many false alarms. I keep thinking it would work if you needed confirmation, but the 9-1-1 guys say it takes 4 keypresses to place a 9-1-1 call on a cell phone, it really doesn't ever happen accidently, and that's the way they like it. There are people who apparently put 9-1-1 on a speed dial, and then they do get false alarms. The current system can't actually handle a "police" button; every button would have to do the same thing - call 9-1-1 (in North America). In the new system, we can do something with it, albeit it's likely the call will be processed exactly the same whether you press "Police", "Fire" or "Medical". It will route the same, the same person would answer, but the call processing and operator displays may be different. Part of any emergency call handling is classification, and it can only help if the user starts the classification. They are unlikely to actually believe in self classification; they will always verify. There are places in North America where 9-1-1 does not work. Of course there are many places in the world where there is not a single emergency number. The solutions we are proposing work in all circumstances. I believe Henning and I agree that habits are hard to break, and if you roam a North American phone into London, dialing 9-1-1 should summon help. We also believe that dialing 9-9-9 should work. This means that whoever interprets the dialplan (the phone or a proxy located wherever) must be able to know what your "home" emergency dialstring is as well as what the local one where you are now is. The "home" strings could conceivably be provisioned, because your home carrier probably has a good idea where your home actually is. The local strings have to be discovered dynamically. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, January 17, 2006 1:20 PM To: br@brianrosen.net Cc: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers I am not at all sure this discussion is entirely about dialplans. Surely, they are part of the problem. To be truthful, I was focusing on the "emergency button" which I am told UAs are starting to have or will have. I have actually never seen one on a phone, though I have seen them on alarm systems. In those cases, it has always been "police", "fire", and "medical". But getting to the dialplan issue. In North American, why would I be dialing 877-0000 instead of 911? And when I dial 911, who do I get? The police? The fire department? I suspect it is a call center that can dispatch both based on what information I convey via voice. I was also under the impression a large part of the problem is the mobility of the UA. If I take my North American phone to the UK and dial 911, shouldn't it convert 911 to urn:service:sos? Would it being doing the right thing by converting 911 to urn:service:sos:police? What if I am trying to report a fire? As to the issue of the proxy, I don't get it. If I'm in the habit of dialing 911 in both Wichita and London and the proxy is in the habit of converting that number to urn:service:sos, what is the issue? Do we actually have a problem statement written on this requirement? That might help. -andy On Jan 17, 2006, at 12:19 PM, Brian Rosen wrote: > You never see the universal identifiers in a user interface. You > map a > local dialstring to them. If your local fire number is 877-0000 > and your > local police number is 878-0000 then those strings map to > urn:service:sos.fire and usn:service:sos.police > > And, if a proxy does dial plan interpretation, then those > dialstrings WILL > be on the wire. They won't hit the mapping system; someone has to > interpret > sip:8770000;user=dialstring into urn:service:sos.fire first, but > they appear > on the wire between the phone and the proxy. > > The issue at hand is how does the dialplan interpreter find out > what the > local dialstrings are? > > I, for one, care a whole lot about how we get good user > interfaces. I tend > to be very vocal when I don't see how to do that. > > Brian > > ________________________________________ > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Andrew Newton > Sent: Tuesday, January 17, 2006 12:01 PM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers > > > On Jan 17, 2006, at 11:29 AM, Hannes Tschofenig wrote: > > > the good thing: the user interface are outside the scope of ecrit. > we care > for the stuff that travels over the wire. > > I find it odd that in the IETF we usually consider the needs of > network > operators but we get to ignore the needs of network users. The "user > interfaces are out of scope" mentality is a wholesale excuse for not > pondering the problem closely enough. > > From a user interface perspective, I think more than 3 identifiers is > overkill. Do we really want users to have scroll through a menu > "types of > emergency" just to make an emergency phone call? > > Anyway, Henning's draft is fine by me. And if it states how to add new > identifiers, good (because it should). But that still doesn't mean > we need a > requirement that the system should be able to have new identifiers > added to > it when necessary. Henning's draft is just an implementation of the > requirement. > > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 17 14:48:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eywof-0007IT-FL; Tue, 17 Jan 2006 14:48:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eywod-0007He-3t for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 14:48:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12660 for ; Tue, 17 Jan 2006 14:46:58 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eywwl-0004Bb-HU for ecrit@ietf.org; Tue, 17 Jan 2006 14:56:52 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EywoS-0000BO-7E; Tue, 17 Jan 2006 13:48:21 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Tue, 17 Jan 2006 14:46:10 -0500 Message-ID: <0e5e01c61b9e$aed141d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8973D738-E6B9-48E4-9440-57B883ECA3A2@hxr.us> Thread-Index: AcYbnRc4SYqe2pXvQiaBrTcoQrkbPQAAOIqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.3 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928355512==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0928355512== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E5F_01C61B74.C5FB39D0" This is a multi-part message in MIME format. ------=_NextPart_000_0E5F_01C61B74.C5FB39D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit See in line _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Tuesday, January 17, 2006 2:31 PM To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers I must be missing a large part of the context. On Jan 17, 2006, at 1:43 PM, Henning Schulzrinne wrote: - Device gets configured manually or by the user's home provider with one or more "home" emergency numbers, e.g., using the SIP configuration mechanism. This could be based on the customer's billing address or some user selection. What do you mean my "home" emergency number? Is it 911? Or is it +1-212-555-1234? Well, in most places in the U.S., it would be 9-1-1, but there are some places where it would be an E.164. Of course, we need an international solution, so the general case is it's an arbitrary dialstring, inclusive of E.164s If is something like 911, then it could just be configured with that information based upon where you bought the phone. Nah, "where you bought the phone" is not the issue. Where "home" is would be the issue. Configuration could probably handle this. IMS devices not used in a corporate PBX setting will also acquire the list of "default" identifiers that way. All devices will have non-volatile storage, if only to store the user credentials, so I can't see that as a problem. - When roaming, the device uses its location to ask for the local dialplan entries (dial string -> service URN pairs, to be precise). If a user dials one of the strings, the device emits a service URN. What was the point of being configured with a "home" emergency number if the device is translating location-specific emergency numbers into URNs? Because someone has to recognize the home emergency number and translate it into the appropriate universal URN. - Proxies also create a mapping table from (SIP dialstring URLs, location) tuples to service URNs. As noted, proxies can pre-populate these tables as long as the granularity for the mappings is based on countries. Even Quebec or the French-speaking part of Belgium seem to have decided to stick with the overall national emergency number(s). Shouldn't the proxy be translating the "home" emergency number to a URN? Isn't that the number the user will dial? The user dials the home number (or the "visited" number). Some entity, possibly the phone, translates to the universal URN What about? 1) Device gets configured as you stated above. 2) Device translates all configured emergency numbers to URN. 3) URN is handed to the mapping service (along with location), which then hands back a PSAP URI. If the phone does dialplan interpretation, that works for the home number, but not for the visited number. If a proxy does dialplan interpretation, it doesn't work; the proxy has to know what home is, and also has to know what visited is. -andy ------=_NextPart_000_0E5F_01C61B74.C5FB39D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See in = line

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton
Sent: Tuesday, January = 17, 2006 2:31 PM
To: Henning = Schulzrinne
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] = Issue 30: Requirements regarding Emergency = Identifiers

 

I must be missing a large part of the = context.

 

On Jan 17, 2006, at 1:43 PM, Henning Schulzrinne = wrote:



- Device gets configured = manually or by the user's home provider with one or more "home" = emergency numbers, e.g., using the SIP configuration mechanism. This could be = based on the customer's billing address or some user = selection.

 

What do you mean my "home" emergency number? Is it = 911? Or is it +1-212-555-1234?

Well, in most places in the = U.S., it would be 9-1-1, but there are some places where it would be an E.164. =   Of course, we need an international solution, so the general case is = it’s an arbitrary dialstring, inclusive of E.164s

 

If is something like 911, then it could just be configured with = that information based upon where you bought the = phone.

Nah, “where you bought the = phone” is not the issue.  Where “home” is would be the issue. =  Configuration could probably handle this.



IMS devices not used in = a corporate PBX setting will also acquire the list of "default" identifiers that way.

 <= /font>

All devices will have non-volatile storage, if only to store the user credentials, so I can't = see that as a problem.

 <= /font>

- When roaming, the = device uses its location to ask for the local dialplan entries (dial string -> = service URN pairs, to be precise). If a user dials one of the strings, the = device emits a service URN.

 

What was the point of being configured with a "home" emergency number if the device is translating location-specific = emergency numbers into URNs?

Because someone has to recognize = the home emergency number and translate it into the appropriate universal = URN.



- Proxies also create a = mapping table from (SIP dialstring URLs, location) tuples to service URNs. As = noted, proxies can pre-populate these tables as long as the granularity for the mappings is based on countries. Even Quebec or the French-speaking part of Belgium seem to have decided to stick with the overall national emergency = number(s).

 

Shouldn't the proxy be translating the "home" = emergency number to a URN? Isn't that the number the user will = dial?

The user dials the home number (or the  “visited” number).  Some entity, possibly the = phone, translates to the universal URN

 

What about?

1) Device gets configured as you stated = above.

2) Device translates all configured emergency numbers to = URN.

3) URN is handed to the mapping service (along with location), = which then hands back a PSAP URI.

If the phone does dialplan = interpretation, that works for the home number, but not for the visited = number.

If a proxy does dialplan = interpretation, it doesn’t work; the proxy has to know what home is, and also has = to know what visited is.

 

 

 

-andy

------=_NextPart_000_0E5F_01C61B74.C5FB39D0-- --===============0928355512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0928355512==-- From ecrit-bounces@ietf.org Tue Jan 17 15:01:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyx1a-00017x-Aw; Tue, 17 Jan 2006 15:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyx1Z-00017s-HS for ecrit@megatron.ietf.org; Tue, 17 Jan 2006 15:01:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13541 for ; Tue, 17 Jan 2006 15:00:23 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyx9k-0004a7-6H for ecrit@ietf.org; Tue, 17 Jan 2006 15:10:17 -0500 Received: from [10.0.1.102] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 17 Jan 2006 15:01:08 -0500 id 0158801D.43CD4D04.00005146 In-Reply-To: <0e5b01c61b9d$da1dcf80$640fa8c0@cis.neustar.com> References: <0e5b01c61b9d$da1dcf80$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers Date: Tue, 17 Jan 2006 15:01:28 -0500 To: br@brianrosen.net X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0069943764==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0069943764== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-20809-1137528077-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-20809-1137528077-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 17, 2006, at 2:40 PM, Brian Rosen wrote: > I believe Henning and I agree that habits are hard to break, and if > you roam > a North American phone into London, dialing 9-1-1 should summon > help. We > also believe that dialing 9-9-9 should work. This means that whoever > interprets the dialplan (the phone or a proxy located wherever) > must be able > to know what your "home" emergency dialstring is as well as what > the local > one where you are now is. The "home" strings could conceivably be > provisioned, because your home carrier probably has a good idea > where your > home actually is. The local strings have to be discovered > dynamically. Brian, Thank you very much for patiently explaining this. And I agree with a lot of what you said. There are two different requirements here. The first requirement is that a "home" emergency number be translated into a universal identifier. The second requirement is that an emergency identifier for the current location of the user be translated into a universal identifier. That is not at all obvious with the current wording. -andy --=_zeke.ecotroph.net-20809-1137528077-0001-2 Content-Type: text/html; charset=iso-8859-1 X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.52.1 Content-Transfer-Encoding: quoted-printable
On Jan 17, 2006, at 2= :40 PM, Brian Rosen wrote:

=

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">I be= lieve Henning and I agree that habits are hard to break, and if you roam=

a North American p= hone into London, dialing 9-1-1 should summon help.=A0 We

also believe that dialing 9-9-9 should work.=A0 This means that whoever

interprets the dialplan (the phone = or a proxy located wherever) must be able

to know what your "home" emergency dialstring is = as well as what the local

one where you are now is.=A0= The "home" strings could conceivably be

provisioned, because your home carrier prob= ably has a good idea where your

home actually is.=A0 = The local strings have to be discovered dynamically.

<= /BLOCKQUOTE>

Brian,

Thank you very much for patiently explaining this.=A0= And I agree with a lot of what you said.

There are two different requirements here.=A0= The first requirement is that a "home" emergency number be translated i= nto a universal identifier.=A0 The second requirement is that an emergen= cy identifier for the current location of the user be translated into a = universal identifier.

That is not at all obvious with the current wording.
=
-andy
--=_zeke.ecotroph.net-20809-1137528077-0001-2-- --===============0069943764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0069943764==-- From ecrit-bounces@ietf.org Wed Jan 18 03:47:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8yW-0004cg-Qd; Wed, 18 Jan 2006 03:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8yU-0004ag-Il for ecrit@megatron.ietf.org; Wed, 18 Jan 2006 03:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18748 for ; Wed, 18 Jan 2006 03:46:00 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez96l-0008FF-Va for ecrit@ietf.org; Wed, 18 Jan 2006 03:56:01 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0I8lK3n006254Wed, 18 Jan 2006 08:47:21 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Ez8yO-0003tb-00; Wed, 18 Jan 2006 08:47:20 +0000 Date: Wed, 18 Jan 2006 08:47:20 +0000 From: "Clive D.W. Feather" To: Brian Rosen Subject: Re: [Ecrit] issue 8: Addition of New Emergency Identifiers Message-ID: <20060118084720.GI12523@finch-staff-1.thus.net> References: <7D9F13AF-F958-4E6B-AE13-F75EB94FE0C8@hxr.us> <0e5b01c61b9d$da1dcf80$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e5b01c61b9d$da1dcf80$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen said: > the 9-1-1 guys say it takes 4 keypresses to place a > 9-1-1 call on a cell phone, it really doesn't ever happen accidently, and > that's the way they like it. Hmm: I was told recently that about *half* the calls to 999/112 in the UK are accidental. In particular, if I lock my mobile handset, it will still recognise the sequence 1 1 2 and make the call; I believe that's standard behaviour. Being joggled in my pocket could make that happen. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 18 14:32:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ30-0006Bt-3J; Wed, 18 Jan 2006 14:32:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ2z-0006Bo-3t for ecrit@megatron.ietf.org; Wed, 18 Jan 2006 14:32:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16088 for ; Wed, 18 Jan 2006 14:31:19 -0500 (EST) Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJBN-0006eM-7a for ecrit@ietf.org; Wed, 18 Jan 2006 14:41:25 -0500 Received: from ([90.152.53.181]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.103856023; Wed, 18 Jan 2006 14:31:59 -0500 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Jan 2006 13:31:53 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Wed, 18 Jan 2006 13:31:53 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD0F@bre2k61p-55> Thread-Topic: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers thread-index: AcYbkxb1XDRY/hACSHSd2z2Vpv3UsQAwG9FQ From: "Stark, Barbara" To: X-OriginalArrivalTime: 18 Jan 2006 19:31:53.0929 (UTC) FILETIME=[D64D1B90:01C61C65] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My recommendation for emergency IDs would be that only recognition of the "home" emergency number(s) and the global SIP URI is required (MUST or SHALL), for UAs. For dialing plans intended to be local in the US, this would include 911. Dialing plans that are local in an EU country would include 112. I do not believe, however, that a US dialing plan must include 112 as an emergency ID, in all VoIP scenarios.=20 As I look at some of our potential hosted enterprise implementations, 3-digit extension dialing is a supported option. I do not believe that it is reasonable to restrict enterprises in the US from ever using "112" as an extension, just because it is the EU emergency number. If ecrit wants to recommend that UAs SHOULD recognize 911 and 112 or any of the others, that would probably be ok. But not MUST or SHALL. While it may be useful to provide a means (DNS, etc.) of sending a VoIP end device local emergency numbers, I, personally, would not trust the behavior of such a device in handling those numbers and would prefer that any device I was using not make use of such information. - Does the device incorporate this info into its dialing plan, or does it examine the digits, once it determines the last digit has been entered (e.g., timeout, matched dial string, "#", or user pressed "send")? - If the device does not incorporate the local emergency number(s) into its dialing plan, how do I know there isn't something in the dialing plan that would prevent the emergency number from ever being dialed? - If the device does incorporate the local emergency number(s) into its dialing plan, does it put them at the beginning or the end? - If it places them at the beginning, how do I know there isn't now a part of my regular dialing plan that I can no longer call? - If it places it at the end, how do I know there isn't a part of my regular dialing plan that will keep the emergency number from being dialed? I have a colleague with a son who lives in Australia. The son maintains a VoIP account from a US VoIP provider. The son does this so that he can call US destinations (such as his father) for just the monthly cost of the account. He does NOT expect or want to use an Australian dial plan from this phone, and he knows that today he cannot use it to call for emergency services. One aspect of many US dial plans is that "00" is used to indicate the caller wants to be routed to an international operator. No other digits are expected after "00", so the VoIP device can be set to immediately recognize the string after the 2nd "0", and send the SIP Invite. The emergency number there in Australia is "000". Under the existing dialing plan defined in the ATA, "000" can never be dialed. If this ATA claimed to support being sent (e.g., DNS) local emergency numbers, I would not be able to predict its behavior when trying to dial "000", unless there were some very detailed rules written. --------------------------------------------------- On a slightly different note relating to emergency IDs, I think the overall solution needs to accept that location-aware VoIP end devices may be improperly configured (possibly by the end user playing around with things), and may not recognize emergency numbers, and therefore would not attach the location. In this case, the proxy would recognize the emegency number. My reading of current expectations is that the VoIP service would then use sort of a "best guess" of the user's location (e.g., a saved emergency address on file). It might be useful to recommend that a server which recognizes an emergency call should send the VoIP end device a request for location (OPTIONS request?), just in case the device does know the location, but didn't know it was an emergency call. Barbara Barbara Stark BellSouth Science & Technology ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 18 16:59:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLKr-0001LF-G9; Wed, 18 Jan 2006 16:59:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLKp-0001Kq-T6 for ecrit@megatron.ietf.org; Wed, 18 Jan 2006 16:59:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13555 for ; Wed, 18 Jan 2006 16:57:52 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLTE-0000lN-2K for ecrit@ietf.org; Wed, 18 Jan 2006 17:08:01 -0500 Received: from lion.cs.columbia.edu (IDENT:s/DS7vywzk+TZ+YoP0+3OByJP1vqVRch@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0ILxDKG029835 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 18 Jan 2006 16:59:14 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0ILxDnE006571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Jan 2006 16:59:13 -0500 Message-ID: <43CEB9A5.6050704@cs.columbia.edu> Date: Wed, 18 Jan 2006 16:56:53 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <9888E1AA13C3A1459D122996A58C0E1131BD0F@bre2k61p-55> In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD0F@bre2k61p-55> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > (e.g., a saved emergency address on file). It might be useful to > recommend that a server which recognizes an emergency call should send > the VoIP end device a request for location (OPTIONS request?), just in > case the device does know the location, but didn't know it was an > emergency call. Unfortunately, this clearly has privacy implications. How do you prevent any party I might be calling from sending a "send me your location" request? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 19 09:50:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezb7h-0006My-Db; Thu, 19 Jan 2006 09:50:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezb7f-0006KK-DE for ecrit@megatron.ietf.org; Thu, 19 Jan 2006 09:50:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28256 for ; Thu, 19 Jan 2006 09:49:20 -0500 (EST) Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbGD-0001kM-D8 for ecrit@ietf.org; Thu, 19 Jan 2006 09:59:37 -0500 Received: from ([90.152.52.44]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.104079291; Thu, 19 Jan 2006 09:50:04 -0500 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Jan 2006 08:50:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Thu, 19 Jan 2006 08:50:05 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD11@bre2k61p-55> Thread-Topic: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Thread-Index: AcYcepP59Zt1eGSXRnuzQPfz3nt9TgAi523i From: "Stark, Barbara" To: "Henning Schulzrinne" X-OriginalArrivalTime: 19 Jan 2006 14:50:05.0555 (UTC) FILETIME=[A289BC30:01C61D07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0087196731==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0087196731== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D07.A23F8A0C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D07.A23F8A0C Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Assuming that the OPTIONS mechanism (described in Section 8.2.2 of = draft-ietf-sip-location-conveyance-01.txt) exists, there's really = nothing you can do to prevent any party you call from sending this = request. The question is, what does your SIP endpoint do with the = request when it gets it? If your SIP endpoint is configured to always = return a 488 reply, then your privacy remains uncompromised, and (going = back to the example of what a server that recognizes an emergency call = might do) your emergency call gets routed according to your emergency = location of record. On the other hand, some people may not really care = if their location is known when they call somebody, and may have their = SIP endpoint respond to such a query with an OK and the location info. = Since this is all under the control of the person who manages the SIP = endpoint, I'm not sure I see the privacy issue. Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wed 1/18/2006 4:56 PM To: Stark, Barbara Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency = Identifiers > (e.g., a saved emergency address on file). It might be useful to > recommend that a server which recognizes an emergency call should send > the VoIP end device a request for location (OPTIONS request?), just in > case the device does know the location, but didn't know it was an > emergency call. Unfortunately, this clearly has privacy implications. How do you prevent = any party I might be calling from sending a "send me your location"=20 request? ------_=_NextPart_001_01C61D07.A23F8A0C Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] Issue 30: Requirements regarding Emergency = Identifiers

Assuming that the OPTIONS mechanism (described in = Section 8.2.2 of draft-ietf-sip-location-conveyance-01.txt) exists, = there's really nothing you can do to prevent any party you call from = sending this request. The question is, what does your SIP endpoint do = with the request when it gets it? If your SIP endpoint is configured to = always return a 488 reply, then your privacy remains uncompromised, and = (going back to the example of what a server that recognizes an emergency = call might do) your emergency call gets routed according to your = emergency location of record. On the other hand, some people may not = really care if their location is known when they call somebody, and may = have their SIP endpoint respond to such a query with an OK and the = location info. Since this is all under the control of the person who = manages the SIP endpoint, I'm not sure I see the privacy issue.
Barbara


-----Original Message-----
From:   Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent:   Wed 1/18/2006 4:56 PM
To:     Stark, Barbara
Cc:     ecrit@ietf.org
Subject:        Re: [Ecrit] Issue 30: = Requirements regarding Emergency Identifiers
> (e.g., a saved emergency address on file). It might be useful = to
> recommend that a server which recognizes an emergency call should = send
> the VoIP end device a request for location (OPTIONS request?), just = in
> case the device does know the location, but didn't know it was = an
> emergency call.

Unfortunately, this clearly has privacy implications. How do you = prevent
  any party I might be calling from sending a "send me your = location"
request?

------_=_NextPart_001_01C61D07.A23F8A0C-- --===============0087196731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0087196731==-- From ecrit-bounces@ietf.org Thu Jan 19 10:00:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbHS-00034l-Nq; Thu, 19 Jan 2006 10:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbHR-00034b-Ob for ecrit@megatron.ietf.org; Thu, 19 Jan 2006 10:00:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29124 for ; Thu, 19 Jan 2006 09:59:26 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbPz-0002CH-7r for ecrit@ietf.org; Thu, 19 Jan 2006 10:09:44 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0JF0lEF000499 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 19 Jan 2006 10:00:48 -0500 (EST) In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD11@bre2k61p-55> References: <9888E1AA13C3A1459D122996A58C0E1131BD11@bre2k61p-55> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F3DB36E-27A2-40D7-8F6C-F5D80E3E09B9@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Thu, 19 Jan 2006 10:00:46 -0500 To: "Stark, Barbara" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is default configuration. I presume we'd want systems to be configured by default to be secure and privacy-safe, i.e., refuse the request without explicit user (GUI) approval. GUI approval isn't nearly as helpful for emergency calls. Thus, in practice, either all systems would be privacy-unsafe out of the box or this mechanism would fail in an emergency. I don't think forcing users to give up location privacy for all calls (or manually twiddling configuration options before each call) just so that emergency calls work is an acceptable design. I think labeling emergency calls is a much better option and follows the general SIP design principle of declaring, rather than inferring, intent. I believe the dial-plan issues are solvable for the vast majority of cases, although I agree that we need to specify behavior sufficiently well to achieve desirable outcomes. Your mechanism fails to protect the user's privacy; the labeling mechanism fails under rather obscure circumstances for calls that few people care about. (I can't remember ever having called the international operator...) On Jan 19, 2006, at 9:50 AM, Stark, Barbara wrote: > Assuming that the OPTIONS mechanism (described in Section 8.2.2 of > draft-ietf-sip-location-conveyance-01.txt) exists, there's really > nothing you can do to prevent any party you call from sending this > request. The question is, what does your SIP endpoint do with the > request when it gets it? If your SIP endpoint is configured to > always return a 488 reply, then your privacy remains uncompromised, > and (going back to the example of what a server that recognizes an > emergency call might do) your emergency call gets routed according > to your emergency location of record. On the other hand, some > people may not really care if their location is known when they > call somebody, and may have their SIP endpoint respond to such a > query with an OK and the location info. Since this is all under the > control of the person who manages the SIP endpoint, I'm not sure I > see the privacy issue. > Barbara > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 19 16:04:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezgxh-0005cW-NY; Thu, 19 Jan 2006 16:04:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezgxg-0005cP-Bv for ecrit@megatron.ietf.org; Thu, 19 Jan 2006 16:04:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27082 for ; Thu, 19 Jan 2006 16:03:25 -0500 (EST) Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezh6G-0005Yw-LG for ecrit@ietf.org; Thu, 19 Jan 2006 16:13:46 -0500 Received: from ([90.152.52.46]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.104208121; Thu, 19 Jan 2006 16:03:22 -0500 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Jan 2006 15:03:22 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Date: Thu, 19 Jan 2006 15:03:21 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD13@bre2k61p-55> Thread-Topic: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers Thread-Index: AcYdCko8WgtUcWb2QnOQGa+gFqMv0gAJSV6C From: "Stark, Barbara" To: "Henning Schulzrinne" X-OriginalArrivalTime: 19 Jan 2006 21:03:22.0016 (UTC) FILETIME=[C7DE7A00:01C61D3B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1715282230==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1715282230== Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D3B.C79E0BDC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D3B.C79E0BDC Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I see that my suggestion (of VSPs sending an OPTION message when they = detect an emergency call digit string, but which the SIP endpoint did = not detect as an emergency call) isn't popular, so I retract it as a = suggestion. Please forget I ever mentioned it. Since the option to do = this exists, and nothing in the architecture precludes it, it's really = irrelevant as to whether or not ecrit chooses to acknowledge existence = of this scenario. However, on my comment about home and local numbering plans, I think = I'll stand my ground, and state more concisely what I'd like to see. 1. ecrit should not be attempting to require recognition of any specific = dialing string. The ecrit architecture depends on UAs being able to = recognize emergency digit strings and translate them into an emergency = SIP URI. It also depends on these strings being configurable (so device = dialing plans are not tied to the area where they were bought). And = that's as far as it needs to go. Nothing in the ecrit architecture = depends on the recognition of a particular string of digits. Given that = the architecture is completely independent of specific string values, = the only entities that have the authority to tell me what emergency = strings I MUST recognize, are the various governmental bodies that have = jurisdiction over the services I offer. ecrit is not such an entity and = does not need to try to take on the role of the FCC.=20 2. If a mechanism exists to send local emergency numbers to a device, = devices must be configurable as to whether or not they make use of this = mechanism. I believe that the results of using this mechanism could be undesirable, = could cause confusion of my customers, and could either not work = properly or interfere with my customers' local dialing plan. Again, all = I'm asking is that use of this mechanism (if it exists) be configurable, = so I can turn it off or default it off in devices I provide to my = customers. By the way, while you may not have dialed 00, many people do make use of = it. It is a valid convention in US dialing plans, and it lands you at a = real, live international operator. Personally, I've never dialed 911, = but I'm not willing to give it up as part of my dialing plan. Again, = ecrit has no authority to interfere with or specify digit dialing plans. Barbara=20 Barbara Stark BellSouth Science & Technology -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thu 1/19/2006 10:00 AM To: Stark, Barbara Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency = Identifiers The problem is default configuration. I presume we'd want systems to =20 be configured by default to be secure and privacy-safe, i.e., refuse =20 the request without explicit user (GUI) approval. GUI approval isn't =20 nearly as helpful for emergency calls. Thus, in practice, either all =20 systems would be privacy-unsafe out of the box or this mechanism =20 would fail in an emergency. I don't think forcing users to give up =20 location privacy for all calls (or manually twiddling configuration =20 options before each call) just so that emergency calls work is an =20 acceptable design. I think labeling emergency calls is a much better option and follows =20 the general SIP design principle of declaring, rather than inferring, =20 intent. I believe the dial-plan issues are solvable for the vast majority of =20 cases, although I agree that we need to specify behavior sufficiently =20 well to achieve desirable outcomes. Your mechanism fails to protect =20 the user's privacy; the labeling mechanism fails under rather obscure =20 circumstances for calls that few people care about. (I can't remember =20 ever having called the international operator...) On Jan 19, 2006, at 9:50 AM, Stark, Barbara wrote: > Assuming that the OPTIONS mechanism (described in Section 8.2.2 of =20 > draft-ietf-sip-location-conveyance-01.txt) exists, there's really =20 > nothing you can do to prevent any party you call from sending this =20 > request. The question is, what does your SIP endpoint do with the =20 > request when it gets it? If your SIP endpoint is configured to =20 > always return a 488 reply, then your privacy remains uncompromised, =20 > and (going back to the example of what a server that recognizes an =20 > emergency call might do) your emergency call gets routed according =20 > to your emergency location of record. On the other hand, some =20 > people may not really care if their location is known when they =20 > call somebody, and may have their SIP endpoint respond to such a =20 > query with an OK and the location info. Since this is all under the =20 > control of the person who manages the SIP endpoint, I'm not sure I =20 > see the privacy issue. > Barbara > ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 118 ------_=_NextPart_001_01C61D3B.C79E0BDC Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] Issue 30: Requirements regarding Emergency = Identifiers

I see that my suggestion (of VSPs sending an OPTION = message when they detect an emergency call digit string, but which the = SIP endpoint did not detect as an emergency call) isn't popular, so I = retract it as a suggestion. Please forget I ever mentioned it. Since the = option to do this exists, and nothing in the architecture precludes it, = it's really irrelevant as to whether or not ecrit chooses to acknowledge = existence of this scenario.

However, on my comment about home and local numbering plans, I think = I'll stand my ground, and state more concisely what I'd like to see.

1. ecrit should not be attempting to require recognition of any specific = dialing string. The ecrit architecture depends on UAs being able to = recognize emergency digit strings and translate them into an emergency = SIP URI. It also depends on these strings being configurable (so device = dialing plans are not tied to the area where they were bought). And = that's as far as it needs to go. Nothing in the ecrit architecture = depends on the recognition of a particular string of digits. Given that = the architecture is completely independent of specific string values, = the only entities that have the authority to tell me what emergency = strings I MUST recognize, are the various governmental bodies that have = jurisdiction over the services I offer. ecrit is not such an entity and = does not need to try to take on the role of the FCC.

2. If a mechanism exists to send local emergency numbers to a device, = devices  must be configurable as to whether or not they make use of = this mechanism.

I believe that the results of using this mechanism could be undesirable, = could cause confusion of my customers, and could either not work = properly or interfere with my customers' local dialing plan. Again, all = I'm asking is that use of this mechanism (if it exists) be configurable, = so I can turn it off or default it off in devices I provide to my = customers.

By the way, while you may not have dialed 00, many people do make use of = it. It is a valid convention in US dialing plans, and it lands you at a = real, live international operator. Personally, I've never dialed 911, = but I'm not willing to give it up as part of my dialing plan. Again, = ecrit has no authority to interfere with or specify digit dialing = plans.
Barbara

Barbara Stark
BellSouth Science & Technology


-----Original Message-----
From:   Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent:   Thu 1/19/2006 10:00 AM
To:     Stark, Barbara
Cc:     ecrit@ietf.org
Subject:        Re: [Ecrit] Issue 30: = Requirements regarding Emergency Identifiers
The problem is default configuration. I presume we'd want systems = to 
be configured by default to be secure and privacy-safe, i.e., = refuse 
the request without explicit user (GUI) approval. GUI approval = isn't 
nearly as helpful for emergency calls. Thus, in practice, either = all 
systems would be privacy-unsafe out of the box or this = mechanism 
would fail in an emergency. I don't think forcing users to give = up 
location privacy for all calls (or manually twiddling = configuration 
options before each call) just so that emergency calls work is = an 
acceptable design.

I think labeling emergency calls is a much better option and = follows 
the general SIP design principle of declaring, rather than = inferring, 
intent.

I believe the dial-plan issues are solvable for the vast majority = of 
cases, although I agree that we need to specify behavior = sufficiently 
well to achieve desirable outcomes. Your mechanism fails to = protect 
the user's privacy; the labeling mechanism fails under rather = obscure 
circumstances for calls that few people care about. (I can't = remember 
ever having called the international operator...)

On Jan 19, 2006, at 9:50 AM, Stark, Barbara wrote:

> Assuming that the OPTIONS mechanism (described in Section 8.2.2 = of 
> draft-ietf-sip-location-conveyance-01.txt) exists, there's = really 
> nothing you can do to prevent any party you call from sending = this 
> request. The question is, what does your SIP endpoint do with = the 
> request when it gets it? If your SIP endpoint is configured = to 
> always return a 488 reply, then your privacy remains = uncompromised, 
> and (going back to the example of what a server that recognizes = an 
> emergency call might do) your emergency call gets routed = according 
> to your emergency location of record. On the other hand, = some 
> people may not really care if their location is known when = they 
> call somebody, and may have their SIP endpoint respond to such = a 
> query with an OK and the location info. Since this is all under = the 
> control of the person who manages the SIP endpoint, I'm not sure = I 
> see the privacy issue.
> Barbara
>

*****

"The = information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers." 118

 ------_=_NextPart_001_01C61D3B.C79E0BDC-- --===============1715282230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1715282230==-- From ecrit-bounces@ietf.org Thu Jan 19 16:44:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezha3-0002U0-HJ; Thu, 19 Jan 2006 16:44:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezha1-0002Tj-UK for ecrit@megatron.ietf.org; Thu, 19 Jan 2006 16:44:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29386 for ; Thu, 19 Jan 2006 16:43:00 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezhia-0006cg-KT for ecrit@ietf.org; Thu, 19 Jan 2006 16:53:22 -0500 Received: from lion.cs.columbia.edu (IDENT:xUPXgz8HDzGx58GuJFroGp4BAmoJ5tHa@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0JLiHKG008741 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 19 Jan 2006 16:44:22 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0JLiHnE031386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Jan 2006 16:44:17 -0500 Message-ID: <43D007A5.6030002@cs.columbia.edu> Date: Thu, 19 Jan 2006 16:41:57 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers References: <9888E1AA13C3A1459D122996A58C0E1131BD13@bre2k61p-55> In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD13@bre2k61p-55> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > 1. ecrit should not be attempting to require recognition of any specific > dialing string. The ecrit architecture depends on UAs being able to No IETF working group can require the implementation of anything (or the correct implementation of anything...). At best, we can provide mechanisms that people find useful. > 2. If a mechanism exists to send local emergency numbers to a device, > devices must be configurable as to whether or not they make use of this > mechanism. > > I believe that the results of using this mechanism could be undesirable, > could cause confusion of my customers, and could either not work > properly or interfere with my customers' local dialing plan. Again, all > I'm asking is that use of this mechanism (if it exists) be configurable, > so I can turn it off or default it off in devices I provide to my customers. That seems, to me, an implementation issue. For example, DHCP, as a classical configuration protocol, is configurable in most cases, in that one can choose to use it or hard-code the IP address. > > By the way, while you may not have dialed 00, many people do make use of > it. It is a valid convention in US dialing plans, and it lands you at a > real, live international operator. Personally, I've never dialed 911, > but I'm not willing to give it up as part of my dialing plan. Again, > ecrit has no authority to interfere with or specify digit dialing plans. We auto-configure dial plans all the time today. This is just another configuration option. Since we're talking about requirements here, maybe we should get back to those: - Emergency calls should be recognizable as such by the user agent. - Both "home" and "visited" emergency numbers should be available automatically (for customers that want this feature). Can we agree on those? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 20 08:14:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezw6S-0005Ki-NM; Fri, 20 Jan 2006 08:14:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezw6R-0005Kd-1g for ecrit@megatron.ietf.org; Fri, 20 Jan 2006 08:14:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11700 for ; Fri, 20 Jan 2006 08:13:28 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzwF8-0003sr-1Y for ecrit@ietf.org; Fri, 20 Jan 2006 08:23:57 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0KDEWP4009800 for ; Fri, 20 Jan 2006 13:14:32 GMT (envelope-from raymond.forbes@marconi.com) To: ecrit@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Fri, 20 Jan 2006 13:17:19 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 20/01/2006 13:14:33, Serialize complete at 20/01/2006 13:14:33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Subject: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1226222911==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1226222911== Content-Type: multipart/alternative; boundary="=_alternative 00488533802570FC_=" This is a multipart message in MIME format. --=_alternative 00488533802570FC_= Content-Type: text/plain; charset="US-ASCII" Ecrit delegates, I read your I-Ds with interest. Thank you. I was slightly concerned that they seam to be very terminal centric in terms of Location provision. The Discussions in ETSI and the ECC have focused on Validated Location, Validated by the network or Provided within the network by a secure database. What the Validation means to the EU is that the Location on authenticated before it reaches the Emergency Services usually by the CSP (communication Service Provider). Not that it is a valid address or location which is the ecrit definition of validation; both concepts have validity. ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This is an option allowed in Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt Real Geographic mapping in the TS 102 164 is calculated within the PSAP by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does not need to be mentioned. It is almost the same as the case (8), acquisition of Location Information by a Call Routing Entity in Title: Security Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8 Requirements for Interface . Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means that User's location cannot be held on a Publically accessible directory database. Secondly, I have one question about the Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve a limited geographic region, ..." In Summary "PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority. (This terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This definition from Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt is not correct the US people read ETSI documents though US Glasses. The PSAP in ETSI SR 002 180 is not the same as the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as Marc Lisner and NENA are very aware. I'm not sure that this definition error affects the Internet draft very much. All I think these Internet drafts need to concern is the routing to a PASP function Outside the Telephone or IP network. In ETSI the definition of PSAPs is split in into two functions, to cover different national situations, PSAP1 (or the PSAP) which is the first stage access point to the Emergency services This is not mentioned in the I-D. Secondly the PSAP2 (or ECC Emergency Control Centre) these are geographically located. This is the US PSAP and the PSAP mentioned in your document. In the UK this is EOAC, in New Zealand ECC. In Germany these Functions are physically collocated. In Sweden and the UK there are a small number of PSAP1 or (PSAP functions). For Example C&W and T-Mobil route all UK Emergency calls to One PSAP. The Other UK Operators Route all UK Emergency calls to a small number of PSAPs (managed by BT). These may be geographically distributed in times of normal operation, however they may be load distributed in times of severe load or PSAP failure. All Emergency Calls in Sweden are routed to a Small number of PSAPS run by a National Authorised Company called "SOS-Alarm" These are not PSAPs in your document if I read your documents correctly. These PSAPs route the Emergency onto the most appropriate Control or Assistance Centre, Fire, Police, Ambulance, Coastguard, Cave/Mountain/Forest rescue, etc... One Control or assistance Centre may dispatch several Emergency responders to an incident. I think the one word addition of "may" will address this sufficiently. I have discussed this last point with Hannes see below: [hannes] if we can deal with this issue by changing the sentence from "PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority." to ""PSAP (Public Safety Answering Point): Physical location where emergency calls may be received under the responsibility of a public authority." [rcf] agreed. Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Tschofenig, Hannes" Sent by: "emtel : Emtel" 09/01/2006 22:47 Please respond to "Tschofenig, Hannes" To: EMTEL@LIST.ETSI.ORG cc: Subject: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt hi all, a new version of our requirements document is available. please send review comments to the mailing list (see http://www.ietf.org/html.charters/ecrit-charter.html). ------------------------- Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-02.txt Pages : 27 Date : 2006-1-3 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt ------------------------- ciao hannes ------------------------------------------------------------------- Mail archive for EMTEL can be browsed at the following url: http://list.etsi.org/EMTEL.html ------------------------------------------------------------------- --=_alternative 00488533802570FC_= Content-Type: text/html; charset="US-ASCII"
Ecrit delegates,

I read your I-Ds with interest. Thank you.

I was slightly concerned that they seam to be very terminal centric in terms of Location provision.

The Discussions in ETSI and the ECC have focused on Validated Location, Validated by the network or Provided within the network by a secure database. What the Validation means to the EU is that the Location on authenticated before it reaches the Emergency Services usually by the CSP (communication Service Provider). Not that it is a valid address or location which is the ecrit definition of validation; both concepts have validity.

ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This is an option allowed in Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall
Filename: draft-ietf-ecrit-requirements-02.txt
Real Geographic mapping in the TS 102 164 is calculated within the PSAP by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does not need to be mentioned. It is almost the same as the case (8), acquisition of Location Information by a Call Routing Entity in Title: Security Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8 Requirements for Interface .

Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means that User's location cannot be held on a Publically accessible directory database.

Secondly, I have one question about the Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve a limited geographic region, ..."

In Summary

"PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority.  (This terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This definition from Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt is not correct the US people read ETSI documents though US Glasses. The PSAP in ETSI SR 002 180 is not the same as the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as Marc Lisner and NENA are very aware. I'm not sure that this definition error affects the Internet draft very much. All I think these Internet drafts need to concern is the routing to a PASP function Outside the Telephone or IP network.

In ETSI the definition of PSAPs is split in into two functions, to cover different national situations, PSAP1 (or the PSAP) which is the first stage access point to the Emergency services This is not mentioned in the I-D. Secondly the PSAP2 (or ECC Emergency Control Centre) these are geographically located. This is the US PSAP and the PSAP mentioned in your document. In the UK this is EOAC, in New Zealand ECC. In Germany these Functions are physically collocated.

In Sweden and the UK there are a small number of PSAP1 or (PSAP functions). For Example C&W and T-Mobil route all UK Emergency calls to One PSAP. The Other UK Operators Route all UK Emergency calls to a small number of PSAPs (managed by BT). These may be geographically distributed in times of normal operation, however they may be load distributed in times of severe load or PSAP failure. All Emergency Calls in Sweden are routed to a Small number of PSAPS run by a National Authorised Company called "SOS-Alarm" These are not PSAPs in your document if I read your documents correctly. These PSAPs route the Emergency onto the most appropriate Control or Assistance Centre, Fire, Police, Ambulance, Coastguard, Cave/Mountain/Forest rescue, etc... One Control or assistance Centre may dispatch several Emergency responders to an incident.

I think the one word addition of "may" will address this sufficiently.

I have discussed this last point with Hannes see below:

[hannes] if we can deal with this issue by changing the sentence from

"PSAP (Public Safety Answering Point): Physical location where emergency
calls are received under the responsibility of a public authority."

to

""PSAP (Public Safety Answering Point): Physical location where
emergency calls may be received under the responsibility of a public
authority."

[rcf] agreed.


Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


"Tschofenig, Hannes" <hannes.tschofenig@SIEMENS.COM>
Sent by: "emtel : Emtel" <EMTEL@LIST.ETSI.ORG>

09/01/2006 22:47
Please respond to "Tschofenig, Hannes"

       
        To:        EMTEL@LIST.ETSI.ORG
        cc:        
        Subject:        [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt



hi all,
a new version of our requirements document is available. please send
review comments to the mailing list (see
http://www.ietf.org/html.charters/ecrit-charter.html).
-------------------------
Title                : Requirements for Emergency Context Resolution
with Internet Technologies
Author(s)        : H. Schulzrinne, R. Marshall
Filename        : draft-ietf-ecrit-requirements-02.txt
Pages                : 27
Date                : 2006-1-3

This document enumerates requirements for emergency calls placed by
the public using voice-over-IP (VoIP) and general Internet multimedia
systems, where Internet protocols are used end-to-end.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt

-------------------------

ciao
hannes
-------------------------------------------------------------------
Mail archive for EMTEL can be browsed at the following url:
http://list.etsi.org/EMTEL.html
-------------------------------------------------------------------

--=_alternative 00488533802570FC_=-- --===============1226222911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1226222911==-- From ecrit-bounces@ietf.org Fri Jan 20 11:39:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzI5-0003L8-SI; Fri, 20 Jan 2006 11:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzI2-0003Kw-TB for ecrit@megatron.ietf.org; Fri, 20 Jan 2006 11:39:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28140 for ; Fri, 20 Jan 2006 11:37:38 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzQo-0002Kq-F3 for ecrit@ietf.org; Fri, 20 Jan 2006 11:48:11 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EzzHr-0008LL-4g; Fri, 20 Jan 2006 10:38:55 -0600 From: "Brian Rosen" To: "'Raymond Forbes'" , Subject: RE: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt Date: Fri, 20 Jan 2006 11:36:28 -0500 Message-ID: <005801c61ddf$ab28fb20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYdxCW02OOv7DTJT9y9BDRGK1RJvQAGQeaw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ray We focus on being terminal centric because in many cases the access = network provider, which is the only carrier that knows where the terminal is, is = not the CSP. The CSP may be in a different country and not subject to laws where the terminal is, even though it is providing telephony services to = it. The legal status is not the important part; it is the fact that the CSP doesn=92t know where the terminal is. The terminal however, is being = provided packet service by the access network, and is the point where the = subscriber to the access network meets the subscriber to the CSP. That is why we = focus on the terminal =96 because the access network can supply location to = the terminal, and the terminal can supply location to the CSP. Attempting = to pass information between the access network and the CSP is fraught with difficulty, the most severe of which is identifiers =3D how the access = network could identify the CSP subscriber. We have some terminology issues, because we are using the term = =93Valid=94 to mean that the location is one recognized by the public safety agencies = as a location they know how to send responders. Validated thus means we have taken steps to assure that the location is a valid one. Protecting the information from forgery or modification is a different issue which is = also important to us. I have no problem removing the Note in the security threats document. However, I do have a problem with removing the word =93limited=94 in the geographic coverage of a PSAP. Even if one PSAP serves the entire = country, its service boundary is limited to that country. So I think the = requirement is properly stated. I would not oppose adding some clarification = (=93although that region may be as large as an entire country=94), but I don=92t = really think it is needed. Although I don=92t have a big problem with the change to the PSAP = definition, I do wonder if we would be better off changing the definition to say = that the PSAP is where the call is first answered. Brian ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Raymond Forbes Sent: Friday, January 20, 2006 8:17 AM To: ecrit@ietf.org Subject: [Ecrit] Fw: [EMTEL] I-D = ACTION:draft-ietf-ecrit-requirements-02.txt Ecrit delegates,=20 I read your I-Ds with interest. Thank you.=20 I was slightly concerned that they seam to be very terminal centric in = terms of Location provision.=20 The Discussions in ETSI and the ECC have focused on Validated Location, Validated by the network or Provided within the network by a secure database. What the Validation means to the EU is that the Location on authenticated before it reaches the Emergency Services usually by the = CSP (communication Service Provider). Not that it is a valid address or = location which is the ecrit definition of validation; both concepts have = validity.=20 ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by = the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This = is an option allowed in Title: Requirements for Emergency Context = Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall=20 Filename: draft-ietf-ecrit-requirements-02.txt Real Geographic mapping in the TS 102 164 is calculated within the PSAP = by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does = not need to be mentioned. It is almost the same as the case (8), acquisition = of Location Information by a Call Routing Entity in Title: Security Threats = and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter = 6.8 Requirements for Interface .=20 Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note = is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the = user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of = the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one = of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means = that User's location cannot be held on a Publically accessible directory database.=20 Secondly, I have one question about the Requirements for Emergency = Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. = Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 = Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the = US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve = a limited geographic region, ..."=20 In Summary=20 "PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority. = =A0(This terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This definition from Title: Requirements for Emergency Context Resolution = with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt is not correct the US people read = ETSI documents though US Glasses. The PSAP in ETSI SR 002 180 is not the same = as the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as Marc = Lisner and NENA are very aware. I'm not sure that this definition error affects = the Internet draft very much. All I think these Internet drafts need to = concern is the routing to a PASP function Outside the Telephone or IP network.=20 In ETSI the definition of PSAPs is split in into two functions, to cover different national situations, PSAP1 (or the PSAP) which is the first = stage access point to the Emergency services This is not mentioned in the I-D. Secondly the PSAP2 (or ECC Emergency Control Centre) these are geographically located. This is the US PSAP and the PSAP mentioned in = your document. In the UK this is EOAC, in New Zealand ECC. In Germany these Functions are physically collocated.=20 In Sweden and the UK there are a small number of PSAP1 or (PSAP = functions). For Example C&W and T-Mobil route all UK Emergency calls to One PSAP. = The Other UK Operators Route all UK Emergency calls to a small number of = PSAPs (managed by BT). These may be geographically distributed in times of = normal operation, however they may be load distributed in times of severe load = or PSAP failure. All Emergency Calls in Sweden are routed to a Small number = of PSAPS run by a National Authorised Company called "SOS-Alarm" These are = not PSAPs in your document if I read your documents correctly. These PSAPs = route the Emergency onto the most appropriate Control or Assistance Centre, = Fire, Police, Ambulance, Coastguard, Cave/Mountain/Forest rescue, etc... One Control or assistance Centre may dispatch several Emergency responders = to an incident.=20 I think the one word addition of "may" will address this sufficiently.=20 I have discussed this last point with Hannes see below:=20 [hannes] if we can deal with this issue by changing the sentence from "PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority." to ""PSAP (Public Safety Answering Point): Physical location where emergency calls may be received under the responsibility of a public authority." [rcf] agreed.=20 Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. =A0If you are not the intended recipient, please notify us immediately by reply e-mail and = then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents = to any other person: to do so could be a breach of confidence. "Tschofenig, Hannes" =20 Sent by: "emtel : Emtel" =20 09/01/2006 22:47=20 Please respond to "Tschofenig, Hannes"=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0EMTEL@LIST.ETSI.ORG=20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0[EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt hi all, a new version of our requirements document is available. please send review comments to the mailing list (see http://www.ietf.org/html.charters/ecrit-charter.html). ------------------------- Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Requirements for Emergency = Context Resolution with Internet Technologies=20 Author(s) =A0 =A0 =A0 =A0: H. Schulzrinne, R. Marshall Filename =A0 =A0 =A0 =A0: draft-ietf-ecrit-requirements-02.txt Pages =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 27 Date =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2006-1-3=20 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt ------------------------- ciao hannes ------------------------------------------------------------------- Mail archive for EMTEL can be browsed at the following url:=20 http://list.etsi.org/EMTEL.html -------------------------------------------------------------------=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 22 08:26:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0fEb-0002n4-4H; Sun, 22 Jan 2006 08:26:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0fEZ-0002ms-0c for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 08:26:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19389 for ; Sun, 22 Jan 2006 08:24:48 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0fNf-0007zG-My for ecrit@ietf.org; Sun, 22 Jan 2006 08:35:46 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0MDQ6nm024800 for ; Sun, 22 Jan 2006 14:26:06 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k0MDQ6vI026732 for ; Sun, 22 Jan 2006 14:26:06 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jan 2006 14:26:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jan 2006 14:21:25 +0100 Message-ID: Thread-Topic: Issue 30: Summary Thread-Index: AcYfVr6LXvU4VR2+TMuZtYT0eP7Q3w== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 22 Jan 2006 13:26:06.0003 (UTC) FILETIME=[65F86030:01C61F57] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Issue 30: Summary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 i am trying to summarize the discussion related to issue 30/issue 8. =20 - there are location-dependent and global emergency identifiers.=20 global emergency identifiers are, for example the sos uris introduced in sipping-sos draft. location-dependent emergency identifiers are those that are used today in specific countries (see, for example, http://www.sccfd.org/travel.html) - location-dependent numbers might be further categorized into 'home' emergency numbers (the definition of 'home' relates to a specific user) and numbers used in a 'local' region (here 'local emergency numbers'). "local" here means the valid emergency telephone number used in the geographic vicinity the user finds himself in. - the sip ua should translate home emergency numbers to a global emergency identifier. the ua is most likely pre-provisioned with this information to be able to make such a translation. - there are cases where the sip ua does not recognize the home emergency number. in this case the home emergency number is not translated to a global emergency identifier. a sip proxy (in the visited or the home network) needs to understand that this is an emergency call.=20 - the sip ua should translate local emergency numbers to a global emergency identifier. - there are scenarios where a user dials a local emergency number that is different from the home emergency number. the sip user agent might have no other mechanism to determine whether this is an emergency call or not.=20 henning motivated the usage of local emergency numbers with the following two examples: * if somebody visits a foreign country and sees a firetruck=20 with 999 on the side, he or she expects to be able to dial that number=20 and summon that fire truck (or its cousin); * There's the "tourist collapses, good samaritan finds tourist cell=20 phone and dials local emergency number" case. there are four approaches to the problem: 1) the sip ua is dynamically configured with local emergency numbers (whenever the user and the sip user agent travel to a new region) and therefore the case is not likely to happen unless you have the following case: * Tourist Alice collapses, another tourist Bob finds the cell=20 phone of Alice and dials its own home emergency number (because it does not know the local emergency number) and the home emergency number is different from the local emergency number and Alice/Bob have different home emergency numbers. 2) the sip proxy is located in the access network and understands the local emergency number.=20 3) the sip ua is configured to understand all emergency numbers in the entire world. the sip ua would map these translate all these configured numbers to global emergency user identifiers.=20 the problem is only that local emergency numbers in one region are not emergency numbers in another region.=20 4) the sip ua is not configured to understand all emergency numbers but the sip proxy is. if we focus on the case where the sip proxy is not local (otherwise we would again talk about (2)) then there are most likely the same problems as in (3).=20 =20 it seems that some of you want to work on a solution for (1) (or have already worked on it).=20 ciao hannes ps: the user interface is important to us and we need to be aware of these aspects (as we need to be aware of many other aspects as well). i guess that most of you understood what i meant by "out-of-scope".=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 22 11:13:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0hqa-0007Qb-3S; Sun, 22 Jan 2006 11:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0hqY-0007QN-Ay for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 11:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28891 for ; Sun, 22 Jan 2006 11:12:13 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0hzi-00040U-5A for ecrit@ietf.org; Sun, 22 Jan 2006 11:23:11 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0MGDW9g021448 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 22 Jan 2006 11:13:33 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Summary Date: Sun, 22 Jan 2006 11:13:30 -0500 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jan 22, 2006, at 8:21 AM, Tschofenig, Hannes wrote: > hi all, > > i am trying to summarize the discussion related to issue 30/issue 8. > > - there are location-dependent and global emergency identifiers. > global emergency identifiers are, for example the sos uris > introduced in > sipping-sos > draft. location-dependent emergency identifiers are those that are > used > today in specific countries (see, for example, > http://www.sccfd.org/travel.html) This is probably more nit-picking than substance, but I would avoid using the term "identifier" for dial strings such as "9 1 1". Calling them 'emergency dial strings' is a bit awkward, but avoids confusion. We try to make this distinction in the 2806/3966 RFCs, reserving "identifier" to something that has a URI. (Dial strings are not tel URIs, for example.) > > - location-dependent numbers might be further categorized into 'home' > emergency numbers (the definition of 'home' relates to a specific > user) > and numbers used in a 'local' region (here 'local emergency numbers'). > "local" here means the valid emergency telephone number used in the > geographic vicinity the user finds himself in. I prefer the term "visited", since this corresponds fairly closely to the mobile IP or 3GPP issues using the same terminology. > > - the sip ua should translate home emergency numbers to a global > emergency identifier. the ua is most likely pre-provisioned with this > information to be able to make such a translation. For SIP devices, we can probably reference the SIP configuration work in this regard, although I wouldn't want to require this. In particular, SIP configuration is, unfortunately, fairly heavy-weight. It is quite possible for a device to determine its home location and then use the same location-to-dial string mapping mechanism that it might use for the 'visited' emergency dial string. > > - there are cases where the sip ua does not recognize the home > emergency > number. in this case the home emergency number is not translated to a > global emergency identifier. a sip proxy (in the visited or the home > network) needs to understand that this is an emergency call. > > - the sip ua should translate local emergency numbers to a global > emergency identifier. I'm guessing that you do mean SHOULD. > > * Tourist Alice collapses, another tourist Bob finds the cell > phone of Alice and dials its own home emergency number (because it > does > not know the local emergency number) and the home emergency number is > different from the local emergency number and Alice/Bob have different > home emergency numbers. > That seems essentially unsolvable. Given typical tourist herds that I have observed, they tend to cluster by nationality (or at least region), if only to make the job of the tour guide a bit easier :-) > > the problem is only that local emergency numbers in one region are not > emergency numbers in another region. > And, more seriously, emergency numbers in one part of the world are used as regular numbers, for services (operator, directory assistance, etc.), prefixes or PBX extensions, elsewhere. > > it seems that some of you want to work on a solution for (1) (or have > already worked on it). > > ciao > hannes > > ps: the user interface is important to us and we need to be aware of > these aspects (as we need to be aware of many other aspects as > well). i > guess that most of you understood what i meant by "out-of-scope". I think we can, at best, reference some of the potential problems, such as the ones that Barbara Stark helpfully pointed out. I suspect that these trade-offs may differ a bit for mobile vs. landline devices. For example, if I'm getting service from the US, but live in Australia, it is probably a wise move to give the user of a stationary device the option of keeping '00' for international operator or using it as an emergency number, following local custom. Given that a one or two incidents of "baby sitter dials 9-1-1 on VoIP phone and gets no answer" caused major regulatory upheaval in the US, I suspect that the default will be to make emergency calls at the current location of the device work, even if that interferes with some other aspect of the dial plan. It is much better to force the user to dial #00 than having a house guest in Adelaide dial 000 to get an ambulance and talk to an international operator in New Jersey instead. As always, the IETF does not have the authority to regulate device manufacturers. It would be up to local regulatory bodies to give standards the force of law or regulation. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 22 12:48:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0jJz-0003fc-5k; Sun, 22 Jan 2006 12:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0jJx-0003fU-RX for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 12:48:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04930 for ; Sun, 22 Jan 2006 12:46:40 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0jT8-0006gx-Q2 for ecrit@ietf.org; Sun, 22 Jan 2006 12:57:39 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0MHlwhw005818; Sun, 22 Jan 2006 18:47:59 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0MHlwjN010409; Sun, 22 Jan 2006 18:47:58 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jan 2006 18:47:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt Date: Sun, 22 Jan 2006 18:46:55 +0100 Message-ID: Thread-Topic: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt Thread-Index: AcYdw9nOXIq8SEZ+SxahhPYRPYshrwBrWYfg From: "Tschofenig, Hannes" To: "Raymond Forbes" , X-OriginalArrivalTime: 22 Jan 2006 17:47:58.0267 (UTC) FILETIME=[FB3598B0:01C61F7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi raymond,=20 thanks for reading our documents.=20 please find some feedback inline: ________________________________ Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im Auftrag von Raymond Forbes Gesendet: Freitag, 20. Januar 2006 14:17 An: ecrit@ietf.org Betreff: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt =09 =09 Ecrit delegates,=20 =09 I read your I-Ds with interest. Thank you.=20 =09 I was slightly concerned that they seam to be very terminal centric in terms of Location provision.=20 [hannes] brian responded to you already about this aspect. we should certainly make sure that the document is well-balanced in the description of the architectural differences. =09 The Discussions in ETSI and the ECC have focused on Validated Location, Validated by the network or Provided within the network by a secure database. What the Validation means to the EU is that the Location on authenticated before it reaches the Emergency Services usually by the CSP (communication Service Provider). Not that it is a valid address or location which is the ecrit definition of validation; both concepts have validity.=20 =09 [hannes] we had a long discussion about the term location validation and i think that we use the terms differently.=20 do you have a pointer to your definition?=20 ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This is an option allowed in Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall=20 Filename: draft-ietf-ecrit-requirements-02.txt =09 [hannes] i have to read into the details of ETSI TS 102 164 but the described scenario seems to be supported by the requirements draft. the ability for an outbound proxy to perform location-based routing is clearly in scope of our work. the ability of using the sip identity work is also allowed and might be quite useful.=20 Real Geographic mapping in the TS 102 164 is calculated within the PSAP by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does not need to be mentioned. It is almost the same as the case (8), acquisition of Location Information by a Call Routing Entity in Title: Security Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8 Requirements for Interface .=20 =09 Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means that User's location cannot be held on a Publically accessible directory database.=20 =09 [hannes] here is the paragraph you are referring to:=20 ( http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 01.txt)=20 " 3. The timeliness, integrity and privacy of call signalling must be ensured as it passes between the emergency caller's device and the PSAP. NOTE - a confidentiality requirement applies to the association of a location with an emergency (e.g., within call signalling) or with an individual. The location data per se is not confidential. " i would like to hear your opinion about the following security aspect. we have two places where confidentiality protection=20 is applicable:=20 a) between the access network and the end host when location information is provided by the access network to the end host (e.g., using dhcp as described in http://www.ietf.org/rfc/rfc3825.txt and in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt )=20 b) as part of the emergency call itself.=20 what problems do you see if confidentiality protection is not applied at (a) and/or at (b) (with regard to the above-mentioned law)? Secondly, I have one question about the Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve a limited geographic region, ..."=20 =09 [hannes] maybe the term 'limited' should be read as 'specific'. the size of the region, however, does not matter for the purpose of location-based routing or for the mapping protocol. as such, it does not matter. I could give a long discourse on these issues. In Summary=20 =09 "PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority. (This terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This definition from Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt is not correct the US people read ETSI documents though US Glasses. The PSAP in ETSI SR 002 180 is not the same as the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as Marc Lisner and NENA are very aware. I'm not sure that this definition error affects the Internet draft very much. All I think these Internet drafts need to concern is the routing to a PASP function Outside the Telephone or IP network.=20 =09 In ETSI the definition of PSAPs is split in into two functions, to cover different national situations, PSAP1 (or the PSAP) which is the first stage access point to the Emergency services This is not mentioned in the I-D. Secondly the PSAP2 (or ECC Emergency Control Centre) these are geographically located. This is the US PSAP and the PSAP mentioned in your document. In the UK this is EOAC, in New Zealand ECC. In Germany these Functions are physically collocated.=20 =09 In Sweden and the UK there are a small number of PSAP1 or (PSAP functions). For Example C&W and T-Mobil route all UK Emergency calls to One PSAP. The Other UK Operators Route all UK Emergency calls to a small number of PSAPs (managed by BT). These may be geographically distributed in times of normal operation, however they may be load distributed in times of severe load or PSAP failure. All Emergency Calls in Sweden are routed to a Small number of PSAPS run by a National Authorised Company called "SOS-Alarm" These are not PSAPs in your document if I read your documents correctly. These PSAPs route the Emergency onto the most appropriate Control or Assistance Centre, Fire, Police, Ambulance, Coastguard, Cave/Mountain/Forest rescue, etc... One Control or assistance Centre may dispatch several Emergency responders to an incident.=20 =09 I think the one word addition of "may" will address this sufficiently.=20 =09 I have discussed this last point with Hannes see below:=20 =09 [hannes] if we can deal with this issue by changing the sentence from =09 "PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority." =09 to =09 ""PSAP (Public Safety Answering Point): Physical location where emergency calls may be received under the responsibility of a public authority." =09 [rcf] agreed.=20 =09 ciao hannes =09 Regards, =09 Ray Forbes. =09 +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =09 =09 =09 =09 "Tschofenig, Hannes" =20 Sent by: "emtel : Emtel" =20 09/01/2006 22:47=20 Please respond to "Tschofenig, Hannes"=20 =20 To: EMTEL@LIST.ETSI.ORG=20 cc: =20 Subject: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt hi all, =09 a new version of our requirements document is available. please send review comments to the mailing list (see http://www.ietf.org/html.charters/ecrit-charter.html). =09 ------------------------- =09 Title : Requirements for Emergency Context Resolution with Internet Technologies=20 Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-02.txt Pages : 27 Date : 2006-1-3=20 =09 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt =09 =09 ------------------------- =09 =09 ciao hannes =09 =09 ------------------------------------------------------------------- Mail archive for EMTEL can be browsed at the following url:=20 http://list.etsi.org/EMTEL.html =09 -------------------------------------------------------------------=20 =09 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 22 14:23:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0koG-0005T4-Ma; Sun, 22 Jan 2006 14:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0koF-0005Sz-LW for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 14:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11139 for ; Sun, 22 Jan 2006 14:22:01 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0kxR-0000xa-2R for ecrit@ietf.org; Sun, 22 Jan 2006 14:33:02 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0MJNAhE025372; Sun, 22 Jan 2006 20:23:10 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0MJN5vH019713; Sun, 22 Jan 2006 20:23:05 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jan 2006 20:23:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jan 2006 20:20:10 +0100 Message-ID: Thread-Topic: Moving sipping-sos draft to ECRIT WG Thread-Index: AcYfiNxj9nSQZWvvRDGb/Or14+cD3g== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 22 Jan 2006 19:23:05.0451 (UTC) FILETIME=[44F4C3B0:01C61F89] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: rohan@ekabal.com, "Peterson, Jon" , marc.linsner@cisco.com, gonzalo.camarillo@ericsson.com Subject: [Ecrit] Moving sipping-sos draft to ECRIT WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 at the last IETF meeting I had a discussion with the SIPPING chairs about a home for the draft-schulzrinne-sipping-service-01.txt draft. During this discussion draft-ietf-sipping-sos-01.txt was also mentioned and we thought that it could be a good idea to move the draft-ietf-sipping-sos-01.txt to the ECRIT working group. Since Henning is currently working on the draft update (based on the recent mailing list discusions) we would like know whether there are some objections against moving the draft-ietf-sipping-sos-01.txt draft from the SIPPING WG to the ECRIT WG. Ciao Hannes/Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 22 15:06:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0lTv-0008Nk-6E; Sun, 22 Jan 2006 15:06:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0lTt-0008NS-Sm for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 15:06:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13731 for ; Sun, 22 Jan 2006 15:05:03 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0ld4-000267-LO for ecrit@ietf.org; Sun, 22 Jan 2006 15:16:04 -0500 Received: (qmail invoked by alias); 22 Jan 2006 20:06:20 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp032) with SMTP; 22 Jan 2006 21:06:20 +0100 X-Authenticated: #29516787 Message-ID: <43D3E5B9.4070103@gmx.net> Date: Sun, 22 Jan 2006 21:06:17 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning, Henning Schulzrinne wrote: > > On Jan 22, 2006, at 8:21 AM, Tschofenig, Hannes wrote: > >> hi all, >> >> i am trying to summarize the discussion related to issue 30/issue 8. >> >> - there are location-dependent and global emergency identifiers. >> global emergency identifiers are, for example the sos uris introduced in >> sipping-sos >> draft. location-dependent emergency identifiers are those that are used >> today in specific countries (see, for example, >> http://www.sccfd.org/travel.html) > > > > This is probably more nit-picking than substance, but I would avoid > using the term "identifier" for dial strings such as "9 1 1". Calling > them 'emergency dial strings' is a bit awkward, but avoids confusion. > We try to make this distinction in the 2806/3966 RFCs, reserving > "identifier" to something that has a URI. (Dial strings are not tel > URIs, for example.) > that's fine with me. > >> >> - location-dependent numbers might be further categorized into 'home' >> emergency numbers (the definition of 'home' relates to a specific user) >> and numbers used in a 'local' region (here 'local emergency numbers'). >> "local" here means the valid emergency telephone number used in the >> geographic vicinity the user finds himself in. > > > I prefer the term "visited", since this corresponds fairly closely to > the mobile IP or 3GPP issues using the same terminology. actually, i thought about using the term 'visited' and then went back to the mailing list discussion and followed the suggestion you made in one of your previous mails. in fact, i also thought that the term 'visited' is not quite appropriate here since 'visited' and 'home network' refers to an administrative domain rather than a region that happens to use the same emergency dial strings. with the mobile ip terminology it is quitely that you move from one visited network to another one but you are still within an area that uses the same dial strings. > > >> >> - the sip ua should translate home emergency numbers to a global >> emergency identifier. the ua is most likely pre-provisioned with this >> information to be able to make such a translation. > > > For SIP devices, we can probably reference the SIP configuration work > in this regard, although I wouldn't want to require this. In > particular, SIP configuration is, unfortunately, fairly heavy-weight. > It is quite possible for a device to determine its home location and > then use the same location-to-dial string mapping mechanism that it > might use for the 'visited' emergency dial string. i also thought about this. it might be possible to use the sip device config framework. this aspect was, however, not important for the summary of the mailing list discussion. > > >> >> - there are cases where the sip ua does not recognize the home emergency >> number. in this case the home emergency number is not translated to a >> global emergency identifier. a sip proxy (in the visited or the home >> network) needs to understand that this is an emergency call. >> >> - the sip ua should translate local emergency numbers to a global >> emergency identifier. > > > I'm guessing that you do mean SHOULD. yes, if i write it as input for the requirements document. with this version i just want to get sure that i roughly got the point of this discussion. > > >> >> * Tourist Alice collapses, another tourist Bob finds the cell >> phone of Alice and dials its own home emergency number (because it does >> not know the local emergency number) and the home emergency number is >> different from the local emergency number and Alice/Bob have different >> home emergency numbers. >> > > That seems essentially unsolvable. not the entire set of local emergency dial strings is not in any country for another purpose. > Given typical tourist herds that I > have observed, they tend to cluster by nationality (or at least > region), if only to make the job of the tour guide a bit easier :-) i tend to agree with you. > > >> >> the problem is only that local emergency numbers in one region are not >> emergency numbers in another region. >> > > And, more seriously, emergency numbers in one part of the world are > used as regular numbers, for services (operator, directory assistance, > etc.), prefixes or PBX extensions, elsewhere. yes. that's what i meant. > > >> >> it seems that some of you want to work on a solution for (1) (or have >> already worked on it). >> >> ciao >> hannes >> >> ps: the user interface is important to us and we need to be aware of >> these aspects (as we need to be aware of many other aspects as well). i >> guess that most of you understood what i meant by "out-of-scope". > > > I think we can, at best, reference some of the potential problems, such > as the ones that Barbara Stark helpfully pointed out. I suspect that > these trade-offs may differ a bit for mobile vs. landline devices. > > For example, if I'm getting service from the US, but live in Australia, > it is probably a wise move to give the user of a stationary device the > option of keeping '00' for international operator or using it as an > emergency number, following local custom. Given that a one or two > incidents of "baby sitter dials 9-1-1 on VoIP phone and gets no answer" > caused major regulatory upheaval in the US, I suspect that the default > will be to make emergency calls at the current location of the device > work, even if that interferes with some other aspect of the dial plan. > It is much better to force the user to dial #00 than having a house > guest in Adelaide dial 000 to get an ambulance and talk to an > international operator in New Jersey instead. > > As always, the IETF does not have the authority to regulate device > manufacturers. It would be up to local regulatory bodies to give > standards the force of law or regulation. maybe this is another topic for the bcp? ciao hannes > > Henning > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 22 15:53:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mDT-0003jW-JQ; Sun, 22 Jan 2006 15:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mDS-0003jO-23 for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 15:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16224 for ; Sun, 22 Jan 2006 15:52:09 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0mMe-0003PQ-5q for ecrit@ietf.org; Sun, 22 Jan 2006 16:03:09 -0500 Received: by uproxy.gmail.com with SMTP id j3so482349ugf for ; Sun, 22 Jan 2006 12:53:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ck/nu3Jcv8Mw5c0e8dQp2mWFdHpzJOsFGoiERpl8WtAM3Lf2F9sWL7OSkpTyccZ/l3Vc4Hj7LGUwguKu9oaLzHvDKTf2AFx7Ki7oiqbipv0Sh1OkS6RmfA1FQH7U//t3w6MHjhXibQK3F9FFcdg+3mepJaJSYCKnBi8X2sRL0Zk= Received: by 10.49.9.19 with SMTP id m19mr282709nfi; Sun, 22 Jan 2006 12:53:32 -0800 (PST) Received: by 10.48.4.20 with HTTP; Sun, 22 Jan 2006 12:53:32 -0800 (PST) Message-ID: Date: Sun, 22 Jan 2006 21:53:32 +0100 From: Murugaraj Shanmugam To: ecrit@ietf.org Subject: Re: [Ecrit] re: I-D ACTION:draft-taylor-ecrit-security-threats-01.txt In-Reply-To: <43A97150.9080904@nortel.com> MIME-Version: 1.0 References: <43A97150.9080904@nortel.com> X-Spam-Score: 2.4 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: murugaraj.shanmugam@siemens.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484247657==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0484247657== Content-Type: multipart/alternative; boundary="----=_Part_9200_18708985.1137963212038" ------=_Part_9200_18708985.1137963212038 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, the interim meeting is getting closer and Hannes asked me to summarize the changes after Steven Kent's draft review (provided after IETF#64). Based on his feedback we produced the current draft version draft-taylor-ecrit-security-threats-01.txt. The crux of Steven's comments is as follows: a) The draft should explain the architecture of the emergency calling functionality, describe the operation model, present the threat model with different classes of adversaries, motivations and their capabilities and articulate the security requirments. b) No counter measures should be discussed in this draft, since the counte= r measures were not self-explanatory. As a consequence this version of the draft has been rewritten from the scratch to reflect Steven Kent's comments. * Emergency call routing system overview to describe the operation of the model, * listed and discussed the diffenrent variants of potenial attacks, * presented the security requirements with respect to the emergency model described in this document. * removed the discussion of countermeasures. A more detailed mail was sent to the list at the end of last year: http://www1.ietf.org/mail-archive/web/ecrit/current/msg01251.html ciao, Raj ------=_Part_9200_18708985.1137963212038 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi all,

the interim meeting is getting closer and Hannes asked = me to summarize the changes after Steven Kent's draft review (provided afte= r IETF#64). Based on his feedback we produced the current draft version=20 draft-taylor-ecrit-security-threats-01.txt.

The crux of Steven'= s comments is as follows:

a) The draft should explain the archi= tecture of the emergency calling  functionality, describe the operatio= n model, present the threat model with different classes of  adversari= es, motivations and their capabilities  and articulate the security re= quirments.

b) No counter measures should be discussed in this draft, since the=   counter measures were not  self-explanatory.

As a conseq= uence this version of the draft has been rewritten from the scratch to refl= ect Steven Kent's comments.

* Emergency call routing system overview to describe the operation = of the model,

* listed and discussed the diffenrent variants of pote= nial attacks,

* presented the security requirements with respect to = the emergency model described in this document.

* removed the discussion of countermeasures.

A more detailed= mail was sent to the list at the end of last year:
http://www1.ietf.org/mail-archive/web/ecrit/current= /msg01251.html

ciao,
Raj
------=_Part_9200_18708985.1137963212038-- --===============0484247657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0484247657==-- From ecrit-bounces@ietf.org Sun Jan 22 17:52:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0o4T-0001nu-Fu; Sun, 22 Jan 2006 17:52:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0o4R-0001l8-Fj for ecrit@megatron.ietf.org; Sun, 22 Jan 2006 17:52:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24251 for ; Sun, 22 Jan 2006 17:50:58 -0500 (EST) Message-Id: <200601222250.RAA24251@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0oDe-0006ve-MM for ecrit@ietf.org; Sun, 22 Jan 2006 18:01:59 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0o4H-000E9S-BD; Sun, 22 Jan 2006 22:52:17 +0000 To: "Tschofenig, Hannes" Date: Sun, 22 Jan 2006 14:52:17 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rohan@ekabal.com, "Peterson, Jon" , marc.linsner@cisco.com, ecrit@ietf.org, gonzalo.camarillo@ericsson.com Subject: [Ecrit] Re: Moving sipping-sos draft to ECRIT WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, Hannes, The fact that sos is a sipping document is an accident, in my records. I did not take it through a charter approval. My opinion: I think you should not move the sos draft to ecrit unless the technology is adopted as a WG item. Your discussion with the SIPPING WG chairs is not the same thing as the ECRIT WG expressing the goal to adopt a document and then it becoming chartered (if needed) and a WG doc. I think it would be reasonable for Henning to change the i-d name of the draft to draft-schulzrinne-ecrit-sos so it would show up in the ecrit-related documents. Allison _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 04:18:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0xpt-0000NQ-9g; Mon, 23 Jan 2006 04:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0xpp-0000Mh-KX; Mon, 23 Jan 2006 04:18:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01031; Mon, 23 Jan 2006 04:16:32 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0xz8-0006qB-O7; Mon, 23 Jan 2006 04:27:39 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0N9BjtS032748; Mon, 23 Jan 2006 09:17:34 GMT (envelope-from raymond.forbes@Marconi.com) In-Reply-To: To: "Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Summary MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Mon, 23 Jan 2006 09:18:14 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/01/2006 09:17:32, Serialize complete at 23/01/2006 09:17:32 X-Spam-Score: 2.4 (++) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: ecrit@ietf.org, ecrit-bounces@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0040147161==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0040147161== Content-Type: multipart/alternative; boundary="=_alternative 00329CA8802570FF_=" This is a multipart message in MIME format. --=_alternative 00329CA8802570FF_= Content-Type: text/plain; charset="US-ASCII" Henning, See point below labelled [rcf]: Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. Henning Schulzrinne Sent by: ecrit-bounces@ietf.org 22/01/2006 16:13 To: "Tschofenig, Hannes" cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary On Jan 22, 2006, at 8:21 AM, Tschofenig, Hannes wrote: > hi all, > > i am trying to summarize the discussion related to issue 30/issue 8. > > - there are location-dependent and global emergency identifiers. > global emergency identifiers are, for example the sos uris > introduced in > sipping-sos > draft. location-dependent emergency identifiers are those that are > used > today in specific countries (see, for example, > http://www.sccfd.org/travel.html) This is probably more nit-picking than substance, but I would avoid using the term "identifier" for dial strings such as "9 1 1". Calling them 'emergency dial strings' is a bit awkward, but avoids confusion. We try to make this distinction in the 2806/3966 RFCs, reserving "identifier" to something that has a URI. (Dial strings are not tel URIs, for example.) > > - location-dependent numbers might be further categorized into 'home' > emergency numbers (the definition of 'home' relates to a specific > user) > and numbers used in a 'local' region (here 'local emergency numbers'). > "local" here means the valid emergency telephone number used in the > geographic vicinity the user finds himself in. I prefer the term "visited", since this corresponds fairly closely to the mobile IP or 3GPP issues using the same terminology. > > - the sip ua should translate home emergency numbers to a global > emergency identifier. the ua is most likely pre-provisioned with this > information to be able to make such a translation. For SIP devices, we can probably reference the SIP configuration work in this regard, although I wouldn't want to require this. In particular, SIP configuration is, unfortunately, fairly heavy-weight. It is quite possible for a device to determine its home location and then use the same location-to-dial string mapping mechanism that it might use for the 'visited' emergency dial string. > > - there are cases where the sip ua does not recognize the home > emergency > number. in this case the home emergency number is not translated to a > global emergency identifier. a sip proxy (in the visited or the home > network) needs to understand that this is an emergency call. > > - the sip ua should translate local emergency numbers to a global > emergency identifier. I'm guessing that you do mean SHOULD. > > * Tourist Alice collapses, another tourist Bob finds the cell > phone of Alice and dials its own home emergency number (because it > does > not know the local emergency number) and the home emergency number is > different from the local emergency number and Alice/Bob have different > home emergency numbers. > That seems essentially unsolvable. Given typical tourist herds that I have observed, they tend to cluster by nationality (or at least region), if only to make the job of the tour guide a bit easier :-) [rcf]: GSM Cell Phones address this problem as they can dail a number of Emergency numbers from the SIM Card. The Phone can translate the Dialled number into the Local Emergency number 112, 911, 110, 111, 000 etc... > > the problem is only that local emergency numbers in one region are not > emergency numbers in another region. > And, more seriously, emergency numbers in one part of the world are used as regular numbers, for services (operator, directory assistance, etc.), prefixes or PBX extensions, elsewhere. > > it seems that some of you want to work on a solution for (1) (or have > already worked on it). > > ciao > hannes > > ps: the user interface is important to us and we need to be aware of > these aspects (as we need to be aware of many other aspects as > well). i > guess that most of you understood what i meant by "out-of-scope". I think we can, at best, reference some of the potential problems, such as the ones that Barbara Stark helpfully pointed out. I suspect that these trade-offs may differ a bit for mobile vs. landline devices. For example, if I'm getting service from the US, but live in Australia, it is probably a wise move to give the user of a stationary device the option of keeping '00' for international operator or using it as an emergency number, following local custom. Given that a one or two incidents of "baby sitter dials 9-1-1 on VoIP phone and gets no answer" caused major regulatory upheaval in the US, I suspect that the default will be to make emergency calls at the current location of the device work, even if that interferes with some other aspect of the dial plan. It is much better to force the user to dial #00 than having a house guest in Adelaide dial 000 to get an ambulance and talk to an international operator in New Jersey instead. As always, the IETF does not have the authority to regulate device manufacturers. It would be up to local regulatory bodies to give standards the force of law or regulation. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 00329CA8802570FF_= Content-Type: text/html; charset="US-ASCII"
Henning,

See point below labelled [rcf]:

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


Henning Schulzrinne <hgs@cs.columbia.edu>
Sent by: ecrit-bounces@ietf.org

22/01/2006 16:13

       
        To:        "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
        cc:        ecrit@ietf.org
        Subject:        Re: [Ecrit] Issue 30: Summary




On Jan 22, 2006, at 8:21 AM, Tschofenig, Hannes wrote:

> hi all,
>
> i am trying to summarize the discussion related to issue 30/issue 8.
>
> - there are location-dependent and global emergency identifiers.
> global emergency identifiers are, for example the sos uris  
> introduced in
> sipping-sos
> draft. location-dependent emergency identifiers are those that are  
> used
> today in specific countries (see, for example,
> http://www.sccfd.org/travel.html)


This is probably more nit-picking than substance, but I would avoid  
using the term "identifier" for dial strings such as "9 1 1". Calling  
them 'emergency dial strings' is a bit awkward, but avoids confusion.  
We try to make this distinction in the 2806/3966 RFCs, reserving  
"identifier" to something that has a URI. (Dial strings are not tel  
URIs, for example.)


>
> - location-dependent numbers might be further categorized into 'home'
> emergency numbers (the definition of 'home' relates to a specific  
> user)
> and numbers used in a 'local' region (here 'local emergency numbers').
> "local" here means the valid emergency telephone number used in the
> geographic vicinity the user finds himself in.

I prefer the term "visited", since this corresponds fairly closely to  
the mobile IP or 3GPP issues using the same terminology.


>
> - the sip ua should translate home emergency numbers to a global
> emergency identifier. the ua is most likely pre-provisioned with this
> information to be able to make such a translation.

For SIP devices, we can probably reference the SIP configuration work  
in this regard, although I wouldn't want to require this. In  
particular, SIP configuration is, unfortunately, fairly heavy-weight.  
It is quite possible for a device to determine its home location and  
then use the same location-to-dial string mapping mechanism that it  
might use for the 'visited' emergency dial string.


>
> - there are cases where the sip ua does not recognize the home  
> emergency
> number. in this case the home emergency number is not translated to a
> global emergency identifier. a sip proxy (in the visited or the home
> network) needs to understand that this is an emergency call.
>
> - the sip ua should translate local emergency numbers to a global
> emergency identifier.

I'm guessing that you do mean SHOULD.


>
>   * Tourist Alice collapses, another tourist Bob finds the cell
> phone of Alice and dials its own home emergency number (because it  
> does
> not know the local emergency number) and the home emergency number is
> different from the local emergency number and Alice/Bob have different
> home emergency numbers.
>

That seems essentially unsolvable. Given typical tourist herds that I  
have observed, they tend to cluster by nationality (or at least  
region), if only to make the job of the tour guide a bit easier :-)

[rcf]: GSM Cell Phones address this problem as they can dail a number of Emergency numbers from the SIM Card. The Phone can translate the Dialled number into the Local Emergency number 112, 911, 110, 111, 000 etc...

>
> the problem is only that local emergency numbers in one region are not
> emergency numbers in another region.
>

And, more seriously, emergency numbers in one part of the world are  
used as regular numbers, for services (operator, directory  
assistance, etc.), prefixes or PBX extensions, elsewhere.


>
> it seems that some of you want to work on a solution for (1) (or have
> already worked on it).
>
> ciao
> hannes
>
> ps: the user interface is important to us and we need to be aware of
> these aspects (as we need to be aware of many other aspects as  
> well). i
> guess that most of you understood what i meant by "out-of-scope".

I think we can, at best, reference some of the potential problems,  
such as the ones that Barbara Stark helpfully pointed out. I suspect  
that these trade-offs may differ a bit for mobile vs. landline devices.

For example, if I'm getting service from the US, but live in  
Australia, it is probably a wise move to give the user of a  
stationary device the option of keeping '00' for international  
operator or using it as an emergency number, following local custom.  
Given that a one or two incidents of "baby sitter dials 9-1-1 on VoIP  
phone and gets no answer" caused major regulatory upheaval in the US,  
I suspect that the default will be to make emergency calls at the  
current location of the device work, even if that interferes with  
some other aspect of the dial plan. It is much better to force the  
user to dial #00 than having a house guest in Adelaide dial 000 to  
get an ambulance and talk to an international operator in New Jersey  
instead.

As always, the IETF does not have the authority to regulate device  
manufacturers. It would be up to local regulatory bodies to give  
standards the force of law or regulation.

Henning



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--=_alternative 00329CA8802570FF_=-- --===============0040147161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0040147161==-- From ecrit-bounces@ietf.org Mon Jan 23 04:18:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0xps-0000N4-07; Mon, 23 Jan 2006 04:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0xpo-0000Mb-Aw for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 04:18:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01026 for ; Mon, 23 Jan 2006 04:16:31 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0xz6-0006pd-TF for ecrit@ietf.org; Mon, 23 Jan 2006 04:27:37 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0N9BjtR032748; Mon, 23 Jan 2006 09:17:32 GMT (envelope-from raymond.forbes@Marconi.com) In-Reply-To: <005801c61ddf$ab28fb20$640fa8c0@cis.neustar.com> To: Subject: RE: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Mon, 23 Jan 2006 09:18:10 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/01/2006 09:17:30, Serialize complete at 23/01/2006 09:17:30 X-Spam-Score: 0.0 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010101722==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============2010101722== Content-Type: multipart/alternative; boundary="=_alternative 0031A339802570FF_=" This is a multipart message in MIME format. --=_alternative 0031A339802570FF_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QnJpYW4sDQoNCkkgbmV2ZXIgcHJvcG9zZWQgdG8gcmVtb3ZlIHRoZSB3b3JkICJsaW1pdGVkIiwg Y2xlYXJseSBhIFBTQVAgKHdoYXRldmVyIA0KZGVmaW5pdGlvbiB3ZSB1c2UpIGlzIG5hdGlvbmFs LCBJIG9ubHkgcHJvcG9zZWQgdG8gYWRkIHRoZSB3b3JkICJtYXkiIGFzIGEgDQpQU0FQIG1heSBi ZSBuYXRpb25hbCwgbm90IGxpbWl0ZWQgdG8gYSBnZW9ncmFwaGljIHJlZ2lvbiB3aXRoaW4gYSBj b3VudHJ5Lg0KDQpJIG5ldmVyIHByb3Bvc2VkIHRvIGNoYW5nZSB0aGUgZGVmaW5pdGlvbiBvZiBQ U0FQLCBqdXN0IHRvIHVuZGVyc3RhbmQgdGhhdCANCndlIHJlYWQgdGhlIHdvcmRzIGRpZmZlcmVu dGx5Lg0KDQpJIGRvIHByb3Bvc2UgdG8gZGVsZXRlIHRoZSBub3RlLCBhcyB5b3UgYWdyZWUuDQoN CkkgYW0gc3VyZSB0aGF0IHdlIGNhbiBmaW5kIHJvb20gZm9yIGNvbW1vbiBhZ3JlZW1lbnQuIE9u IHRoZSB0d28gcG9pbnRzIA0KdGhhdCBJIHByb3Bvc2UNCg0KUmVnYXJkcywNCg0KUmF5IEZvcmJl cy4NCg0KKzQ0IDI0IDc2NTYgMzEwNiBwaG9uZQ0KKzQ0IDI0IDc2NTYgMzgxNiBmYXguDQorNDQg NzcxIDg1MSAxMzYxIE1vYmlsZS90ZXh0DQotLS0tLS0tLS0tLS0NClRoaXMgZS1tYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbC4gIElmIHlvdSBhcmUgbm90IHRoZSANCmlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseSBl LW1haWwgYW5kIHRoZW4gDQpkZWxldGUgdGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uIERv IG5vdCBjb3B5IHRoaXMgZS1tYWlsIG9yIGFueSANCmF0dGFjaG1lbnRzLCB1c2UgdGhlIGNvbnRl bnRzIGZvciBhbnkgcHVycG9zZSwgb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIA0KYW55IG90 aGVyIHBlcnNvbjogdG8gZG8gc28gY291bGQgYmUgYSBicmVhY2ggb2YgY29uZmlkZW5jZS4NCg0K DQoNCg0KDQoiQnJpYW4gUm9zZW4iIDxickBicmlhbnJvc2VuLm5ldD4NCjIwLzAxLzIwMDYgMTY6 MzYNClBsZWFzZSByZXNwb25kIHRvIGJyDQogDQogICAgICAgIFRvOiAgICAgIidSYXltb25kIEZv cmJlcyciIDxyYXltb25kLmZvcmJlc0BtYXJjb25pLmNvbT4sIA0KPGVjcml0QGlldGYub3JnPg0K ICAgICAgICBjYzogDQogICAgICAgIFN1YmplY3Q6ICAgICAgICBSRTogW0Vjcml0XSBGdzogW0VN VEVMXSBJLUQgDQpBQ1RJT046ZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDIudHh0DQoN Cg0KUmF5DQoNCldlIGZvY3VzIG9uIGJlaW5nIHRlcm1pbmFsIGNlbnRyaWMgYmVjYXVzZSBpbiBt YW55IGNhc2VzIHRoZSBhY2Nlc3MgDQpuZXR3b3JrDQpwcm92aWRlciwgd2hpY2ggaXMgdGhlIG9u bHkgY2FycmllciB0aGF0IGtub3dzIHdoZXJlIHRoZSB0ZXJtaW5hbCBpcywgaXMgDQpub3QNCnRo ZSBDU1AuICBUaGUgQ1NQIG1heSBiZSBpbiBhIGRpZmZlcmVudCBjb3VudHJ5IGFuZCBub3Qgc3Vi amVjdCB0byBsYXdzDQp3aGVyZSB0aGUgdGVybWluYWwgaXMsIGV2ZW4gdGhvdWdoIGl0IGlzIHBy b3ZpZGluZyB0ZWxlcGhvbnkgc2VydmljZXMgdG8gDQppdC4NClRoZSBsZWdhbCBzdGF0dXMgaXMg bm90IHRoZSBpbXBvcnRhbnQgcGFydDsgaXQgaXMgdGhlIGZhY3QgdGhhdCB0aGUgQ1NQDQpkb2Vz buKAmXQga25vdyB3aGVyZSB0aGUgdGVybWluYWwgaXMuICBUaGUgdGVybWluYWwgaG93ZXZlciwg aXMgYmVpbmcgDQpwcm92aWRlZA0KcGFja2V0IHNlcnZpY2UgYnkgdGhlIGFjY2VzcyBuZXR3b3Jr LCBhbmQgaXMgdGhlIHBvaW50IHdoZXJlIHRoZSANCnN1YnNjcmliZXINCnRvIHRoZSBhY2Nlc3Mg bmV0d29yayBtZWV0cyB0aGUgc3Vic2NyaWJlciB0byB0aGUgQ1NQLiAgVGhhdCBpcyB3aHkgd2Ug DQpmb2N1cw0Kb24gdGhlIHRlcm1pbmFsIOKAkyBiZWNhdXNlIHRoZSBhY2Nlc3MgbmV0d29yayBj YW4gc3VwcGx5IGxvY2F0aW9uIHRvIHRoZQ0KdGVybWluYWwsIGFuZCB0aGUgdGVybWluYWwgY2Fu IHN1cHBseSBsb2NhdGlvbiB0byB0aGUgQ1NQLiAgQXR0ZW1wdGluZyB0bw0KcGFzcyBpbmZvcm1h dGlvbiBiZXR3ZWVuIHRoZSBhY2Nlc3MgbmV0d29yayBhbmQgdGhlIENTUCBpcyBmcmF1Z2h0IHdp dGgNCmRpZmZpY3VsdHksIHRoZSBtb3N0IHNldmVyZSBvZiB3aGljaCBpcyBpZGVudGlmaWVycyA9 IGhvdyB0aGUgYWNjZXNzIA0KbmV0d29yaw0KY291bGQgaWRlbnRpZnkgdGhlIENTUCBzdWJzY3Jp YmVyLg0KDQpXZSBoYXZlIHNvbWUgdGVybWlub2xvZ3kgaXNzdWVzLCBiZWNhdXNlIHdlIGFyZSB1 c2luZyB0aGUgdGVybSDigJxWYWxpZOKAnSB0bw0KbWVhbiB0aGF0IHRoZSBsb2NhdGlvbiBpcyBv bmUgcmVjb2duaXplZCBieSB0aGUgcHVibGljIHNhZmV0eSBhZ2VuY2llcyBhcyANCmENCmxvY2F0 aW9uIHRoZXkga25vdyBob3cgdG8gc2VuZCByZXNwb25kZXJzLiAgVmFsaWRhdGVkIHRodXMgbWVh bnMgd2UgaGF2ZQ0KdGFrZW4gc3RlcHMgdG8gYXNzdXJlIHRoYXQgdGhlIGxvY2F0aW9uIGlzIGEg dmFsaWQgb25lLiAgUHJvdGVjdGluZyB0aGUNCmluZm9ybWF0aW9uIGZyb20gZm9yZ2VyeSBvciBt b2RpZmljYXRpb24gaXMgYSBkaWZmZXJlbnQgaXNzdWUgd2hpY2ggaXMgDQphbHNvDQppbXBvcnRh bnQgdG8gdXMuDQoNCkkgaGF2ZSBubyBwcm9ibGVtIHJlbW92aW5nIHRoZSBOb3RlIGluIHRoZSBz ZWN1cml0eSB0aHJlYXRzIGRvY3VtZW50Lg0KDQpIb3dldmVyLCBJIGRvIGhhdmUgYSBwcm9ibGVt IHdpdGggcmVtb3ZpbmcgdGhlIHdvcmQg4oCcbGltaXRlZOKAnSBpbiB0aGUNCmdlb2dyYXBoaWMg Y292ZXJhZ2Ugb2YgYSBQU0FQLiAgRXZlbiBpZiBvbmUgUFNBUCBzZXJ2ZXMgdGhlIGVudGlyZSAN CmNvdW50cnksDQppdHMgc2VydmljZSBib3VuZGFyeSBpcyBsaW1pdGVkIHRvIHRoYXQgY291bnRy eS4gIFNvIEkgdGhpbmsgdGhlIA0KcmVxdWlyZW1lbnQNCmlzIHByb3Blcmx5IHN0YXRlZC4gIEkg d291bGQgbm90IG9wcG9zZSBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9uIA0KKOKAnGFsdGhvdWdo DQp0aGF0IHJlZ2lvbiBtYXkgYmUgYXMgbGFyZ2UgYXMgYW4gZW50aXJlIGNvdW50cnnigJ0pLCBi dXQgSSBkb27igJl0IHJlYWxseSANCnRoaW5rDQppdCBpcyBuZWVkZWQuDQoNCkFsdGhvdWdoIEkg ZG9u4oCZdCBoYXZlIGEgYmlnIHByb2JsZW0gd2l0aCB0aGUgY2hhbmdlIHRvIHRoZSBQU0FQIA0K ZGVmaW5pdGlvbiwNCkkgZG8gd29uZGVyIGlmIHdlIHdvdWxkIGJlIGJldHRlciBvZmYgY2hhbmdp bmcgdGhlIGRlZmluaXRpb24gdG8gc2F5IHRoYXQNCnRoZSBQU0FQIGlzIHdoZXJlIHRoZSBjYWxs IGlzIGZpcnN0IGFuc3dlcmVkLg0KDQpCcmlhbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpl Y3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNClJheW1vbmQgRm9yYmVzDQpTZW50 OiBGcmlkYXksIEphbnVhcnkgMjAsIDIwMDYgODoxNyBBTQ0KVG86IGVjcml0QGlldGYub3JnDQpT dWJqZWN0OiBbRWNyaXRdIEZ3OiBbRU1URUxdIEktRCANCkFDVElPTjpkcmFmdC1pZXRmLWVjcml0 LXJlcXVpcmVtZW50cy0wMi50eHQNCg0KDQpFY3JpdCBkZWxlZ2F0ZXMsIA0KDQpJIHJlYWQgeW91 ciBJLURzIHdpdGggaW50ZXJlc3QuIFRoYW5rIHlvdS4gDQoNCkkgd2FzIHNsaWdodGx5IGNvbmNl cm5lZCB0aGF0IHRoZXkgc2VhbSB0byBiZSB2ZXJ5IHRlcm1pbmFsIGNlbnRyaWMgaW4gDQp0ZXJt cw0Kb2YgTG9jYXRpb24gcHJvdmlzaW9uLiANCg0KVGhlIERpc2N1c3Npb25zIGluIEVUU0kgYW5k IHRoZSBFQ0MgaGF2ZSBmb2N1c2VkIG9uIFZhbGlkYXRlZCBMb2NhdGlvbiwNClZhbGlkYXRlZCBi eSB0aGUgbmV0d29yayBvciBQcm92aWRlZCB3aXRoaW4gdGhlIG5ldHdvcmsgYnkgYSBzZWN1cmUN CmRhdGFiYXNlLiBXaGF0IHRoZSBWYWxpZGF0aW9uIG1lYW5zIHRvIHRoZSBFVSBpcyB0aGF0IHRo ZSBMb2NhdGlvbiBvbg0KYXV0aGVudGljYXRlZCBiZWZvcmUgaXQgcmVhY2hlcyB0aGUgRW1lcmdl bmN5IFNlcnZpY2VzIHVzdWFsbHkgYnkgdGhlIENTUA0KKGNvbW11bmljYXRpb24gU2VydmljZSBQ cm92aWRlcikuIE5vdCB0aGF0IGl0IGlzIGEgdmFsaWQgYWRkcmVzcyBvciANCmxvY2F0aW9uDQp3 aGljaCBpcyB0aGUgZWNyaXQgZGVmaW5pdGlvbiBvZiB2YWxpZGF0aW9uOyBib3RoIGNvbmNlcHRz IGhhdmUgdmFsaWRpdHkuIA0KDQpFVFNJIFRTIDEwMiAxNjQgQXNzdW1lcyB0aGF0IGhlIFJvdXRp bmcgdG93YXJkIHRoZSBQU0FQIGlzIGdlbmVyYXRlZCBieSANCnRoZQ0KQ0xJOyBhbmQgaW4gRVRT SSBUSVNQQU4gTkdOIHRoYXQgdGhlIFNJUCByb3V0aW5nIHRvd2FyZCB0aGUgUFNBUCB3aWxsIGJl DQpmcm9tIEFzc2VydGVkIElkZW50aXR5IEluZm9ybWF0aW9uIGFkZGVkIG9mIHZhbGlkYXRlZCBi eSB0aGUgRVNSUDsgVGhpcyBpcw0KYW4gb3B0aW9uIGFsbG93ZWQgaW4gVGl0bGU6IFJlcXVpcmVt ZW50cyBmb3IgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbg0Kd2l0aCBJbnRlcm5ldCBUZWNo bm9sb2dpZXMgQXV0aG9yKHMpOiBILiBTY2h1bHpyaW5uZSwgUi4gTWFyc2hhbGwgDQpGaWxlbmFt ZTogZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDIudHh0DQoNClJlYWwgR2VvZ3JhcGhp YyBtYXBwaW5nIGluIHRoZSBUUyAxMDIgMTY0IGlzIGNhbGN1bGF0ZWQgd2l0aGluIHRoZSBQU0FQ IGJ5DQpzZWN1cmUgbG9vayB1cCBpbnRvIHRoZSBvcGVyYXRvcnMgImRpcmVjdG9yeSIgZGF0YWJh c2VzIChieSBhIFByaXZhdGUNCnNlcnZpY2UgSVAgbGluaykuIFRoZSBFVSBoYXMgc3BlY2lhbCBw cm92aXNpb24gdG8gYWxsb3cgYW5kIHJlcXVpcmUgdGhpcw0Kd2l0aCB0aGUgRVUgZGF0YSBwcm90 ZWN0aW9uIERpcmVjdGl2ZS4gVGhpcyBpcyBub3QgbWVudGlvbmVkLCBidXQgZG9lcyBub3QNCm5l ZWQgdG8gYmUgbWVudGlvbmVkLiBJdCBpcyBhbG1vc3QgdGhlIHNhbWUgYXMgdGhlIGNhc2UgKDgp LCBhY3F1aXNpdGlvbiANCm9mDQpMb2NhdGlvbiBJbmZvcm1hdGlvbiBieSBhIENhbGwgUm91dGlu ZyBFbnRpdHkgaW4gVGl0bGU6IFNlY3VyaXR5IFRocmVhdHMgDQphbmQNClJlcXVpcmVtZW50cyBm b3IgRW1lcmdlbmN5IENhbGxpbmcgQXV0aG9yKHMpOiBILiBTY2h1bHpyaW5uZSwgZXQgYWwuDQpG aWxlbmFtZTogZHJhZnQtdGF5bG9yLWVjcml0LXNlY3VyaXR5LXRocmVhdHMtMDEudHh0IHdoZXJl IGluIGNoYXB0ZXIgNi44DQpSZXF1aXJlbWVudHMgZm9yIEludGVyZmFjZSAuIA0KDQpGaXJzdGx5 LCBTZWN1cml0eSBUaHJlYXRzIGFuZCBSZXF1aXJlbWVudHMgZm9yIEVtZXJnZW5jeSBDYWxsaW5n DQpkcmFmdC10YXlsb3ItZWNyaXQtc2VjdXJpdHktdGhyZWF0cy0wMS50eHQgb24gUGFnZSA2IHBv aW50IDMuIFRoZSBOb3RlIGlzDQpub3QgYmUgdHJ1ZSBhY2NvcmRpbmcgdG8gRXVyb3BlYW4gRGly ZWN0aXZlIGFuZCBFdXJvcGUtd2lkZSBsYXdzLiBUaGUgRVUNCmRhdGEgcHJvdGVjdGlvbiBkaXJl Y3RpdmUgc3RhdGVzIHRoYXQgTG9jYXRpb24gaXMgUHJpdmF0ZSBkYXRhIHRvIHRoZSB1c2VyDQp0 aGF0IG11c3QgYmUgc2VjdXJlZCB1bmRlciB0aGUgdXNlcidzIHJpZ2h0IHRvIHJldmVhbCwgd2l0 aHN0YW5kaW5nIHRoZQ0KdGhyZWUgdmVyeSBjbGVhciBsZWdhbCBleGNlcHRpb25zOiB3aGljaCBh cmUgMS4gTmF0aW9uYWwgU2VjdXJpdHk7IDIuDQpDcmltaW5hbCBBY3Rpdml0eSBhbmQgMy4gbWFr aW5nIGFuIEVtZXJnZW5jeSBjYWxsIG9yIFJlcXVlc3QgdG8gdGhlDQpFbWVyZ2VuY3kgc2Vydmlj ZXMuIFRoZXNlIEF1dGhvcml0eSBtdXN0IGxlZ2FsbHkgcmVzcGVjdCB0aGUgcmlnaHRzIG9mIHRo ZQ0KVXNlciBub3QgdG8gcmV2ZWFsIHRoZSBsb2NhdGlvbiB0byB0aGlyZCBwYXJ0aWVzIGFuZCBj b21tZXJjaWFsDQpvcmdhbmlzYXRpb25zLiBJIHN1Z2dlc3QgdGhhdCB5b3UgZGVsZXRlIHRoZSBu b3RlLiBFVSBEaXJlY3RpdmVzIGFuZA0KRXVyb3BlYW4td2lkZSBsYXcgY292ZXJzIGF0IGxlYXN0 IDMwIGNvdW50cmllcy4gVW5kZXIgRVUgRGlyZWN0aXZlcyB0aGUNClVzZXIncyBMb2NhdGlvbiBp cyBQcml2YXRlIGRhdGEgdGhhdCBjYW5ub3QgYmUgcmV2ZWFsZWQgZXhjZXB0IG9uIHRoZQ0KY29t bWVyY2lhbCByZXF1ZXN0IG9mIHRoZSBVc2VyIGZvciBhIExvY2F0aW9uIGJhc2VkIHNlcnZpY2Ug b3IgdW5kZXIgb25lIA0Kb2YNCnRoZSB0aHJlZSBwcm92aXNpb25zLiBUaGUgdXNlcidzIGxvY2F0 aW9uIGZhbGxpbmcgaW5hZHZlcnRlbnRseSBpbnRvIHRoZQ0Kd3JvbmcgaGFuZHMgaXMgYSBzZWN1 cml0eSB0aHJlYXQgdGhhdCB5b3UgZG8gbm90IG1lbnRpb24uIFRoaXMgbWVhbnMgdGhhdA0KVXNl cidzIGxvY2F0aW9uIGNhbm5vdCBiZSBoZWxkIG9uIGEgUHVibGljYWxseSBhY2Nlc3NpYmxlIGRp cmVjdG9yeQ0KZGF0YWJhc2UuIA0KDQpTZWNvbmRseSwgSSBoYXZlIG9uZSBxdWVzdGlvbiBhYm91 dCB0aGUgUmVxdWlyZW1lbnRzIGZvciBFbWVyZ2VuY3kgQ29udGV4dA0KUmVzb2x1dGlvbiB3aXRo IEludGVybmV0IFRlY2hub2xvZ2llcyBBdXRob3Iocyk6IEguIFNjaHVsenJpbm5lLCBSLiANCk1h cnNoYWxsDQpGaWxlbmFtZTogZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDIudHh0IG9u IFBhZ2UgMTYgQ2hhcHRlciA3IA0KTWFwcGluZw0KUHJvdG9jb2wgMXN0IFBhcmFncmFwaC4gVGhl IHNlbnRlbmNlIHN0YXRlcyB0aGF0IHRoZSAiUFNBUFMgb25seSBzZXJ2ZSBhDQpsaW1pdGVkIGdl b2dyYXBoaWMgcmVnaW9uLCAuLi4iIFRoaXMgaW4gbm90IFRydWUuIEl0IG1heSBiZSB0cnVlIGlu IHRoZSBVUw0KYW5kIEdlcm1hbnksIGJ1dCBpbiBtYW55IGNvdW50cmllcyB0aGUgUFNBUHMgbWF5 IHNlcnZlciBhIHdpZGUgYXJlYS4gVGhlDQpwcm9ibGVtIHdpbGwgYmUgc29sdmVkIGlmIHRoZSBX b3JkcyBhcmUgY2hhbmdlZCB0byAiUFNBUFMgbWF5IG9ubHkgc2VydmUgYQ0KbGltaXRlZCBnZW9n cmFwaGljIHJlZ2lvbiwgLi4uIiANCg0KSW4gU3VtbWFyeSANCg0KIlBTQVAgKFB1YmxpYyBTYWZl dHkgQW5zd2VyaW5nIFBvaW50KTogUGh5c2ljYWwgbG9jYXRpb24gd2hlcmUgZW1lcmdlbmN5DQpj YWxscyBhcmUgcmVjZWl2ZWQgdW5kZXIgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGEgcHVibGljIGF1 dGhvcml0eS4gIChUaGlzDQp0ZXJtaW5vbG9neSBpcyB1c2VkIGJ5IGJvdGggRVRTSSwgaW4gRVRT SSBTUiAwMDIgMTgwLCBhbmQgTkVOQS4pIiBUaGlzDQpkZWZpbml0aW9uIGZyb20gVGl0bGU6IFJl cXVpcmVtZW50cyBmb3IgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoDQpJbnRlcm5l dCBUZWNobm9sb2dpZXMgQXV0aG9yKHMpOiBILiBTY2h1bHpyaW5uZSwgUi4gTWFyc2hhbGwgRmls ZW5hbWU6DQpkcmFmdC1pZXRmLWVjcml0LXJlcXVpcmVtZW50cy0wMi50eHQgaXMgbm90IGNvcnJl Y3QgdGhlIFVTIHBlb3BsZSByZWFkIA0KRVRTSQ0KZG9jdW1lbnRzIHRob3VnaCBVUyBHbGFzc2Vz LiBUaGUgUFNBUCBpbiBFVFNJIFNSIDAwMiAxODAgaXMgbm90IHRoZSBzYW1lIA0KYXMNCnRoZSBQ U0FQIGluIE5FTkEsIHRoZSBFQ0MgaW4gU1IgMDAyIDE4MCBpcyB0aGUgUFNBUCBpbiBORU5BLCBh cyBNYXJjIA0KTGlzbmVyDQphbmQgTkVOQSBhcmUgdmVyeSBhd2FyZS4gSSdtIG5vdCBzdXJlIHRo YXQgdGhpcyBkZWZpbml0aW9uIGVycm9yIGFmZmVjdHMgDQp0aGUNCkludGVybmV0IGRyYWZ0IHZl cnkgbXVjaC4gQWxsIEkgdGhpbmsgdGhlc2UgSW50ZXJuZXQgZHJhZnRzIG5lZWQgdG8gDQpjb25j ZXJuDQppcyB0aGUgcm91dGluZyB0byBhIFBBU1AgZnVuY3Rpb24gT3V0c2lkZSB0aGUgVGVsZXBo b25lIG9yIElQIG5ldHdvcmsuIA0KDQpJbiBFVFNJIHRoZSBkZWZpbml0aW9uIG9mIFBTQVBzIGlz IHNwbGl0IGluIGludG8gdHdvIGZ1bmN0aW9ucywgdG8gY292ZXINCmRpZmZlcmVudCBuYXRpb25h bCBzaXR1YXRpb25zLCBQU0FQMSAob3IgdGhlIFBTQVApIHdoaWNoIGlzIHRoZSBmaXJzdCANCnN0 YWdlDQphY2Nlc3MgcG9pbnQgdG8gdGhlIEVtZXJnZW5jeSBzZXJ2aWNlcyBUaGlzIGlzIG5vdCBt ZW50aW9uZWQgaW4gdGhlIEktRC4NClNlY29uZGx5IHRoZSBQU0FQMiAob3IgRUNDIEVtZXJnZW5j eSBDb250cm9sIENlbnRyZSkgdGhlc2UgYXJlDQpnZW9ncmFwaGljYWxseSBsb2NhdGVkLiBUaGlz IGlzIHRoZSBVUyBQU0FQIGFuZCB0aGUgUFNBUCBtZW50aW9uZWQgaW4geW91cg0KZG9jdW1lbnQu IEluIHRoZSBVSyB0aGlzIGlzIEVPQUMsIGluIE5ldyBaZWFsYW5kIEVDQy4gSW4gR2VybWFueSB0 aGVzZQ0KRnVuY3Rpb25zIGFyZSBwaHlzaWNhbGx5IGNvbGxvY2F0ZWQuIA0KDQpJbiBTd2VkZW4g YW5kIHRoZSBVSyB0aGVyZSBhcmUgYSBzbWFsbCBudW1iZXIgb2YgUFNBUDEgb3IgKFBTQVAgDQpm dW5jdGlvbnMpLg0KRm9yIEV4YW1wbGUgQyZXIGFuZCBULU1vYmlsIHJvdXRlIGFsbCBVSyBFbWVy Z2VuY3kgY2FsbHMgdG8gT25lIFBTQVAuIFRoZQ0KT3RoZXIgVUsgT3BlcmF0b3JzIFJvdXRlIGFs bCBVSyBFbWVyZ2VuY3kgY2FsbHMgdG8gYSBzbWFsbCBudW1iZXIgb2YgUFNBUHMNCihtYW5hZ2Vk IGJ5IEJUKS4gVGhlc2UgbWF5IGJlIGdlb2dyYXBoaWNhbGx5IGRpc3RyaWJ1dGVkIGluIHRpbWVz IG9mIA0Kbm9ybWFsDQpvcGVyYXRpb24sIGhvd2V2ZXIgdGhleSBtYXkgYmUgbG9hZCBkaXN0cmli dXRlZCBpbiB0aW1lcyBvZiBzZXZlcmUgbG9hZCBvcg0KUFNBUCBmYWlsdXJlLiBBbGwgRW1lcmdl bmN5IENhbGxzIGluIFN3ZWRlbiBhcmUgcm91dGVkIHRvIGEgU21hbGwgbnVtYmVyIA0Kb2YNClBT QVBTIHJ1biBieSBhIE5hdGlvbmFsIEF1dGhvcmlzZWQgQ29tcGFueSBjYWxsZWQgIlNPUy1BbGFy bSIgVGhlc2UgYXJlIA0Kbm90DQpQU0FQcyBpbiB5b3VyIGRvY3VtZW50IGlmIEkgcmVhZCB5b3Vy IGRvY3VtZW50cyBjb3JyZWN0bHkuIFRoZXNlIFBTQVBzIA0Kcm91dGUNCnRoZSBFbWVyZ2VuY3kg b250byB0aGUgbW9zdCBhcHByb3ByaWF0ZSBDb250cm9sIG9yIEFzc2lzdGFuY2UgQ2VudHJlLCAN CkZpcmUsDQpQb2xpY2UsIEFtYnVsYW5jZSwgQ29hc3RndWFyZCwgQ2F2ZS9Nb3VudGFpbi9Gb3Jl c3QgcmVzY3VlLCBldGMuLi4gT25lDQpDb250cm9sIG9yIGFzc2lzdGFuY2UgQ2VudHJlIG1heSBk aXNwYXRjaCBzZXZlcmFsIEVtZXJnZW5jeSByZXNwb25kZXJzIHRvIA0KYW4NCmluY2lkZW50LiAN Cg0KSSB0aGluayB0aGUgb25lIHdvcmQgYWRkaXRpb24gb2YgIm1heSIgd2lsbCBhZGRyZXNzIHRo aXMgc3VmZmljaWVudGx5LiANCg0KSSBoYXZlIGRpc2N1c3NlZCB0aGlzIGxhc3QgcG9pbnQgd2l0 aCBIYW5uZXMgc2VlIGJlbG93OiANCg0KW2hhbm5lc10gaWYgd2UgY2FuIGRlYWwgd2l0aCB0aGlz IGlzc3VlIGJ5IGNoYW5naW5nIHRoZSBzZW50ZW5jZSBmcm9tDQoNCiJQU0FQIChQdWJsaWMgU2Fm ZXR5IEFuc3dlcmluZyBQb2ludCk6IFBoeXNpY2FsIGxvY2F0aW9uIHdoZXJlIGVtZXJnZW5jeQ0K Y2FsbHMgYXJlIHJlY2VpdmVkIHVuZGVyIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhIHB1YmxpYyBh dXRob3JpdHkuIg0KDQp0bw0KDQoiIlBTQVAgKFB1YmxpYyBTYWZldHkgQW5zd2VyaW5nIFBvaW50 KTogUGh5c2ljYWwgbG9jYXRpb24gd2hlcmUNCmVtZXJnZW5jeSBjYWxscyBtYXkgYmUgcmVjZWl2 ZWQgdW5kZXIgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGEgcHVibGljDQphdXRob3JpdHkuIg0KDQpb cmNmXSBhZ3JlZWQuIA0KDQoNClJlZ2FyZHMsDQoNClJheSBGb3JiZXMuDQoNCis0NCAyNCA3NjU2 IDMxMDYgcGhvbmUNCis0NCAyNCA3NjU2IDM4MTYgZmF4Lg0KKzQ0IDc3MSA4NTEgMTM2MSBNb2Jp bGUvdGV4dA0KLS0tLS0tLS0tLS0tDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwuICBJZiB5b3UgYXJlIG5vdCB0aGUNCmludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseSBlLW1haWwgYW5kIHRoZW4NCmRl bGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gRG8gbm90IGNvcHkgdGhpcyBlLW1h aWwgb3IgYW55DQphdHRhY2htZW50cywgdXNlIHRoZSBjb250ZW50cyBmb3IgYW55IHB1cnBvc2Us IG9yIGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0bw0KYW55IG90aGVyIHBlcnNvbjogdG8gZG8gc28g Y291bGQgYmUgYSBicmVhY2ggb2YgY29uZmlkZW5jZS4NCg0KDQoNCiJUc2Nob2ZlbmlnLCBIYW5u ZXMiIDxoYW5uZXMudHNjaG9mZW5pZ0BTSUVNRU5TLkNPTT4gDQpTZW50IGJ5OiAiZW10ZWwgOiBF bXRlbCIgPEVNVEVMQExJU1QuRVRTSS5PUkc+IA0KMDkvMDEvMjAwNiAyMjo0NyANClBsZWFzZSBy ZXNwb25kIHRvICJUc2Nob2ZlbmlnLCBIYW5uZXMiIA0KICAgICAgICANCiAgICAgICAgVG86ICAg ICAgICBFTVRFTEBMSVNULkVUU0kuT1JHIA0KICAgICAgICBjYzogICAgICAgICANCiAgICAgICAg U3ViamVjdDogICAgICAgIFtFTVRFTF0gSS1EDQpBQ1RJT046ZHJhZnQtaWV0Zi1lY3JpdC1yZXF1 aXJlbWVudHMtMDIudHh0DQoNCg0KDQpoaSBhbGwsDQoNCmEgbmV3IHZlcnNpb24gb2Ygb3VyIHJl cXVpcmVtZW50cyBkb2N1bWVudCBpcyBhdmFpbGFibGUuIHBsZWFzZSBzZW5kDQpyZXZpZXcgY29t bWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCAoc2VlDQpodHRwOi8vd3d3LmlldGYub3JnL2h0bWwu Y2hhcnRlcnMvZWNyaXQtY2hhcnRlci5odG1sKS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpUaXRsZSAgICAgICAgICAgICAgICA6IFJlcXVpcmVtZW50cyBmb3IgRW1lcmdlbmN5IENv bnRleHQgUmVzb2x1dGlvbg0Kd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgDQpBdXRob3Iocykg ICAgICAgIDogSC4gU2NodWx6cmlubmUsIFIuIE1hcnNoYWxsDQpGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWVjcml0LXJlcXVpcmVtZW50cy0wMi50eHQNClBhZ2VzICAgICAgICAgICAgICAg IDogMjcNCkRhdGUgICAgICAgICAgICAgICAgOiAyMDA2LTEtMyANCg0KVGhpcyBkb2N1bWVudCBl bnVtZXJhdGVzIHJlcXVpcmVtZW50cyBmb3IgZW1lcmdlbmN5IGNhbGxzIHBsYWNlZCBieQ0KdGhl IHB1YmxpYyB1c2luZyB2b2ljZS1vdmVyLUlQIChWb0lQKSBhbmQgZ2VuZXJhbCBJbnRlcm5ldCBt dWx0aW1lZGlhDQpzeXN0ZW1zLCB3aGVyZSBJbnRlcm5ldCBwcm90b2NvbHMgYXJlIHVzZWQgZW5k LXRvLWVuZC4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVjcml0LXJlcXVpcmVtZW50cy0w Mi50eHQNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KY2lhbw0KaGFubmVzDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCk1haWwgYXJjaGl2ZSBmb3IgRU1URUwgY2FuIGJlIGJyb3dzZWQgYXQgdGhl IGZvbGxvd2luZyB1cmw6IA0KaHR0cDovL2xpc3QuZXRzaS5vcmcvRU1URUwuaHRtbA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSANCg0KDQoNCg== --=_alternative 0031A339802570FF_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJyaWFuLDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSA8Yj5uZXZlcjwvYj4gcHJvcG9z ZWQgdG8gcmVtb3ZlIHRoZQ0Kd29yZCAmcXVvdDtsaW1pdGVkJnF1b3Q7LCBjbGVhcmx5IGEgUFNB UCAod2hhdGV2ZXIgZGVmaW5pdGlvbiB3ZSB1c2UpIGlzDQpuYXRpb25hbCwgSSBvbmx5IHByb3Bv c2VkIHRvIGFkZCB0aGUgd29yZCAmcXVvdDttYXkmcXVvdDsgYXMgYSBQU0FQIG1heQ0KYmUgbmF0 aW9uYWwsIG5vdCBsaW1pdGVkIHRvIGEgZ2VvZ3JhcGhpYyByZWdpb24gd2l0aGluIGEgY291bnRy eS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgPGI+ bmV2ZXI8L2I+IHByb3Bvc2VkIHRvIGNoYW5nZSB0aGUNCmRlZmluaXRpb24gb2YgUFNBUCwganVz dCB0byB1bmRlcnN0YW5kIHRoYXQgd2UgcmVhZCB0aGUgd29yZHMgZGlmZmVyZW50bHkuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGRvIHByb3Bvc2Ug dG8gZGVsZXRlIHRoZSBub3RlLCBhcw0KeW91IGFncmVlLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBzdXJlIHRoYXQgd2UgY2FuIGZpbmQgcm9v bSBmb3INCmNvbW1vbiBhZ3JlZW1lbnQuIE9uIHRoZSB0d28gcG9pbnRzIHRoYXQgSSBwcm9wb3Nl PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRz LDxicj4NCjxicj4NClJheSBGb3JiZXMuPGJyPg0KPGJyPg0KKzQ0IDI0IDc2NTYgMzEwNiBwaG9u ZTxicj4NCis0NCAyNCA3NjU2IDM4MTYgZmF4Ljxicj4NCis0NCA3NzEgODUxIDEzNjEgTW9iaWxl L3RleHQ8YnI+DQotLS0tLS0tLS0tLS08YnI+DQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwuICZuYnNwO0lmIHlvdSBhcmUgbm90DQp0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJlcGx5IGUtbWFpbCBh bmQNCnRoZW4gZGVsZXRlIHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBEbyBub3QgY29w eSB0aGlzIGUtbWFpbCBvciBhbnkNCmF0dGFjaG1lbnRzLCB1c2UgdGhlIGNvbnRlbnRzIGZvciBh bnkgcHVycG9zZSwgb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnRzDQp0byBhbnkgb3RoZXIgcGVyc29u OiB0byBkbyBzbyBjb3VsZCBiZSBhIGJyZWFjaCBvZiBjb25maWRlbmNlLjxicj4NCjwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0JyaWFuIFJv c2VuJnF1b3Q7ICZsdDtickBicmlhbnJvc2VuLm5ldCZndDs8L2I+PC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwLzAxLzIwMDYgMTY6MzY8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSByZXNwb25kIHRvIGJyPC9mb250Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRvOg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7J1Jh eW1vbmQgRm9yYmVzJyZxdW90OyAmbHQ7cmF5bW9uZC5mb3JiZXNAbWFyY29uaS5jb20mZ3Q7LA0K Jmx0O2Vjcml0QGlldGYub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNjOg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3ViamVjdDoNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1JFOiBbRWNyaXRdIEZ3OiBbRU1URUxdIEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1lY3Jp dC1yZXF1aXJlbWVudHMtMDIudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD5SYXk8YnI+DQo8YnI+DQpXZSBmb2N1cyBvbiBiZWluZyB0ZXJtaW5hbCBj ZW50cmljIGJlY2F1c2UgaW4gbWFueSBjYXNlcyB0aGUgYWNjZXNzIG5ldHdvcms8YnI+DQpwcm92 aWRlciwgd2hpY2ggaXMgdGhlIG9ubHkgY2FycmllciB0aGF0IGtub3dzIHdoZXJlIHRoZSB0ZXJt aW5hbCBpcywgaXMNCm5vdDxicj4NCnRoZSBDU1AuICZuYnNwO1RoZSBDU1AgbWF5IGJlIGluIGEg ZGlmZmVyZW50IGNvdW50cnkgYW5kIG5vdCBzdWJqZWN0IHRvDQpsYXdzPGJyPg0Kd2hlcmUgdGhl IHRlcm1pbmFsIGlzLCBldmVuIHRob3VnaCBpdCBpcyBwcm92aWRpbmcgdGVsZXBob255IHNlcnZp Y2VzIHRvDQppdC48YnI+DQpUaGUgbGVnYWwgc3RhdHVzIGlzIG5vdCB0aGUgaW1wb3J0YW50IHBh cnQ7IGl0IGlzIHRoZSBmYWN0IHRoYXQgdGhlIENTUDxicj4NCmRvZXNu4oCZdCBrbm93IHdoZXJl IHRoZSB0ZXJtaW5hbCBpcy4gJm5ic3A7VGhlIHRlcm1pbmFsIGhvd2V2ZXIsIGlzIGJlaW5nDQpw cm92aWRlZDxicj4NCnBhY2tldCBzZXJ2aWNlIGJ5IHRoZSBhY2Nlc3MgbmV0d29yaywgYW5kIGlz IHRoZSBwb2ludCB3aGVyZSB0aGUgc3Vic2NyaWJlcjxicj4NCnRvIHRoZSBhY2Nlc3MgbmV0d29y ayBtZWV0cyB0aGUgc3Vic2NyaWJlciB0byB0aGUgQ1NQLiAmbmJzcDtUaGF0IGlzIHdoeQ0Kd2Ug Zm9jdXM8YnI+DQpvbiB0aGUgdGVybWluYWwg4oCTIGJlY2F1c2UgdGhlIGFjY2VzcyBuZXR3b3Jr IGNhbiBzdXBwbHkgbG9jYXRpb24gdG8gdGhlPGJyPg0KdGVybWluYWwsIGFuZCB0aGUgdGVybWlu YWwgY2FuIHN1cHBseSBsb2NhdGlvbiB0byB0aGUgQ1NQLiAmbmJzcDtBdHRlbXB0aW5nDQp0bzxi cj4NCnBhc3MgaW5mb3JtYXRpb24gYmV0d2VlbiB0aGUgYWNjZXNzIG5ldHdvcmsgYW5kIHRoZSBD U1AgaXMgZnJhdWdodCB3aXRoPGJyPg0KZGlmZmljdWx0eSwgdGhlIG1vc3Qgc2V2ZXJlIG9mIHdo aWNoIGlzIGlkZW50aWZpZXJzID0gaG93IHRoZSBhY2Nlc3MgbmV0d29yazxicj4NCmNvdWxkIGlk ZW50aWZ5IHRoZSBDU1Agc3Vic2NyaWJlci48YnI+DQo8YnI+DQpXZSBoYXZlIHNvbWUgdGVybWlu b2xvZ3kgaXNzdWVzLCBiZWNhdXNlIHdlIGFyZSB1c2luZyB0aGUgdGVybSDigJxWYWxpZOKAnQ0K dG88YnI+DQptZWFuIHRoYXQgdGhlIGxvY2F0aW9uIGlzIG9uZSByZWNvZ25pemVkIGJ5IHRoZSBw dWJsaWMgc2FmZXR5IGFnZW5jaWVzDQphcyBhPGJyPg0KbG9jYXRpb24gdGhleSBrbm93IGhvdyB0 byBzZW5kIHJlc3BvbmRlcnMuICZuYnNwO1ZhbGlkYXRlZCB0aHVzIG1lYW5zIHdlDQpoYXZlPGJy Pg0KdGFrZW4gc3RlcHMgdG8gYXNzdXJlIHRoYXQgdGhlIGxvY2F0aW9uIGlzIGEgdmFsaWQgb25l LiAmbmJzcDtQcm90ZWN0aW5nDQp0aGU8YnI+DQppbmZvcm1hdGlvbiBmcm9tIGZvcmdlcnkgb3Ig bW9kaWZpY2F0aW9uIGlzIGEgZGlmZmVyZW50IGlzc3VlIHdoaWNoIGlzDQphbHNvPGJyPg0KaW1w b3J0YW50IHRvIHVzLjxicj4NCjxicj4NCkkgaGF2ZSBubyBwcm9ibGVtIHJlbW92aW5nIHRoZSBO b3RlIGluIHRoZSBzZWN1cml0eSB0aHJlYXRzIGRvY3VtZW50Ljxicj4NCjxicj4NCkhvd2V2ZXIs IEkgZG8gaGF2ZSBhIHByb2JsZW0gd2l0aCByZW1vdmluZyB0aGUgd29yZCDigJxsaW1pdGVk4oCd IGluIHRoZTxicj4NCmdlb2dyYXBoaWMgY292ZXJhZ2Ugb2YgYSBQU0FQLiAmbmJzcDtFdmVuIGlm IG9uZSBQU0FQIHNlcnZlcyB0aGUgZW50aXJlDQpjb3VudHJ5LDxicj4NCml0cyBzZXJ2aWNlIGJv dW5kYXJ5IGlzIGxpbWl0ZWQgdG8gdGhhdCBjb3VudHJ5LiAmbmJzcDtTbyBJIHRoaW5rIHRoZSBy ZXF1aXJlbWVudDxicj4NCmlzIHByb3Blcmx5IHN0YXRlZC4gJm5ic3A7SSB3b3VsZCBub3Qgb3Bw b3NlIGFkZGluZyBzb21lIGNsYXJpZmljYXRpb24NCijigJxhbHRob3VnaDxicj4NCnRoYXQgcmVn aW9uIG1heSBiZSBhcyBsYXJnZSBhcyBhbiBlbnRpcmUgY291bnRyeeKAnSksIGJ1dCBJIGRvbuKA mXQgcmVhbGx5DQp0aGluazxicj4NCml0IGlzIG5lZWRlZC48YnI+DQo8YnI+DQpBbHRob3VnaCBJ IGRvbuKAmXQgaGF2ZSBhIGJpZyBwcm9ibGVtIHdpdGggdGhlIGNoYW5nZSB0byB0aGUgUFNBUCBk ZWZpbml0aW9uLDxicj4NCkkgZG8gd29uZGVyIGlmIHdlIHdvdWxkIGJlIGJldHRlciBvZmYgY2hh bmdpbmcgdGhlIGRlZmluaXRpb24gdG8gc2F5IHRoYXQ8YnI+DQp0aGUgUFNBUCBpcyB3aGVyZSB0 aGUgY2FsbCBpcyBmaXJzdCBhbnN3ZXJlZC48YnI+DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpGcm9tOiBl Y3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQpPZjxicj4NClJheW1vbmQgRm9yYmVzPGJyPg0KU2VudDogRnJpZGF5LCBKYW51YXJ5 IDIwLCAyMDA2IDg6MTcgQU08YnI+DQpUbzogZWNyaXRAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBb RWNyaXRdIEZ3OiBbRU1URUxdIEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVu dHMtMDIudHh0PGJyPg0KPGJyPg0KPGJyPg0KRWNyaXQgZGVsZWdhdGVzLCA8YnI+DQo8YnI+DQpJ IHJlYWQgeW91ciBJLURzIHdpdGggaW50ZXJlc3QuIFRoYW5rIHlvdS4gPGJyPg0KPGJyPg0KSSB3 YXMgc2xpZ2h0bHkgY29uY2VybmVkIHRoYXQgdGhleSBzZWFtIHRvIGJlIHZlcnkgdGVybWluYWwg Y2VudHJpYyBpbg0KdGVybXM8YnI+DQpvZiBMb2NhdGlvbiBwcm92aXNpb24uIDxicj4NCjxicj4N ClRoZSBEaXNjdXNzaW9ucyBpbiBFVFNJIGFuZCB0aGUgRUNDIGhhdmUgZm9jdXNlZCBvbiBWYWxp ZGF0ZWQgTG9jYXRpb24sPGJyPg0KVmFsaWRhdGVkIGJ5IHRoZSBuZXR3b3JrIG9yIFByb3ZpZGVk IHdpdGhpbiB0aGUgbmV0d29yayBieSBhIHNlY3VyZTxicj4NCmRhdGFiYXNlLiBXaGF0IHRoZSBW YWxpZGF0aW9uIG1lYW5zIHRvIHRoZSBFVSBpcyB0aGF0IHRoZSBMb2NhdGlvbiBvbjxicj4NCmF1 dGhlbnRpY2F0ZWQgYmVmb3JlIGl0IHJlYWNoZXMgdGhlIEVtZXJnZW5jeSBTZXJ2aWNlcyB1c3Vh bGx5IGJ5IHRoZSBDU1A8YnI+DQooY29tbXVuaWNhdGlvbiBTZXJ2aWNlIFByb3ZpZGVyKS4gTm90 IHRoYXQgaXQgaXMgYSB2YWxpZCBhZGRyZXNzIG9yIGxvY2F0aW9uPGJyPg0Kd2hpY2ggaXMgdGhl IGVjcml0IGRlZmluaXRpb24gb2YgdmFsaWRhdGlvbjsgYm90aCBjb25jZXB0cyBoYXZlIHZhbGlk aXR5Lg0KPGJyPg0KPGJyPg0KRVRTSSBUUyAxMDIgMTY0IEFzc3VtZXMgdGhhdCBoZSBSb3V0aW5n IHRvd2FyZCB0aGUgUFNBUCBpcyBnZW5lcmF0ZWQgYnkNCnRoZTxicj4NCkNMSTsgYW5kIGluIEVU U0kgVElTUEFOIE5HTiB0aGF0IHRoZSBTSVAgcm91dGluZyB0b3dhcmQgdGhlIFBTQVAgd2lsbCBi ZTxicj4NCmZyb20gQXNzZXJ0ZWQgSWRlbnRpdHkgSW5mb3JtYXRpb24gYWRkZWQgb2YgdmFsaWRh dGVkIGJ5IHRoZSBFU1JQOyBUaGlzDQppczxicj4NCmFuIG9wdGlvbiBhbGxvd2VkIGluIFRpdGxl OiBSZXF1aXJlbWVudHMgZm9yIEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb248YnI+DQp3aXRo IEludGVybmV0IFRlY2hub2xvZ2llcyBBdXRob3Iocyk6IEguIFNjaHVsenJpbm5lLCBSLiBNYXJz aGFsbCA8YnI+DQpGaWxlbmFtZTogZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDIudHh0 PGJyPg0KPGJyPg0KUmVhbCBHZW9ncmFwaGljIG1hcHBpbmcgaW4gdGhlIFRTIDEwMiAxNjQgaXMg Y2FsY3VsYXRlZCB3aXRoaW4gdGhlIFBTQVANCmJ5PGJyPg0Kc2VjdXJlIGxvb2sgdXAgaW50byB0 aGUgb3BlcmF0b3JzICZxdW90O2RpcmVjdG9yeSZxdW90OyBkYXRhYmFzZXMgKGJ5IGENClByaXZh dGU8YnI+DQpzZXJ2aWNlIElQIGxpbmspLiBUaGUgRVUgaGFzIHNwZWNpYWwgcHJvdmlzaW9uIHRv IGFsbG93IGFuZCByZXF1aXJlIHRoaXM8YnI+DQp3aXRoIHRoZSBFVSBkYXRhIHByb3RlY3Rpb24g RGlyZWN0aXZlLiBUaGlzIGlzIG5vdCBtZW50aW9uZWQsIGJ1dCBkb2VzDQpub3Q8YnI+DQpuZWVk IHRvIGJlIG1lbnRpb25lZC4gSXQgaXMgYWxtb3N0IHRoZSBzYW1lIGFzIHRoZSBjYXNlICg4KSwg YWNxdWlzaXRpb24NCm9mPGJyPg0KTG9jYXRpb24gSW5mb3JtYXRpb24gYnkgYSBDYWxsIFJvdXRp bmcgRW50aXR5IGluIFRpdGxlOiBTZWN1cml0eSBUaHJlYXRzDQphbmQ8YnI+DQpSZXF1aXJlbWVu dHMgZm9yIEVtZXJnZW5jeSBDYWxsaW5nIEF1dGhvcihzKTogSC4gU2NodWx6cmlubmUsIGV0IGFs Ljxicj4NCkZpbGVuYW1lOiBkcmFmdC10YXlsb3ItZWNyaXQtc2VjdXJpdHktdGhyZWF0cy0wMS50 eHQgd2hlcmUgaW4gY2hhcHRlciA2Ljg8YnI+DQpSZXF1aXJlbWVudHMgZm9yIEludGVyZmFjZSAu IDxicj4NCjxicj4NCkZpcnN0bHksIFNlY3VyaXR5IFRocmVhdHMgYW5kIFJlcXVpcmVtZW50cyBm b3IgRW1lcmdlbmN5IENhbGxpbmc8YnI+DQpkcmFmdC10YXlsb3ItZWNyaXQtc2VjdXJpdHktdGhy ZWF0cy0wMS50eHQgb24gUGFnZSA2IHBvaW50IDMuIFRoZSBOb3RlDQppczxicj4NCm5vdCBiZSB0 cnVlIGFjY29yZGluZyB0byBFdXJvcGVhbiBEaXJlY3RpdmUgYW5kIEV1cm9wZS13aWRlIGxhd3Mu IFRoZSBFVTxicj4NCmRhdGEgcHJvdGVjdGlvbiBkaXJlY3RpdmUgc3RhdGVzIHRoYXQgTG9jYXRp b24gaXMgUHJpdmF0ZSBkYXRhIHRvIHRoZSB1c2VyPGJyPg0KdGhhdCBtdXN0IGJlIHNlY3VyZWQg dW5kZXIgdGhlIHVzZXIncyByaWdodCB0byByZXZlYWwsIHdpdGhzdGFuZGluZyB0aGU8YnI+DQp0 aHJlZSB2ZXJ5IGNsZWFyIGxlZ2FsIGV4Y2VwdGlvbnM6IHdoaWNoIGFyZSAxLiBOYXRpb25hbCBT ZWN1cml0eTsgMi48YnI+DQpDcmltaW5hbCBBY3Rpdml0eSBhbmQgMy4gbWFraW5nIGFuIEVtZXJn ZW5jeSBjYWxsIG9yIFJlcXVlc3QgdG8gdGhlPGJyPg0KRW1lcmdlbmN5IHNlcnZpY2VzLiBUaGVz ZSBBdXRob3JpdHkgbXVzdCBsZWdhbGx5IHJlc3BlY3QgdGhlIHJpZ2h0cyBvZg0KdGhlPGJyPg0K VXNlciBub3QgdG8gcmV2ZWFsIHRoZSBsb2NhdGlvbiB0byB0aGlyZCBwYXJ0aWVzIGFuZCBjb21t ZXJjaWFsPGJyPg0Kb3JnYW5pc2F0aW9ucy4gSSBzdWdnZXN0IHRoYXQgeW91IGRlbGV0ZSB0aGUg bm90ZS4gRVUgRGlyZWN0aXZlcyBhbmQ8YnI+DQpFdXJvcGVhbi13aWRlIGxhdyBjb3ZlcnMgYXQg bGVhc3QgMzAgY291bnRyaWVzLiBVbmRlciBFVSBEaXJlY3RpdmVzIHRoZTxicj4NClVzZXIncyBM b2NhdGlvbiBpcyBQcml2YXRlIGRhdGEgdGhhdCBjYW5ub3QgYmUgcmV2ZWFsZWQgZXhjZXB0IG9u IHRoZTxicj4NCmNvbW1lcmNpYWwgcmVxdWVzdCBvZiB0aGUgVXNlciBmb3IgYSBMb2NhdGlvbiBi YXNlZCBzZXJ2aWNlIG9yIHVuZGVyIG9uZQ0Kb2Y8YnI+DQp0aGUgdGhyZWUgcHJvdmlzaW9ucy4g VGhlIHVzZXIncyBsb2NhdGlvbiBmYWxsaW5nIGluYWR2ZXJ0ZW50bHkgaW50byB0aGU8YnI+DQp3 cm9uZyBoYW5kcyBpcyBhIHNlY3VyaXR5IHRocmVhdCB0aGF0IHlvdSBkbyBub3QgbWVudGlvbi4g VGhpcyBtZWFucyB0aGF0PGJyPg0KVXNlcidzIGxvY2F0aW9uIGNhbm5vdCBiZSBoZWxkIG9uIGEg UHVibGljYWxseSBhY2Nlc3NpYmxlIGRpcmVjdG9yeTxicj4NCmRhdGFiYXNlLiA8YnI+DQo8YnI+ DQpTZWNvbmRseSwgSSBoYXZlIG9uZSBxdWVzdGlvbiBhYm91dCB0aGUgUmVxdWlyZW1lbnRzIGZv ciBFbWVyZ2VuY3kgQ29udGV4dDxicj4NClJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9s b2dpZXMgQXV0aG9yKHMpOiBILiBTY2h1bHpyaW5uZSwgUi4gTWFyc2hhbGw8YnI+DQpGaWxlbmFt ZTogZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDIudHh0IG9uIFBhZ2UgMTYgQ2hhcHRl ciA3IE1hcHBpbmc8YnI+DQpQcm90b2NvbCAxc3QgUGFyYWdyYXBoLiBUaGUgc2VudGVuY2Ugc3Rh dGVzIHRoYXQgdGhlICZxdW90O1BTQVBTIG9ubHkgc2VydmUNCmE8YnI+DQpsaW1pdGVkIGdlb2dy YXBoaWMgcmVnaW9uLCAuLi4mcXVvdDsgVGhpcyBpbiBub3QgVHJ1ZS4gSXQgbWF5IGJlIHRydWUg aW4NCnRoZSBVUzxicj4NCmFuZCBHZXJtYW55LCBidXQgaW4gbWFueSBjb3VudHJpZXMgdGhlIFBT QVBzIG1heSBzZXJ2ZXIgYSB3aWRlIGFyZWEuIFRoZTxicj4NCnByb2JsZW0gd2lsbCBiZSBzb2x2 ZWQgaWYgdGhlIFdvcmRzIGFyZSBjaGFuZ2VkIHRvICZxdW90O1BTQVBTIG1heSBvbmx5DQpzZXJ2 ZSBhPGJyPg0KbGltaXRlZCBnZW9ncmFwaGljIHJlZ2lvbiwgLi4uJnF1b3Q7IDxicj4NCjxicj4N CkluIFN1bW1hcnkgPGJyPg0KPGJyPg0KJnF1b3Q7UFNBUCAoUHVibGljIFNhZmV0eSBBbnN3ZXJp bmcgUG9pbnQpOiBQaHlzaWNhbCBsb2NhdGlvbiB3aGVyZSBlbWVyZ2VuY3k8YnI+DQpjYWxscyBh cmUgcmVjZWl2ZWQgdW5kZXIgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGEgcHVibGljIGF1dGhvcml0 eS4gJm5ic3A7KFRoaXM8YnI+DQp0ZXJtaW5vbG9neSBpcyB1c2VkIGJ5IGJvdGggRVRTSSwgaW4g RVRTSSBTUiAwMDIgMTgwLCBhbmQgTkVOQS4pJnF1b3Q7DQpUaGlzPGJyPg0KZGVmaW5pdGlvbiBm cm9tIFRpdGxlOiBSZXF1aXJlbWVudHMgZm9yIEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24g d2l0aDxicj4NCkludGVybmV0IFRlY2hub2xvZ2llcyBBdXRob3Iocyk6IEguIFNjaHVsenJpbm5l LCBSLiBNYXJzaGFsbCBGaWxlbmFtZTo8YnI+DQpkcmFmdC1pZXRmLWVjcml0LXJlcXVpcmVtZW50 cy0wMi50eHQgaXMgbm90IGNvcnJlY3QgdGhlIFVTIHBlb3BsZSByZWFkDQpFVFNJPGJyPg0KZG9j dW1lbnRzIHRob3VnaCBVUyBHbGFzc2VzLiBUaGUgUFNBUCBpbiBFVFNJIFNSIDAwMiAxODAgaXMg bm90IHRoZSBzYW1lDQphczxicj4NCnRoZSBQU0FQIGluIE5FTkEsIHRoZSBFQ0MgaW4gU1IgMDAy IDE4MCBpcyB0aGUgUFNBUCBpbiBORU5BLCBhcyBNYXJjIExpc25lcjxicj4NCmFuZCBORU5BIGFy ZSB2ZXJ5IGF3YXJlLiBJJ20gbm90IHN1cmUgdGhhdCB0aGlzIGRlZmluaXRpb24gZXJyb3IgYWZm ZWN0cw0KdGhlPGJyPg0KSW50ZXJuZXQgZHJhZnQgdmVyeSBtdWNoLiBBbGwgSSB0aGluayB0aGVz ZSBJbnRlcm5ldCBkcmFmdHMgbmVlZCB0byBjb25jZXJuPGJyPg0KaXMgdGhlIHJvdXRpbmcgdG8g YSBQQVNQIGZ1bmN0aW9uIE91dHNpZGUgdGhlIFRlbGVwaG9uZSBvciBJUCBuZXR3b3JrLg0KPGJy Pg0KPGJyPg0KSW4gRVRTSSB0aGUgZGVmaW5pdGlvbiBvZiBQU0FQcyBpcyBzcGxpdCBpbiBpbnRv IHR3byBmdW5jdGlvbnMsIHRvIGNvdmVyPGJyPg0KZGlmZmVyZW50IG5hdGlvbmFsIHNpdHVhdGlv bnMsIFBTQVAxIChvciB0aGUgUFNBUCkgd2hpY2ggaXMgdGhlIGZpcnN0IHN0YWdlPGJyPg0KYWNj ZXNzIHBvaW50IHRvIHRoZSBFbWVyZ2VuY3kgc2VydmljZXMgVGhpcyBpcyBub3QgbWVudGlvbmVk IGluIHRoZSBJLUQuPGJyPg0KU2Vjb25kbHkgdGhlIFBTQVAyIChvciBFQ0MgRW1lcmdlbmN5IENv bnRyb2wgQ2VudHJlKSB0aGVzZSBhcmU8YnI+DQpnZW9ncmFwaGljYWxseSBsb2NhdGVkLiBUaGlz IGlzIHRoZSBVUyBQU0FQIGFuZCB0aGUgUFNBUCBtZW50aW9uZWQgaW4geW91cjxicj4NCmRvY3Vt ZW50LiBJbiB0aGUgVUsgdGhpcyBpcyBFT0FDLCBpbiBOZXcgWmVhbGFuZCBFQ0MuIEluIEdlcm1h bnkgdGhlc2U8YnI+DQpGdW5jdGlvbnMgYXJlIHBoeXNpY2FsbHkgY29sbG9jYXRlZC4gPGJyPg0K PGJyPg0KSW4gU3dlZGVuIGFuZCB0aGUgVUsgdGhlcmUgYXJlIGEgc21hbGwgbnVtYmVyIG9mIFBT QVAxIG9yIChQU0FQIGZ1bmN0aW9ucykuPGJyPg0KRm9yIEV4YW1wbGUgQyZhbXA7VyBhbmQgVC1N b2JpbCByb3V0ZSBhbGwgVUsgRW1lcmdlbmN5IGNhbGxzIHRvIE9uZSBQU0FQLg0KVGhlPGJyPg0K T3RoZXIgVUsgT3BlcmF0b3JzIFJvdXRlIGFsbCBVSyBFbWVyZ2VuY3kgY2FsbHMgdG8gYSBzbWFs bCBudW1iZXIgb2YgUFNBUHM8YnI+DQoobWFuYWdlZCBieSBCVCkuIFRoZXNlIG1heSBiZSBnZW9n cmFwaGljYWxseSBkaXN0cmlidXRlZCBpbiB0aW1lcyBvZiBub3JtYWw8YnI+DQpvcGVyYXRpb24s IGhvd2V2ZXIgdGhleSBtYXkgYmUgbG9hZCBkaXN0cmlidXRlZCBpbiB0aW1lcyBvZiBzZXZlcmUg bG9hZA0Kb3I8YnI+DQpQU0FQIGZhaWx1cmUuIEFsbCBFbWVyZ2VuY3kgQ2FsbHMgaW4gU3dlZGVu IGFyZSByb3V0ZWQgdG8gYSBTbWFsbCBudW1iZXINCm9mPGJyPg0KUFNBUFMgcnVuIGJ5IGEgTmF0 aW9uYWwgQXV0aG9yaXNlZCBDb21wYW55IGNhbGxlZCAmcXVvdDtTT1MtQWxhcm0mcXVvdDsNClRo ZXNlIGFyZSBub3Q8YnI+DQpQU0FQcyBpbiB5b3VyIGRvY3VtZW50IGlmIEkgcmVhZCB5b3VyIGRv Y3VtZW50cyBjb3JyZWN0bHkuIFRoZXNlIFBTQVBzDQpyb3V0ZTxicj4NCnRoZSBFbWVyZ2VuY3kg b250byB0aGUgbW9zdCBhcHByb3ByaWF0ZSBDb250cm9sIG9yIEFzc2lzdGFuY2UgQ2VudHJlLCBG aXJlLDxicj4NClBvbGljZSwgQW1idWxhbmNlLCBDb2FzdGd1YXJkLCBDYXZlL01vdW50YWluL0Zv cmVzdCByZXNjdWUsIGV0Yy4uLiBPbmU8YnI+DQpDb250cm9sIG9yIGFzc2lzdGFuY2UgQ2VudHJl IG1heSBkaXNwYXRjaCBzZXZlcmFsIEVtZXJnZW5jeSByZXNwb25kZXJzDQp0byBhbjxicj4NCmlu Y2lkZW50LiA8YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSBvbmUgd29yZCBhZGRpdGlvbiBvZiAmcXVv dDttYXkmcXVvdDsgd2lsbCBhZGRyZXNzIHRoaXMgc3VmZmljaWVudGx5Lg0KPGJyPg0KPGJyPg0K SSBoYXZlIGRpc2N1c3NlZCB0aGlzIGxhc3QgcG9pbnQgd2l0aCBIYW5uZXMgc2VlIGJlbG93OiA8 YnI+DQo8YnI+DQpbaGFubmVzXSBpZiB3ZSBjYW4gZGVhbCB3aXRoIHRoaXMgaXNzdWUgYnkgY2hh bmdpbmcgdGhlIHNlbnRlbmNlIGZyb208YnI+DQo8YnI+DQomcXVvdDtQU0FQIChQdWJsaWMgU2Fm ZXR5IEFuc3dlcmluZyBQb2ludCk6IFBoeXNpY2FsIGxvY2F0aW9uIHdoZXJlIGVtZXJnZW5jeTxi cj4NCmNhbGxzIGFyZSByZWNlaXZlZCB1bmRlciB0aGUgcmVzcG9uc2liaWxpdHkgb2YgYSBwdWJs aWMgYXV0aG9yaXR5LiZxdW90Ozxicj4NCjxicj4NCnRvPGJyPg0KPGJyPg0KJnF1b3Q7JnF1b3Q7 UFNBUCAoUHVibGljIFNhZmV0eSBBbnN3ZXJpbmcgUG9pbnQpOiBQaHlzaWNhbCBsb2NhdGlvbiB3 aGVyZTxicj4NCmVtZXJnZW5jeSBjYWxscyBtYXkgYmUgcmVjZWl2ZWQgdW5kZXIgdGhlIHJlc3Bv bnNpYmlsaXR5IG9mIGEgcHVibGljPGJyPg0KYXV0aG9yaXR5LiZxdW90Ozxicj4NCjxicj4NClty Y2ZdIGFncmVlZC4gPGJyPg0KPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpSYXkgRm9y YmVzLjxicj4NCjxicj4NCis0NCAyNCA3NjU2IDMxMDYgcGhvbmU8YnI+DQorNDQgMjQgNzY1NiAz ODE2IGZheC48YnI+DQorNDQgNzcxIDg1MSAxMzYxIE1vYmlsZS90ZXh0PGJyPg0KLS0tLS0tLS0t LS0tPGJyPg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs LiAmbmJzcDtJZiB5b3UgYXJlIG5vdA0KdGhlPGJyPg0KaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJlcGx5IGUtbWFpbCBhbmQgdGhlbjxicj4NCmRl bGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gRG8gbm90IGNvcHkgdGhpcyBlLW1h aWwgb3IgYW55PGJyPg0KYXR0YWNobWVudHMsIHVzZSB0aGUgY29udGVudHMgZm9yIGFueSBwdXJw b3NlLCBvciBkaXNjbG9zZSB0aGUgY29udGVudHMNCnRvPGJyPg0KYW55IG90aGVyIHBlcnNvbjog dG8gZG8gc28gY291bGQgYmUgYSBicmVhY2ggb2YgY29uZmlkZW5jZS48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQomcXVvdDtUc2Nob2ZlbmlnLCBIYW5uZXMmcXVvdDsgJmx0O2hhbm5lcy50c2Nob2Zl bmlnQFNJRU1FTlMuQ09NJmd0OyA8YnI+DQpTZW50IGJ5OiAmcXVvdDtlbXRlbCA6IEVtdGVsJnF1 b3Q7ICZsdDtFTVRFTEBMSVNULkVUU0kuT1JHJmd0OyA8YnI+DQowOS8wMS8yMDA2IDIyOjQ3IDxi cj4NClBsZWFzZSByZXNwb25kIHRvICZxdW90O1RzY2hvZmVuaWcsIEhhbm5lcyZxdW90OyA8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFTVRFTEBMSVNULkVUU0kuT1JH DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2M6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3ViamVjdDogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0VNVEVMXQ0KSS1EPGJyPg0KQUNUSU9OOmRyYWZ0LWll dGYtZWNyaXQtcmVxdWlyZW1lbnRzLTAyLnR4dDxicj4NCjxicj4NCjxicj4NCjxicj4NCmhpIGFs bCw8YnI+DQo8YnI+DQphIG5ldyB2ZXJzaW9uIG9mIG91ciByZXF1aXJlbWVudHMgZG9jdW1lbnQg aXMgYXZhaWxhYmxlLiBwbGVhc2Ugc2VuZDxicj4NCnJldmlldyBjb21tZW50cyB0byB0aGUgbWFp bGluZyBsaXN0IChzZWU8YnI+DQpodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvZWNy aXQtY2hhcnRlci5odG1sKS48YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KPGJyPg0KVGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogUmVxdWlyZW1lbnRzDQpmb3IgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1 dGlvbjxicj4NCndpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIDxicj4NCkF1dGhvcihzKSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEguIFNjaHVsenJpbm5lLCBSLiBNYXJzaGFsbDxicj4N CkZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1lY3JpdC1y ZXF1aXJlbWVudHMtMDIudHh0PGJyPg0KUGFnZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjc8YnI+DQpEYXRlICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMDYtMS0zDQo8YnI+ DQo8YnI+DQpUaGlzIGRvY3VtZW50IGVudW1lcmF0ZXMgcmVxdWlyZW1lbnRzIGZvciBlbWVyZ2Vu Y3kgY2FsbHMgcGxhY2VkIGJ5PGJyPg0KdGhlIHB1YmxpYyB1c2luZyB2b2ljZS1vdmVyLUlQIChW b0lQKSBhbmQgZ2VuZXJhbCBJbnRlcm5ldCBtdWx0aW1lZGlhPGJyPg0Kc3lzdGVtcywgd2hlcmUg SW50ZXJuZXQgcHJvdG9jb2xzIGFyZSB1c2VkIGVuZC10by1lbmQuPGJyPg0KPGJyPg0KQSBVUkwg Zm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PGJyPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDIudHh0PGJyPg0KPGJy Pg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCjxicj4NCmNpYW88 YnI+DQpoYW5uZXM8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KTWFpbCBhcmNoaXZlIGZvciBF TVRFTCBjYW4gYmUgYnJvd3NlZCBhdCB0aGUgZm9sbG93aW5nIHVybDogPGJyPg0KaHR0cDovL2xp c3QuZXRzaS5vcmcvRU1URUwuaHRtbDxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KPGJyPg0KPC90dD48 L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0031A339802570FF_=-- --===============2010101722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2010101722==-- From ecrit-bounces@ietf.org Mon Jan 23 05:15:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0yjN-0003uN-Be; Mon, 23 Jan 2006 05:15:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0yjL-0003uI-PM for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 05:15:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04512 for ; Mon, 23 Jan 2006 05:13:54 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0yse-0008Sf-JW for ecrit@ietf.org; Mon, 23 Jan 2006 05:25:02 -0500 Received: (qmail invoked by alias); 23 Jan 2006 10:15:11 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp021) with SMTP; 23 Jan 2006 11:15:11 +0100 X-Authenticated: #29516787 Message-ID: <43D4ACAD.3090008@gmx.net> Date: Mon, 23 Jan 2006 11:15:09 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raymond Forbes Subject: Re: [Ecrit] Issue 30: Summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ecrit-bounces@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi raymond, ~snip~ > > * Tourist Alice collapses, another tourist Bob finds the cell > > phone of Alice and dials its own home emergency number (because it > > does > > not know the local emergency number) and the home emergency number is > > different from the local emergency number and Alice/Bob have different > > home emergency numbers. > > > > That seems essentially unsolvable. Given typical tourist herds that I > have observed, they tend to cluster by nationality (or at least > region), if only to make the job of the tour guide a bit easier :-) > > [rcf]: GSM Cell Phones address this problem as they can dail a number of > Emergency numbers from the SIM Card. The Phone can translate the Dialled > number into the Local Emergency number 112, 911, 110, 111, 000 etc... in gsm there is no equivalent to the global emergency identifier as we discuss it here. as such, you need to have a mechanism to retrieve the local emergency numbers in order todo the translation from the home emergency number to the local onces. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 08:45:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F120W-0000Wf-Om; Mon, 23 Jan 2006 08:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F120V-0000WO-LQ; Mon, 23 Jan 2006 08:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18767; Mon, 23 Jan 2006 08:43:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F129q-000692-NI; Mon, 23 Jan 2006 08:55:00 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 23 Jan 2006 05:45:05 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0NDj4WF016747; Mon, 23 Jan 2006 05:45:04 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 08:45:03 -0500 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: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 08:45:02 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301030C77@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgBhWSN/y0bZ66TeeqUmEMNSsEZQAHDX5g From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" , "Raymond Forbes" X-OriginalArrivalTime: 23 Jan 2006 13:45:03.0706 (UTC) FILETIME=[3681D3A0:01C62023] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: ecrit-bounces@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, We still seem to be glossing over terms and usage it seems. When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? Mike=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number=20 > (because it =20 > > > does > not know the local emergency number) and the home=20 > emergency=20 > > number is > different from the local emergency number and=20 > Alice/Bob=20 > > have different > home emergency numbers. > > > > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 09:11:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Pz-0006aa-2y; Mon, 23 Jan 2006 09:11:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Px-0006Yn-1R; Mon, 23 Jan 2006 09:11:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21318; Mon, 23 Jan 2006 09:10:06 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12ZF-0007EJ-Qc; Mon, 23 Jan 2006 09:21:15 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0NEBMku007173Mon, 23 Jan 2006 14:11:22 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F12Pi-0002IF-00; Mon, 23 Jan 2006 14:11:22 +0000 Date: Mon, 23 Jan 2006 14:11:22 +0000 From: "Clive D.W. Feather" To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] Issue 30: Summary Message-ID: <20060123141122.GD3821@finch-staff-1.thus.net> References: <072C5B76F7CEAB488172C6F64B30B5E301030C77@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301030C77@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ecrit-bounces@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) said: > When you talk about "emergency numbers", are you referring to an E.164 > number that the "emergency dial string" gets translated to? And what if there isn't such a thing? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 09:13:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Rb-0007uK-DQ; Mon, 23 Jan 2006 09:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12RZ-0007u8-Ki; Mon, 23 Jan 2006 09:13:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22215; Mon, 23 Jan 2006 09:11:46 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12av-0007Qd-Iz; Mon, 23 Jan 2006 09:22:58 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0NED4u2015493; Mon, 23 Jan 2006 15:13:05 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0NED3Fr017909; Mon, 23 Jan 2006 15:13:04 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 15:13:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 15:10:26 +0100 Message-ID: Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgBhWSN/y0bZ66TeeqUmEMNSsEZQAHDX5gAAD4+wA= From: "Tschofenig, Hannes" To: "Michael Hammer \(mhammer\)" , "Hannes Tschofenig" , "Raymond Forbes" X-OriginalArrivalTime: 23 Jan 2006 14:13:03.0096 (UTC) FILETIME=[1F806780:01C62027] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: ecrit-bounces@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi mike,=20 =20 > Hannes, >=20 > We still seem to be glossing over terms and usage it seems. >=20 > When you talk about "emergency numbers", are you referring to an E.164 > number that the "emergency dial string" gets translated to? Or, just > that 3 digit emergency code? i guess we should use the term 'emergency dial string'.=20 i used the term 'emergency numbers' in my response to raymond since he used it as well. i wanted to avoid confusion in the discussion with him (and instead create other confusion). >=20 > Also, you seem to suggest that each of the hundred or so=20 > emergency dial > strings (112, 911, etc.) are reserved for emergency use=20 > globally. no, i do not make any suggestions with this regard.=20 my summary was just an attempt to capture what was said and to investigate what people really want.=20 =20 to me it seems that some people want to work on a mechanism to allow the end point to learn information about the available local emergency dial strings.=20 > Right > now I understand there are some conflicts. Are you proposing that all > those emergency codes be reserved for emergency use in all countries. you know that we cannot do that.=20 > That is, where any of those codes is used for another purpose, that > country must change their usage? So, that the tourist from=20 > any country > can visit any country and any emergency code will work? no. ciao hannes >=20 > Mike=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > On Behalf Of Hannes Tschofenig > > Sent: Monday, January 23, 2006 5:15 AM > > To: Raymond Forbes > > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > >=20 > > hi raymond, > >=20 > > ~snip~ > >=20 > > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > > phone of Alice and dials its own home emergency number=20 > > (because it =20 > > > > does > not know the local emergency number) and the home=20 > > emergency=20 > > > number is > different from the local emergency number and=20 > > Alice/Bob=20 > > > have different > home emergency numbers. > > > > > > >=20 > > > That seems essentially unsolvable. Given typical tourist=20 > > herds that I=20 > > > have observed, they tend to cluster by nationality (or at least=20 > > > region), if only to make the job of the tour guide a bit=20 > easier :-) > > >=20 > > > [rcf]: GSM Cell Phones address this problem as they can=20 > > dail a number=20 > > > of Emergency numbers from the SIM Card. The Phone can=20 > translate the=20 > > > Dialled number into the Local Emergency number 112, 911,=20 > > 110, 111, 000 etc... > >=20 > >=20 > > in gsm there is no equivalent to the global emergency=20 > > identifier as we discuss it here. > > as such, you need to have a mechanism to retrieve the local=20 > > emergency numbers in order todo the translation from the home=20 > > emergency number to the local onces. > >=20 > > ciao > > hannes > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 09:30:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12ia-00044N-Ji; Mon, 23 Jan 2006 09:30:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12iY-00043T-TL for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 09:30:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22884 for ; Mon, 23 Jan 2006 09:29:18 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12kA-0007lS-Ja for ecrit@ietf.org; Mon, 23 Jan 2006 09:32:32 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jan 2006 06:22:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,211,1136188800"; d="scan'208"; a="20257959:sNHT25831742" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0NEMKPc028216; Mon, 23 Jan 2006 09:22:38 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 09:22:34 -0500 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: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 09:22:32 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301030CA9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgBhWSN/y0bZ66TeeqUmEMNSsEZQAHDX5gAAD4+wAAAGb5IA== From: "Michael Hammer \(mhammer\)" To: "Tschofenig, Hannes" , "Hannes Tschofenig" X-OriginalArrivalTime: 23 Jan 2006 14:22:34.0109 (UTC) FILETIME=[73DA12D0:01C62028] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Then hopefully, the requirements/solution addresses these two cases: Home dial string used for non-emergency service code coincides with local visited emergency dial string. Home emergency dial string coincides with local visited non-emergency dial string service code. as well as the cases: Home emergency dial string not used in local visited network. Local visited emergency dial string not used in home network. Mike > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Monday, January 23, 2006 9:10 AM > To: Michael Hammer (mhammer); Hannes Tschofenig; Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: AW: [Ecrit] Issue 30: Summary >=20 > hi mike,=20 > =20 > > Hannes, > >=20 > > We still seem to be glossing over terms and usage it seems. > >=20 > > When you talk about "emergency numbers", are you referring=20 > to an E.164=20 > > number that the "emergency dial string" gets translated to?=20 > Or, just=20 > > that 3 digit emergency code? >=20 > i guess we should use the term 'emergency dial string'.=20 > i used the term 'emergency numbers' in my response to raymond=20 > since he used it as well. i wanted to avoid confusion in the=20 > discussion with him (and instead create other confusion). >=20 > >=20 > > Also, you seem to suggest that each of the hundred or so emergency=20 > > dial strings (112, 911, etc.) are reserved for emergency=20 > use globally. >=20 > no, i do not make any suggestions with this regard.=20 > my summary was just an attempt to capture what was said and=20 > to investigate what people really want.=20 > =20 > to me it seems that some people want to work on a mechanism=20 > to allow the end point to learn information about the=20 > available local emergency dial strings.=20 >=20 > > Right > > now I understand there are some conflicts. Are you=20 > proposing that all=20 > > those emergency codes be reserved for emergency use in all=20 > countries. >=20 > you know that we cannot do that.=20 >=20 > > That is, where any of those codes is used for another purpose, that=20 > > country must change their usage? So, that the tourist from any=20 > > country can visit any country and any emergency code will work? >=20 > no. >=20 > ciao > hannes >=20 > >=20 > > Mike > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > > Behalf Of Hannes Tschofenig > > > Sent: Monday, January 23, 2006 5:15 AM > > > To: Raymond Forbes > > > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] Issue 30: Summary > > >=20 > > > hi raymond, > > >=20 > > > ~snip~ > > >=20 > > > > > * Tourist Alice collapses, another tourist Bob=20 > finds the cell > > > > > phone of Alice and dials its own home emergency number > > > (because it > > > > > does > not know the local emergency number) and the home > > > emergency > > > > number is > different from the local emergency number and > > > Alice/Bob > > > > have different > home emergency numbers. > > > > > > > > >=20 > > > > That seems essentially unsolvable. Given typical tourist > > > herds that I > > > > have observed, they tend to cluster by nationality (or at least=20 > > > > region), if only to make the job of the tour guide a bit > > easier :-) > > > >=20 > > > > [rcf]: GSM Cell Phones address this problem as they can > > > dail a number > > > > of Emergency numbers from the SIM Card. The Phone can > > translate the > > > > Dialled number into the Local Emergency number 112, 911, > > > 110, 111, 000 etc... > > >=20 > > >=20 > > > in gsm there is no equivalent to the global emergency=20 > identifier as=20 > > > we discuss it here. > > > as such, you need to have a mechanism to retrieve the local=20 > > > emergency numbers in order todo the translation from the home=20 > > > emergency number to the local onces. > > >=20 > > > ciao > > > hannes > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 09:30:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12if-000471-MI; Mon, 23 Jan 2006 09:30:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12id-000461-TQ for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 09:30:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22929 for ; Mon, 23 Jan 2006 09:29:24 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12iK-0007g0-Kr for ecrit@ietf.org; Mon, 23 Jan 2006 09:30:37 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0NEKbLr002058; Mon, 23 Jan 2006 14:20:38 GMT (envelope-from raymond.forbes@marconi.com) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301030C77@xmb-rtp-20b.amer.cisco.com> To: mhammer@cisco.com Subject: RE: [Ecrit] Issue 30: Summary MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Mon, 23 Jan 2006 14:23:27 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/01/2006 14:20:37, Serialize complete at 23/01/2006 14:20:37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1637884709==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1637884709== Content-Type: multipart/alternative; boundary="=_alternative 004E3AD9802570FF_=" This is a multipart message in MIME format. --=_alternative 004E3AD9802570FF_= Content-Type: text/plain; charset="US-ASCII" I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored. This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages. The GSM solution requires that other national numbers not in the Prime list may be additionally stored. This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services. Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Michael Hammer \(mhammer\)" 23/01/2006 13:45 To: "Hannes Tschofenig" , "Raymond Forbes" cc: , Subject: RE: [Ecrit] Issue 30: Summary Hannes, We still seem to be glossing over terms and usage it seems. When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary > > hi raymond, > > ~snip~ > > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number > (because it > > > does > not know the local emergency number) and the home > emergency > > number is > different from the local emergency number and > Alice/Bob > > have different > home emergency numbers. > > > > > > > That seems essentially unsolvable. Given typical tourist > herds that I > > have observed, they tend to cluster by nationality (or at least > > region), if only to make the job of the tour guide a bit easier :-) > > > > [rcf]: GSM Cell Phones address this problem as they can > dail a number > > of Emergency numbers from the SIM Card. The Phone can translate the > > Dialled number into the Local Emergency number 112, 911, > 110, 111, 000 etc... > > > in gsm there is no equivalent to the global emergency > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local > emergency numbers in order todo the translation from the home > emergency number to the local onces. > > ciao > hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > --=_alternative 004E3AD9802570FF_= Content-Type: text/html; charset="US-ASCII"
I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.

This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages.

The GSM solution requires that other national numbers not in the Prime list may be additionally stored.

This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services.

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


"Michael Hammer \(mhammer\)" <mhammer@cisco.com>

23/01/2006 13:45

       
        To:        "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "Raymond Forbes" <raymond.forbes@marconi.com>
        cc:        <ecrit-bounces@ietf.org>, <ecrit@ietf.org>
        Subject:        RE: [Ecrit] Issue 30: Summary



Hannes,

We still seem to be glossing over terms and usage it seems.

When you talk about "emergency numbers", are you referring to an E.164
number that the "emergency dial string" gets translated to?  Or, just
that 3 digit emergency code?

Also, you seem to suggest that each of the hundred or so emergency dial
strings (112, 911, etc.) are reserved for emergency use globally.  Right
now I understand there are some conflicts.  Are you proposing that all
those emergency codes be reserved for emergency use in all countries.
That is, where any of those codes is used for another purpose, that
country must change their usage?  So, that the tourist from any country
can visit any country and any emergency code will work?

Mike

> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> On Behalf Of Hannes Tschofenig
> Sent: Monday, January 23, 2006 5:15 AM
> To: Raymond Forbes
> Cc: ecrit-bounces@ietf.org; ecrit@ietf.org
> Subject: Re: [Ecrit] Issue 30: Summary
>
> hi raymond,
>
> ~snip~
>
> >  >   * Tourist Alice collapses, another tourist Bob finds the cell
> >  > phone of Alice and dials its own home emergency number
> (because it  
> > > does  > not know the local emergency number) and the home
> emergency
> > number is  > different from the local emergency number and
> Alice/Bob
> > have different  > home emergency numbers.
> >  >
> >
> > That seems essentially unsolvable. Given typical tourist
> herds that I
> > have observed, they tend to cluster by nationality (or at least
> > region), if only to make the job of the tour guide a bit easier :-)
> >
> > [rcf]: GSM Cell Phones address this problem as they can
> dail a number
> > of Emergency numbers from the SIM Card. The Phone can translate the
> > Dialled number into the Local Emergency number 112, 911,
> 110, 111, 000 etc...
>
>
> in gsm there is no equivalent to the global emergency
> identifier as we discuss it here.
> as such, you need to have a mechanism to retrieve the local
> emergency numbers in order todo the translation from the home
> emergency number to the local onces.
>
> ciao
> hannes
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>

--=_alternative 004E3AD9802570FF_=-- --===============1637884709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1637884709==-- From ecrit-bounces@ietf.org Mon Jan 23 09:31:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12ir-0004EP-34; Mon, 23 Jan 2006 09:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12im-0004C7-Mf for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 09:31:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23011 for ; Mon, 23 Jan 2006 09:29:32 -0500 (EST) 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 1F12em-0007Z8-0R for ecrit@ietf.org; Mon, 23 Jan 2006 09:26:57 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Jan 2006 06:17:06 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0NEH5jt021957; Mon, 23 Jan 2006 06:17:05 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 09:17:05 -0500 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: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 09:17:04 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301030C9F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgJvoPAQAH78BoRZeysUgSSATrfwAAJS7Q From: "Michael Hammer \(mhammer\)" To: "Clive D.W. Feather" X-OriginalArrivalTime: 23 Jan 2006 14:17:05.0116 (UTC) FILETIME=[AFC1B9C0:01C62027] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not necessarily an issue, but I need to be able to correctly parse the sentence. Mike =20 > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net]=20 > Sent: Monday, January 23, 2006 9:11 AM > To: Michael Hammer (mhammer) > Cc: Hannes Tschofenig; Raymond Forbes;=20 > ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > Michael Hammer (mhammer) said: > > When you talk about "emergency numbers", are you referring=20 > to an E.164=20 > > number that the "emergency dial string" gets translated to? >=20 > And what if there isn't such a thing? >=20 > --=20 > Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495 6138 > Internet Expert | Home: | Fax: =20 > +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > +44 7973 377646 > Thus plc | | >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 09:55:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1367-0003Si-RC; Mon, 23 Jan 2006 09:55:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1365-0003Sb-R1 for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 09:55:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25163 for ; Mon, 23 Jan 2006 09:53:39 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13FQ-0000pN-Bj for ecrit@ietf.org; Mon, 23 Jan 2006 10:04:50 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0NEstdG000191; Mon, 23 Jan 2006 15:54:56 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0NEstBr028713; Mon, 23 Jan 2006 15:54:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 15:54:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 15:53:57 +0100 Message-ID: Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgBhWSN/y0bZ66TeeqUmEMNSsEZQAHDX5gAAD4+wAAAGb5IAABNaWA From: "Tschofenig, Hannes" To: "Michael Hammer \(mhammer\)" , "Hannes Tschofenig" X-OriginalArrivalTime: 23 Jan 2006 14:54:55.0308 (UTC) FILETIME=[F8E588C0:01C6202C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi mike,=20 if you have your home and your local dial strings configured at the user = agent then you map them to the global emergency identifier. as such, = there is no problem anymore.=20 the problem appears if you do not map them to the global emergency = identifier.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Gesendet: Montag, 23. Januar 2006 15:23 > An: Tschofenig, Hannes; Hannes Tschofenig > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] Issue 30: Summary >=20 > Then hopefully, the requirements/solution addresses these two cases: >=20 > Home dial string used for non-emergency service code coincides with > local visited emergency dial string. >=20 > Home emergency dial string coincides with local visited non-emergency > dial string service code. >=20 > as well as the cases: >=20 > Home emergency dial string not used in local visited network. >=20 > Local visited emergency dial string not used in home network. >=20 > Mike >=20 >=20 >=20 > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > > Sent: Monday, January 23, 2006 9:10 AM > > To: Michael Hammer (mhammer); Hannes Tschofenig; Raymond Forbes > > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > > Subject: AW: [Ecrit] Issue 30: Summary > >=20 > > hi mike,=20 > > =20 > > > Hannes, > > >=20 > > > We still seem to be glossing over terms and usage it seems. > > >=20 > > > When you talk about "emergency numbers", are you referring=20 > > to an E.164=20 > > > number that the "emergency dial string" gets translated to?=20 > > Or, just=20 > > > that 3 digit emergency code? > >=20 > > i guess we should use the term 'emergency dial string'.=20 > > i used the term 'emergency numbers' in my response to raymond=20 > > since he used it as well. i wanted to avoid confusion in the=20 > > discussion with him (and instead create other confusion). > >=20 > > >=20 > > > Also, you seem to suggest that each of the hundred or so=20 > emergency=20 > > > dial strings (112, 911, etc.) are reserved for emergency=20 > > use globally. > >=20 > > no, i do not make any suggestions with this regard.=20 > > my summary was just an attempt to capture what was said and=20 > > to investigate what people really want.=20 > > =20 > > to me it seems that some people want to work on a mechanism=20 > > to allow the end point to learn information about the=20 > > available local emergency dial strings.=20 > >=20 > > > Right > > > now I understand there are some conflicts. Are you=20 > > proposing that all=20 > > > those emergency codes be reserved for emergency use in all=20 > > countries. > >=20 > > you know that we cannot do that.=20 > >=20 > > > That is, where any of those codes is used for another=20 > purpose, that=20 > > > country must change their usage? So, that the tourist from any=20 > > > country can visit any country and any emergency code will work? > >=20 > > no. > >=20 > > ciao > > hannes > >=20 > > >=20 > > > Mike > > >=20 > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > > > Behalf Of Hannes Tschofenig > > > > Sent: Monday, January 23, 2006 5:15 AM > > > > To: Raymond Forbes > > > > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Issue 30: Summary > > > >=20 > > > > hi raymond, > > > >=20 > > > > ~snip~ > > > >=20 > > > > > > * Tourist Alice collapses, another tourist Bob=20 > > finds the cell > > > > > > phone of Alice and dials its own home emergency number > > > > (because it > > > > > > does > not know the local emergency number) and the home > > > > emergency > > > > > number is > different from the local emergency number and > > > > Alice/Bob > > > > > have different > home emergency numbers. > > > > > > > > > > >=20 > > > > > That seems essentially unsolvable. Given typical tourist > > > > herds that I > > > > > have observed, they tend to cluster by nationality=20 > (or at least=20 > > > > > region), if only to make the job of the tour guide a bit > > > easier :-) > > > > >=20 > > > > > [rcf]: GSM Cell Phones address this problem as they can > > > > dail a number > > > > > of Emergency numbers from the SIM Card. The Phone can > > > translate the > > > > > Dialled number into the Local Emergency number 112, 911, > > > > 110, 111, 000 etc... > > > >=20 > > > >=20 > > > > in gsm there is no equivalent to the global emergency=20 > > identifier as=20 > > > > we discuss it here. > > > > as such, you need to have a mechanism to retrieve the local=20 > > > > emergency numbers in order todo the translation from the home=20 > > > > emergency number to the local onces. > > > >=20 > > > > ciao > > > > hannes > > > >=20 > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > >=20 > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 10:02:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13Cs-0004p7-Fv; Mon, 23 Jan 2006 10:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13Cr-0004p2-8g for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:02:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25460 for ; Mon, 23 Jan 2006 10:00:38 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F13MA-000109-RG for ecrit@ietf.org; Mon, 23 Jan 2006 10:11:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 16:05:43 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B235F@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgK8FRvBwnKPVJTyazk7qv6H0YPwAAQC1w From: "Stastny Richard" To: "Raymond Forbes" , X-Spam-Score: 0.3 (/) X-Scan-Signature: 39821207e2a2cade5c69c89d23fb80ee Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1550875572==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1550875572== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6202E.7AF3DB4E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6202E.7AF3DB4E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am really getting tired of this discussion, which goes on now for years, simply because there is no solution to have home and local emergency dial strings working in any case because of conflicts that are not resolvable on a global scale, and especially NOT by ECRIT. =20 Since any user needs to have a dial plan agreed upon with his provider (which will be in most cases the home dial plan) and this dial plan can be configured into the device =20 I suggest the following: =20 The global emergency dial strings 911 and 112 MUST be supported by any device and MUST be mapped to the default sos identifier In addition, the emergency dial strings supported in the home dial plan MUST be supported and mapped accordingly =20 Local emergency dial strings may be supported if there exists no conflict. If the device is not aware of the local emergency dial strings or conflicting other dial strings, it MUST NOT support these dial strings (in doubt) =20 VoIP users should be made aware at subscription time that they SHALL only use 911 or 112 when abroad (also by NENA and EENA) =20 Regards Richard =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes Sent: Monday, January 23, 2006 3:23 PM To: mhammer@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.=20 This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages.=20 The GSM solution requires that other national numbers not in the Prime list may be additionally stored.=20 This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services.=20 Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =20 "Michael Hammer \(mhammer\)" =20 23/01/2006 13:45=20 =20 To: "Hannes Tschofenig" , "Raymond Forbes" =20 cc: , =20 Subject: RE: [Ecrit] Issue 30: Summary Hannes, We still seem to be glossing over terms and usage it seems. When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? Mike=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number=20 > (because it =20 > > > does > not know the local emergency number) and the home=20 > emergency=20 > > number is > different from the local emergency number and=20 > Alice/Bob=20 > > have different > home emergency numbers. > > > > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ------_=_NextPart_001_01C6202E.7AF3DB4E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am really = getting tired of this discussion, which goes on now for years,
simply because there is no solution to have home and local emergency
dial strings working in any case because of conflicts that are not = resolvable
on a global scale, and especially NOT by = ECRIT.

 =

Since any user = needs to have a dial plan agreed upon with his provider
(which will be in most cases the home dial plan) and this dial plan
can be configured into the device

 =

I suggest the = following:

 =

The global = emergency dial strings 911 and 112 MUST be supported by any = device

and MUST be = mapped to the default sos identifier
In addition, the emergency dial strings supported in the home dial plan = MUST be supported

and mapped = accordingly

 =

Local emergency = dial strings may be supported if there exists no conflict. If the device
is not aware of the local emergency dial strings or conflicting other = dial strings, it MUST NOT
support these dial strings (in doubt)

 =

VoIP users = should be made aware at subscription time that they SHALL only use
911 or 112 when abroad (also by NENA and = EENA)

 =

Regards

Richard

 =

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes
Sent: Monday, January 23, = 2006 3:23 PM
To: mhammer@cisco.com
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 


I was only pointing to the example in GSM (3GPP) = today where there most commonly used global numbers are stored in all SIM = modules, and further local national numbers may be additionally = stored.

This alleviates the need for having a Global address as the Roaming/Nomadic = terminal inter-works with the region it is in. A global address has certain = advantages.

The GSM solution requires that other national numbers not in the Prime list = may be additionally stored.

This solves the problem of encountered my the majority of tourists, US or = Japanese Tourists in London. who do not know that their national number (911 or = 110) needs translating to 112. It does not solve all problems. For example = 110 in Germany will reach the Police not the Emergency services. =

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not = the intended recipient, please notify us immediately by reply e-mail and = then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents = to any other person: to do so could be a breach of confidence.


 

"Michael Hammer \(mhammer\)" <mhammer@cisco.com> =

23/01/2006 13:45

       
        To:        "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "Raymond Forbes" <raymond.forbes@marconi.com>
        cc:       =  <ecrit-bounces@ietf.org>, <ecrit@ietf.org>
        Subject:        RE: [Ecrit] = Issue 30: Summary




Hannes,

We still seem to be glossing over terms = and usage it seems.

When you talk about "emergency = numbers", are you referring to an E.164
number that the "emergency dial = string" gets translated to?  Or, just
that 3 digit emergency = code?

Also, you seem to suggest that each of = the hundred or so emergency dial
strings (112, 911, etc.) are reserved for emergency use globally.  Right
now I understand there are some = conflicts.  Are you proposing that all
those emergency codes be reserved for = emergency use in all countries.
That is, where any of those codes is used = for another purpose, that
country must change their usage? =  So, that the tourist from any country
can visit any country and any emergency = code will work?

Mike

> -----Original = Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> On Behalf Of Hannes = Tschofenig
> Sent: Monday, January 23, 2006 5:15 = AM
> To: Raymond Forbes
> Cc: ecrit-bounces@ietf.org; = ecrit@ietf.org
> Subject: Re: [Ecrit] Issue 30: = Summary
>
> hi raymond,
>
> ~snip~
>
> >  >   * Tourist = Alice collapses, another tourist Bob finds the cell
> >  > phone of Alice and = dials its own home emergency number
> (because it  
> > > does  > not know = the local emergency number) and the home
> emergency
> > number is  > different = from the local emergency number and
> Alice/Bob
> > have different  > home = emergency numbers.
> >  >
> >
> > That seems essentially = unsolvable. Given typical tourist
> herds that I
> > have observed, they tend to = cluster by nationality (or at least
> > region), if only to make the = job of the tour guide a bit easier :-)
> >
> > [rcf]: GSM Cell Phones address = this problem as they can
> dail a number
> > of Emergency numbers from the = SIM Card. The Phone can translate the
> > Dialled number into the Local = Emergency number 112, 911,
> 110, 111, 000 etc...
>
>
> in gsm there is no equivalent to the = global emergency
> identifier as we discuss it = here.
> as such, you need to have a = mechanism to retrieve the local
> emergency numbers in order todo the translation from the home
> emergency number to the local = onces.
>
> ciao
> hannes
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> = https://www1.ietf.org/mailman/listinfo/ecrit
> =

------_=_NextPart_001_01C6202E.7AF3DB4E-- --===============1550875572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1550875572==-- From ecrit-bounces@ietf.org Mon Jan 23 10:07:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13IJ-000658-R6; Mon, 23 Jan 2006 10:07:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13IJ-00064w-5O for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:07:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25803 for ; Mon, 23 Jan 2006 10:06:18 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13Rf-0001Ch-QC for ecrit@ietf.org; Mon, 23 Jan 2006 10:17:28 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F13I5-0003pX-5f; Mon, 23 Jan 2006 09:07:34 -0600 From: "Brian Rosen" To: "'Raymond Forbes'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 10:05:16 -0500 Message-ID: <047c01c6202e$6d75a9d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYgK0IFL3u3xeiHQqG+sRqhKzBz7gAATLGg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that while we do have to agree on terminology for our documents, = we don=92t have to agree here in ecrit on exactly what an endpoint does = with information we supply it. I=92d rather not get into specifying a = =93prime=94 list of numbers, for example. What I do want to do is to specify the mechanisms by which an endpoint learns the emergency dialstring for both its home and visited locations. It does seem like =93dialstring=94 is the right noun, especially the way = we intend to use it, which is that an entity (the endpoint or a downstream proxy) translates that digit sequence to the universal URN, which may subsequently be translated to some other URI (be it a SIP uri or a tel = uri or even something else). So, I would propose that we henceforth agree = to use the term =93emergency dialstring=94 to refer to the digit sequence = dialed in some location to reach emergency services. This avoids confusion with = what =93emergency number=94 means. Then, I do think we are better off referring to =93visited=94 and = =93home=94 access networks when talking about these issues. It does seem to make it = wireless centric, which I don=92t intend to, but I think it eliminates confusion. = The term =93local=94 and =93remote=94 are too ambiguous to be used for = either =93home=94 or =93visited=94 (is it remote from where you normally are, or remote from = where you are now?). Brian ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Raymond Forbes Sent: Monday, January 23, 2006 9:23 AM To: mhammer@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.=20 This alleviates the need for having a Global address as the = Roaming/Nomadic terminal inter-works with the region it is in. A global address has = certain advantages.=20 The GSM solution requires that other national numbers not in the Prime = list may be additionally stored.=20 This solves the problem of encountered my the majority of tourists, US = or Japanese Tourists in London. who do not know that their national number = (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services. = Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. =A0If you are not the intended recipient, please notify us immediately by reply e-mail and = then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents = to any other person: to do so could be a breach of confidence. "Michael Hammer \(mhammer\)" =20 23/01/2006 13:45=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Hannes Tschofenig" = , "Raymond Forbes" =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0, = =20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [Ecrit] Issue 30: Summary Hannes, We still seem to be glossing over terms and usage it seems. When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? =A0Or, just that 3 digit emergency code? Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. = =A0Right now I understand there are some conflicts. =A0Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? =A0So, that the tourist from any = country can visit any country and any emergency code will work? Mike=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > =A0> =A0 * Tourist Alice collapses, another tourist Bob finds the = cell > > =A0> phone of Alice and dials its own home emergency number=20 > (because it =A0 > > > does =A0> not know the local emergency number) and the home=20 > emergency=20 > > number is =A0> different from the local emergency number and=20 > Alice/Bob=20 > > have different =A0> home emergency numbers. > > =A0> > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 10:19:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13Ts-0001eW-Ci; Mon, 23 Jan 2006 10:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13Tq-0001eI-FA for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:19:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26588 for ; Mon, 23 Jan 2006 10:18:13 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13dC-0001eM-TV for ecrit@ietf.org; Mon, 23 Jan 2006 10:29:23 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jan 2006 07:19:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,212,1136188800"; d="scan'208,217"; a="20263350:sNHT58395962" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0NFIsPu008957; Mon, 23 Jan 2006 10:19:30 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 10:19:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 10:19:24 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301030CFD@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgK8FRvBwnKPVJTyazk7qv6H0YPwAAQC1wAADYUoA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" X-OriginalArrivalTime: 23 Jan 2006 15:19:24.0748 (UTC) FILETIME=[64C048C0:01C62030] X-Spam-Score: 0.5 (/) X-Scan-Signature: 38a35b5fc88e9b9a2affced027b040a4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0465948286==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0465948286== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62030.6495ED68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62030.6495ED68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like your approach, but have only one question. =20 Do folks from Asia, Africa, Australia, and South America accept that 911 and 112 are the global emergency dial strings? =20 Mike =20 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, January 23, 2006 10:06 AM To: Raymond Forbes; Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =09 =09 I am really getting tired of this discussion, which goes on now for years, simply because there is no solution to have home and local emergency dial strings working in any case because of conflicts that are not resolvable on a global scale, and especially NOT by ECRIT. =20 Since any user needs to have a dial plan agreed upon with his provider (which will be in most cases the home dial plan) and this dial plan can be configured into the device =20 I suggest the following: =20 The global emergency dial strings 911 and 112 MUST be supported by any device and MUST be mapped to the default sos identifier In addition, the emergency dial strings supported in the home dial plan MUST be supported and mapped accordingly =20 Local emergency dial strings may be supported if there exists no conflict. If the device is not aware of the local emergency dial strings or conflicting other dial strings, it MUST NOT support these dial strings (in doubt) =20 VoIP users should be made aware at subscription time that they SHALL only use 911 or 112 when abroad (also by NENA and EENA) =20 Regards Richard =09 =09 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes Sent: Monday, January 23, 2006 3:23 PM To: mhammer@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 =09 I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.=20 =09 This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages.=20 =09 The GSM solution requires that other national numbers not in the Prime list may be additionally stored.=20 =09 This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services.=20 =09 Regards, =09 Ray Forbes. =09 +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =09 =09 =09 =20 "Michael Hammer \(mhammer\)" =20 23/01/2006 13:45=20 =20 To: "Hannes Tschofenig" , "Raymond Forbes" =20 cc: , =20 Subject: RE: [Ecrit] Issue 30: Summary =09 =09 =09 Hannes, =09 We still seem to be glossing over terms and usage it seems. =09 When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? =09 Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? =09 Mike=20 =09 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number=20 > (because it =20 > > > does > not know the local emergency number) and the home=20 > emergency=20 > > number is > different from the local emergency number and=20 > Alice/Bob=20 > > have different > home emergency numbers. > > > > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ------_=_NextPart_001_01C62030.6495ED68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I like your approach, but have only one=20 question.
 
Do folks from Asia, Africa, Australia, and South America = accept=20 that 911 and 112 are the global emergency dial = strings?
 
Mike
 

From: Stastny Richard=20 [mailto:Richard.Stastny@oefeg.at]
Sent: Monday, January 23, = 2006=20 10:06 AM
To: Raymond Forbes; Michael Hammer = (mhammer)
Cc:=20 ecrit@ietf.org
Subject: RE: [Ecrit] Issue 30:=20 Summary

I am really = getting=20 tired of this discussion, which goes on now for years,
simply = because there=20 is no solution to have home and local emergency
dial strings = working in any=20 case because of conflicts that are not resolvable
on a global = scale, and=20 especially NOT by ECRIT.

 

Since any = user needs=20 to have a dial plan agreed upon with his provider
(which will be in = most=20 cases the home dial plan) and this dial plan
can be configured into = the=20 device

 

I suggest = the=20 following:

 

The global = emergency=20 dial strings 911 and 112 MUST be supported by any=20 device

and MUST be = mapped to=20 the default sos identifier
In addition, the emergency dial strings=20 supported in the home dial plan MUST be = supported

and mapped=20 accordingly

 

Local = emergency dial=20 strings may be supported if there exists no conflict. If the = device
is not=20 aware of the local emergency dial strings or conflicting other dial = strings,=20 it MUST NOT
support these dial strings (in=20 doubt)

 

VoIP users = should be=20 made aware at subscription time that they SHALL only use
911 or 112 = when=20 abroad (also by NENA and EENA)

 

Regards

Richard

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of Raymond Forbes
Sent: Monday, January 23, 2006 = 3:23=20 PM
To: = mhammer@cisco.com
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] Issue 30:=20 Summary

 


I = was only=20 pointing to the example in GSM (3GPP) today where there most commonly = used=20 global numbers are stored in all SIM modules, and further local = national=20 numbers may be additionally stored.

This alleviates the = need for=20 having a Global address as the Roaming/Nomadic terminal inter-works = with the=20 region it is in. A global address has certain = advantages.=20

The GSM solution = requires=20 that other national numbers not in the Prime list may be additionally=20 stored.

This solves the = problem of=20 encountered my the majority of tourists, US or Japanese Tourists in = London.=20 who do not know that their national number (911 or 110) needs = translating to=20 112. It does not solve all problems. For example 110 in Germany will = reach the=20 Police not the Emergency services.

Regards,

Ray = Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 = 771 851=20 1361 Mobile/text
------------
This e-mail and any attachments = are=20 confidential.  If you are not the intended recipient, please = notify us=20 immediately by reply e-mail and then delete this message from your = system. Do=20 not copy this e-mail or any attachments, use the contents for any = purpose, or=20 disclose the contents to any other person: to do so could be a breach = of=20 confidence.


 

"Michael=20 Hammer \(mhammer\)" <mhammer@cisco.com>=20

23/01/2006=20 13:45

    =    =20
  =    =20   To:        "Hannes Tschofenig"=20 <Hannes.Tschofenig@gmx.net>, "Raymond Forbes"=20 <raymond.forbes@marconi.com>
  =    =20   cc:       =  <ecrit-bounces@ietf.org>,=20 <ecrit@ietf.org>
 =20       Subject:        RE: = [Ecrit]=20 Issue 30: = Summary




Hannes,

We still seem to be glossing over terms and usage = it=20 seems.

When you talk = about=20 "emergency numbers", are you referring to an = E.164
number that the "emergency dial string" gets = translated to?=20  Or, just
that 3 = digit=20 emergency code?

Also, you seem=20 to suggest that each of the hundred or so emergency=20 dial
strings (112, 911, = etc.) are=20 reserved for emergency use globally. =  Right
now I understand there are some conflicts. =  Are you=20 proposing that all
those = emergency=20 codes be reserved for emergency use in all = countries.
That is, where any of those codes is used for = another=20 purpose, that
country = must change=20 their usage?  So, that the tourist from any=20 country
can visit any = country and=20 any emergency code will work?

Mike

>=20 -----Original Message-----
>=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20
> On Behalf Of = Hannes=20 Tschofenig
> Sent: = Monday,=20 January 23, 2006 5:15 AM
> To:=20 Raymond Forbes
> Cc:=20 ecrit-bounces@ietf.org; ecrit@ietf.org
> Subject: Re: [Ecrit] Issue 30:=20 Summary
>=20
> hi=20 raymond,
>=20
>=20 ~snip~
>=20
> >  > =   *=20 Tourist Alice collapses, another tourist Bob finds the=20 cell
> > =  > phone of=20 Alice and dials its own home emergency number =
> (because it  
> > > does  > not know the local = emergency=20 number) and the home
>=20 emergency
> > = number is=20  > different from the local emergency number and=20
> Alice/Bob=20
> > have = different=20  > home emergency numbers.
> >  >
> >
>=20 > That seems essentially unsolvable. Given typical tourist=20
> herds that I=20
> > have = observed, they=20 tend to cluster by nationality (or at least
> > region), if only to make the job of the = tour=20 guide a bit easier :-)
> >=20
> > [rcf]: GSM = Cell Phones=20 address this problem as they can
> dail a number
> > of Emergency numbers from the SIM Card. = The Phone=20 can translate the
> = >=20 Dialled number into the Local Emergency number 112, 911,=20
> 110, 111, 000=20 etc...
>=20
> =
> in gsm there is no equivalent to the global = emergency=20
> identifier as we = discuss it=20 here.
> as such, you = need to=20 have a mechanism to retrieve the local
> emergency numbers in order todo the = translation from=20 the home
> emergency = number to=20 the local onces.
>=20
>=20 ciao
>=20 hannes
>=20
>=20 = _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ecrit
>=20

= ------_=_NextPart_001_01C62030.6495ED68-- --===============0465948286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0465948286==-- From ecrit-bounces@ietf.org Mon Jan 23 10:25:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13ZV-0002XJ-9P; Mon, 23 Jan 2006 10:25:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13ZT-0002XA-Iw for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:25:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26971 for ; Mon, 23 Jan 2006 10:24:02 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13ip-0001qG-Ls for ecrit@ietf.org; Mon, 23 Jan 2006 10:35:12 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0NFPF65016700; Mon, 23 Jan 2006 15:25:15 GMT (envelope-from raymond.forbes@marconi.com) In-Reply-To: To: hannes.tschofenig@siemens.com Subject: Re: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Mon, 23 Jan 2006 15:28:05 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/01/2006 15:25:15, Serialize complete at 23/01/2006 15:25:15 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2e8a07f64def4bd8598257bc442beb9d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516568540==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1516568540== Content-Type: multipart/alternative; boundary="=_alternative 0052F99E802570FF_=" This is a multipart message in MIME format. --=_alternative 0052F99E802570FF_= Content-Type: text/plain; charset="US-ASCII" Hannes, See [RCF]: Below Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Tschofenig, Hannes" 22/01/2006 17:46 To: "Raymond Forbes" , cc: Subject: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt [hannes] we had a long discussion about the term location validation and i think that we use the terms differently. do you have a pointer to your definition? [RCF]: Read EU Commission Recommendation C(2003) 2657 ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This is an option allowed in Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt [hannes] i have to read into the details of ETSI TS 102 164 but the described scenario seems to be supported by the requirements draft. the ability for an outbound proxy to perform location-based routing is clearly in scope of our work. the ability of using the sip identity work is also allowed and might be quite useful. Real Geographic mapping in the TS 102 164 is calculated within the PSAP by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does not need to be mentioned. It is almost the same as the case (8), acquisition of Location Information by a Call Routing Entity in Title: Security Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8 Requirements for Interface . Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means that User's location cannot be held on a Publically accessible directory database. [hannes] here is the paragraph you are referring to: ( http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 01.txt) " 3. The timeliness, integrity and privacy of call signalling must be ensured as it passes between the emergency caller's device and the PSAP. NOTE - a confidentiality requirement applies to the association of a location with an emergency (e.g., within call signalling) or with an individual. The location data per se is not confidential. " i would like to hear your opinion about the following security aspect. we have two places where confidentiality protection is applicable: a) between the access network and the end host when location information is provided by the access network to the end host (e.g., using dhcp as described in http://www.ietf.org/rfc/rfc3825.txt and in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt ) b) as part of the emergency call itself. what problems do you see if confidentiality protection is not applied at (a) and/or at (b) (with regard to the above-mentioned law)? [RCF]: I can agree Option a) above, Option B is also true but is a human risk that people who know call content, including Location data may misuse their knowledge. I am not suggesting that there is a requirement to encrypt Emergency sessions, Or at least not from this EU data protection requirement. [RCF]: there may be a general concern that communication across the public Internet is more easily eavesdropped (casually intercepted by unauthorised individuals) than communication across a private network (IP based or Circuit switched) Secondly, I have one question about the Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve a limited geographic region, ..." [hannes] maybe the term 'limited' should be read as 'specific'. the size of the region, however, does not matter for the purpose of location-based routing or for the mapping protocol. as such, it does not matter. [RCF]: I think there is room for agreement the around the text; I think that I agree with Brian on this that the Region is Limited to be within a Specific Nation it may be a more locally or specifically defined region with a nation. It may be the Entire National Area (in the case of Luxembourg for example). Ciao hannes Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Tschofenig, Hannes" Sent by: "emtel : Emtel" 09/01/2006 22:47 Please respond to "Tschofenig, Hannes" To: EMTEL@LIST.ETSI.ORG cc: Subject: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt hi all, a new version of our requirements document is available. please send review comments to the mailing list (see http://www.ietf.org/html.charters/ecrit-charter.html). ------------------------- Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-02.txt Pages : 27 Date : 2006-1-3 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt ------------------------- ciao hannes ------------------------------------------------------------------- Mail archive for EMTEL can be browsed at the following url: http://list.etsi.org/EMTEL.html ------------------------------------------------------------------- --=_alternative 0052F99E802570FF_= Content-Type: text/html; charset="US-ASCII"
Hannes,

See [RCF]: Below

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


"Tschofenig, Hannes" <hannes.tschofenig@siemens.com>

22/01/2006 17:46

       
        To:        "Raymond Forbes" <raymond.forbes@marconi.com>, <ecrit@ietf.org>
        cc:        
        Subject:        AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt




[hannes] we had a long discussion about the term location validation and
i think that we use the terms differently.
do you have a pointer to your definition?

[RCF]: Read EU Commission Recommendation C(2003) 2657

                ETSI TS 102 164 Assumes that he Routing toward the PSAP is
generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward
the PSAP will be from Asserted Identity Information added of validated
by the ESRP; This is an option allowed in Title: Requirements for
Emergency Context Resolution with Internet Technologies Author(s): H.
Schulzrinne, R. Marshall
                Filename: draft-ietf-ecrit-requirements-02.txt
               

[hannes] i have to read into the details of ETSI TS 102 164 but the
described scenario seems to be supported by the requirements draft. the
ability for an outbound proxy to perform location-based  routing is
clearly in scope of our work. the ability of using the sip identity work
is also allowed  and might be quite useful.


                Real Geographic mapping in the TS 102 164 is calculated within
the PSAP by secure look up into the operators "directory" databases (by
a Private service IP link). The EU has special provision to allow and
require this with the EU data protection Directive. This is not
mentioned, but does not need to be mentioned. It is almost the same as
the case (8), acquisition of Location Information by a Call Routing
Entity in Title: Security Threats and Requirements for Emergency Calling
Author(s): H. Schulzrinne, et al. Filename:
draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8
Requirements for Interface .

               
                Firstly, Security Threats and Requirements for Emergency Calling
draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note
is not be true according to European Directive and Europe-wide laws. The
EU data protection directive states that Location is Private data to the
user that must be secured under the user's right to reveal, withstanding
the three very clear legal exceptions: which are 1. National Security;
2. Criminal Activity and 3. making an Emergency call or Request to the
Emergency services. These Authority must legally respect the rights of
the User not to reveal the location to third parties and commercial
organisations. I suggest that you delete the note. EU Directives and
European-wide law covers at least 30 countries. Under EU Directives the
User's Location is Private data that cannot be revealed except on the
commercial request of the User for a Location based service or under one
of the three provisions. The user's location falling inadvertently into
the wrong hands is a security threat that you do not mention. This means
that User's location cannot be held on a Publically accessible directory
database.

               

[hannes] here is the paragraph you are referring to:
(
http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-
01.txt)

"
  3.  The timeliness, integrity and privacy of call signalling must be
      ensured as it passes between the emergency caller's device and
      the PSAP.

         NOTE - a confidentiality requirement applies to the
         association of a location with an emergency (e.g., within call
         signalling) or with an individual.  The location data per se
         is not confidential.
"

i would like to hear your opinion about the following security aspect.
we have two places where confidentiality protection
is applicable:

a) between the access network and the end host when location information
is provided by the access network to the end host (e.g., using dhcp as
described in http://www.ietf.org/rfc/rfc3825.txt and in
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt
)

b) as part of the emergency call itself.

what problems do you see if confidentiality protection is not applied at
(a) and/or at (b) (with regard to the above-mentioned law)?

[RCF]: I can agree Option a) above, Option B is also true but is a human risk that people who know call content, including Location data may misuse their knowledge. I am not suggesting that there is a requirement to encrypt Emergency sessions, Or at least not from this EU data protection requirement.

[RCF]: there may be a general concern that communication across the public Internet is more easily eavesdropped (casually intercepted by unauthorised individuals) than communication across a private network (IP based or Circuit switched)

                Secondly, I have one question about the Requirements for
Emergency Context Resolution with Internet Technologies Author(s): H.
Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt
on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states
that the "PSAPS only serve a limited geographic region, ..." This in not
True. It may be true in the US and Germany, but in many countries the
PSAPs may server a wide area. The problem will be solved if the Words
are changed to "PSAPS may only serve a limited geographic region, ..."
               

[hannes] maybe the term 'limited' should be read as 'specific'. the size
of the region, however, does not matter for the purpose of
location-based routing or for the mapping protocol. as such, it does not
matter.

[RCF]: I think there is room for agreement the around the text; I think that I agree with Brian on this that the Region is Limited to be within a Specific Nation it may be a more locally or specifically defined region with a nation. It may be the Entire National Area (in the case of Luxembourg for example).

Ciao
hannes

               
                Regards,
               
                Ray Forbes.
               
                +44 24 7656 3106 phone
                +44 24 7656 3816 fax.
                +44 771 851 1361 Mobile/text
                ------------
                This e-mail and any attachments are confidential.  If you are
not the intended recipient, please notify us immediately by reply e-mail
and then delete this message from your system. Do not copy this e-mail
or any attachments, use the contents for any purpose, or disclose the
contents to any other person: to do so could be a breach of confidence.
               
               
               
               
                                 "Tschofenig, Hannes" <hannes.tschofenig@SIEMENS.COM>
                Sent by: "emtel : Emtel" <EMTEL@LIST.ETSI.ORG>

                09/01/2006 22:47
                Please respond to "Tschofenig, Hannes"

                                         
                        To:        EMTEL@LIST.ETSI.ORG
                        cc:        
                        Subject:        [EMTEL] I-D
ACTION:draft-ietf-ecrit-requirements-02.txt



                hi all,
               
                a new version of our requirements document is available. please
send
                review comments to the mailing list (see
                http://www.ietf.org/html.charters/ecrit-charter.html).
               
                -------------------------
               
                Title                : Requirements for Emergency Context
Resolution
                with Internet Technologies
                Author(s)        : H. Schulzrinne, R. Marshall
                Filename        : draft-ietf-ecrit-requirements-02.txt
                Pages                : 27
                Date                : 2006-1-3
               
                This document enumerates requirements for emergency calls placed
by
                the public using voice-over-IP (VoIP) and general Internet
multimedia
                systems, where Internet protocols are used end-to-end.
               
                A URL for this Internet-Draft is:
               
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt
               
               
                -------------------------
               
               
                ciao
                hannes
               
               
-------------------------------------------------------------------
                Mail archive for EMTEL can be browsed at the following url:
                http://list.etsi.org/EMTEL.html
               
-------------------------------------------------------------------
               
               


--=_alternative 0052F99E802570FF_=-- --===============1516568540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1516568540==-- From ecrit-bounces@ietf.org Mon Jan 23 10:29:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13dZ-0004e6-JQ; Mon, 23 Jan 2006 10:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13dX-0004dr-Jn for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:29:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27293 for ; Mon, 23 Jan 2006 10:28:14 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F13mt-0001yb-2M for ecrit@ietf.org; Mon, 23 Jan 2006 10:39:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 16:33:26 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2361@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgK8FRvBwnKPVJTyazk7qv6H0YPwAAQC1wAADYUoAAAHt/YA== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" X-Spam-Score: 0.3 (/) X-Scan-Signature: 6a5c486139a804859f37cd11eb5255b5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0004632186==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0004632186== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62032.5B899C22" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62032.5B899C22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO basically all folks from countries having GSM implemented will accept or at least will know about 112, which includes all regions you mentioned Richard =20 =20 =20 ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Monday, January 23, 2006 4:19 PM To: Stastny Richard Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 I like your approach, but have only one question. =20 Do folks from Asia, Africa, Australia, and South America accept that 911 and 112 are the global emergency dial strings? =20 Mike =20 =20 =09 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, January 23, 2006 10:06 AM To: Raymond Forbes; Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary I am really getting tired of this discussion, which goes on now for years, simply because there is no solution to have home and local emergency dial strings working in any case because of conflicts that are not resolvable on a global scale, and especially NOT by ECRIT. =20 Since any user needs to have a dial plan agreed upon with his provider (which will be in most cases the home dial plan) and this dial plan can be configured into the device =20 I suggest the following: =20 The global emergency dial strings 911 and 112 MUST be supported by any device and MUST be mapped to the default sos identifier In addition, the emergency dial strings supported in the home dial plan MUST be supported and mapped accordingly =20 Local emergency dial strings may be supported if there exists no conflict. If the device is not aware of the local emergency dial strings or conflicting other dial strings, it MUST NOT support these dial strings (in doubt) =20 VoIP users should be made aware at subscription time that they SHALL only use 911 or 112 when abroad (also by NENA and EENA) =20 Regards Richard =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes Sent: Monday, January 23, 2006 3:23 PM To: mhammer@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 =09 I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.=20 =09 This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages.=20 =09 The GSM solution requires that other national numbers not in the Prime list may be additionally stored.=20 =09 This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services.=20 =09 Regards, =09 Ray Forbes. =09 +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =09 =09 =20 "Michael Hammer \(mhammer\)" =20 23/01/2006 13:45=20 =20 To: "Hannes Tschofenig" , "Raymond Forbes" =20 cc: , =20 Subject: RE: [Ecrit] Issue 30: Summary =09 =09 =09 Hannes, =09 We still seem to be glossing over terms and usage it seems. =09 When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? =09 Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? =09 Mike=20 =09 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number=20 > (because it =20 > > > does > not know the local emergency number) and the home=20 > emergency=20 > > number is > different from the local emergency number and=20 > Alice/Bob=20 > > have different > home emergency numbers. > > > > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ------_=_NextPart_001_01C62032.5B899C22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMHO basically = all folks from countries having GSM implemented will accept or
at least will know about 112, which includes all regions you = mentioned

Richard

 =

 =

 =

From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Monday, January 23, = 2006 4:19 PM
To: Stastny Richard
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 

I like your approach, but have = only one question.

 

Do folks from Asia, Africa, = Australia, and South America accept that 911 and 112 are the global emergency dial strings?

 

Mike

 

 

From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
Sent: Monday, January 23, = 2006 10:06 AM
To: Raymond Forbes; = Michael Hammer (mhammer)
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

I am really = getting tired of this discussion, which goes on now for years,
simply because there is no solution to have home and local emergency
dial strings working in any case because of conflicts that are not = resolvable
on a global scale, and especially NOT by = ECRIT.

 =

Since any user = needs to have a dial plan agreed upon with his provider
(which will be in most cases the home dial plan) and this dial plan
can be configured into the device

 =

I suggest the = following:

 =

The global = emergency dial strings 911 and 112 MUST be supported by any = device

and MUST be = mapped to the default sos identifier
In addition, the emergency dial strings supported in the home dial plan = MUST be supported

and mapped = accordingly

 =

Local emergency = dial strings may be supported if there exists no conflict. If the device
is not aware of the local emergency dial strings or conflicting other = dial strings, it MUST NOT
support these dial strings (in doubt)

 =

VoIP users = should be made aware at subscription time that they SHALL only use
911 or 112 when abroad (also by NENA and = EENA)

 =

Regards

Richard

 =

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes
Sent: Monday, January 23, = 2006 3:23 PM
To: mhammer@cisco.com
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 


I was only pointing to the example in GSM (3GPP) today where = there most commonly used global numbers are stored in all SIM modules, and further = local national numbers may be additionally stored.

This alleviates the need for having a Global address as the Roaming/Nomadic = terminal inter-works with the region it is in. A global address has certain = advantages.

The GSM solution requires that other national numbers not in the Prime list = may be additionally stored.

This solves the problem of encountered my the majority of tourists, US or = Japanese Tourists in London. who do not know that their national number (911 or = 110) needs translating to 112. It does not solve all problems. For example = 110 in Germany will reach the Police not the Emergency services. =

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not = the intended recipient, please notify us immediately by reply e-mail and then delete = this message from your system. Do not copy this e-mail or any attachments, = use the contents for any purpose, or disclose the contents to any other person: = to do so could be a breach of confidence.

 

"Michael Hammer = \(mhammer\)" <mhammer@cisco.com>

23/01/2006 13:45

       
        To:        "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "Raymond Forbes" <raymond.forbes@marconi.com>
        cc:       =  <ecrit-bounces@ietf.org>, <ecrit@ietf.org>
        Subject:        RE: [Ecrit] = Issue 30: Summary




Hannes,

We still seem to be glossing over terms = and usage it seems.

When you talk about "emergency = numbers", are you referring to an E.164
number that the "emergency dial = string" gets translated to?  Or, just
that 3 digit emergency = code?

Also, you seem to suggest that each of = the hundred or so emergency dial
strings (112, 911, etc.) are reserved for emergency use globally.  Right
now I understand there are some = conflicts.  Are you proposing that all
those emergency codes be reserved for = emergency use in all countries.
That is, where any of those codes is used = for another purpose, that
country must change their usage? =  So, that the tourist from any country
can visit any country and any emergency = code will work?

Mike

> -----Original = Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> On Behalf Of Hannes = Tschofenig
> Sent: Monday, January 23, 2006 5:15 = AM
> To: Raymond Forbes
> Cc: ecrit-bounces@ietf.org; = ecrit@ietf.org
> Subject: Re: [Ecrit] Issue 30: = Summary
>
> hi raymond,
>
> ~snip~
>
> >  >   * Tourist = Alice collapses, another tourist Bob finds the cell
> >  > phone of Alice and = dials its own home emergency number
> (because it  
> > > does  > not know = the local emergency number) and the home
> emergency
> > number is  > different = from the local emergency number and
> Alice/Bob
> > have different  > home = emergency numbers.
> >  >
> >
> > That seems essentially = unsolvable. Given typical tourist
> herds that I
> > have observed, they tend to = cluster by nationality (or at least
> > region), if only to make the = job of the tour guide a bit easier :-)
> >
> > [rcf]: GSM Cell Phones address = this problem as they can
> dail a number
> > of Emergency numbers from the = SIM Card. The Phone can translate the
> > Dialled number into the Local = Emergency number 112, 911,
> 110, 111, 000 etc...
>
>
> in gsm there is no equivalent to the = global emergency
> identifier as we discuss it = here.
> as such, you need to have a = mechanism to retrieve the local
> emergency numbers in order todo the translation from the home
> emergency number to the local = onces.
>
> ciao
> hannes
>
> = _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> = https://www1.ietf.org/mailman/listinfo/ecrit
> =

------_=_NextPart_001_01C62032.5B899C22-- --===============0004632186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0004632186==-- From ecrit-bounces@ietf.org Mon Jan 23 10:43:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13rE-000859-It; Mon, 23 Jan 2006 10:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13rC-00083o-4R for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:43:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28532 for ; Mon, 23 Jan 2006 10:42:18 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F140V-0002Yx-5x for ecrit@ietf.org; Mon, 23 Jan 2006 10:53:28 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0NFhUBJ020630; Mon, 23 Jan 2006 15:43:30 GMT (envelope-from raymond.forbes@marconi.com) In-Reply-To: MIME-Version: 1.0 To: hannes.tschofenig@siemens.com Subject: Re: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Mon, 23 Jan 2006 15:46:18 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/01/2006 15:43:30, Serialize complete at 23/01/2006 15:43:30 X-Spam-Score: 0.0 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1839634504==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1839634504== Content-Type: multipart/alternative; boundary="=_alternative 00565465802570FF_=" This is a multipart message in MIME format. --=_alternative 00565465802570FF_= Content-Type: text/plain; charset="US-ASCII" Hannes, See [RCF]: Below [RCF]: According to the EU Data protection and Privacy Directive EU Citizens have a right to not have their location traced, unless they chose to reveal their location to the respondent; with three Legal exceptions. An example of illicit tracking may be that robbers will know when to break into your house if they know that you are in another country. Another example is that local SPAM may be directed to your terminal as a nescience. Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Tschofenig, Hannes" 22/01/2006 17:46 To: "Raymond Forbes" , cc: Subject: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt [hannes] we had a long discussion about the term location validation and i think that we use the terms differently. do you have a pointer to your definition? [RCF]: Read EU Commission Recommendation C(2003) 2657 ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This is an option allowed in Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt [hannes] i have to read into the details of ETSI TS 102 164 but the described scenario seems to be supported by the requirements draft. the ability for an outbound proxy to perform location-based routing is clearly in scope of our work. the ability of using the sip identity work is also allowed and might be quite useful. Real Geographic mapping in the TS 102 164 is calculated within the PSAP by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does not need to be mentioned. It is almost the same as the case (8), acquisition of Location Information by a Call Routing Entity in Title: Security Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8 Requirements for Interface . Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means that User's location cannot be held on a Publically accessible directory database. [hannes] here is the paragraph you are referring to: ( http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 01.txt) " 3. The timeliness, integrity and privacy of call signalling must be ensured as it passes between the emergency caller's device and the PSAP. NOTE - a confidentiality requirement applies to the association of a location with an emergency (e.g., within call signalling) or with an individual. The location data per se is not confidential. " i would like to hear your opinion about the following security aspect. we have two places where confidentiality protection is applicable: a) between the access network and the end host when location information is provided by the access network to the end host (e.g., using dhcp as described in http://www.ietf.org/rfc/rfc3825.txt and in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt ) b) as part of the emergency call itself. what problems do you see if confidentiality protection is not applied at (a) and/or at (b) (with regard to the above-mentioned law)? [RCF]: I can agree Option a) above, Option B is also true but is a human risk that people who know call content, including Location data may misuse their knowledge. I am not suggesting that there is a requirement to encrypt Emergency sessions, Or at least not from this EU data protection requirement. [RCF]: According to the EU Data protection and Privacy Directive EU Citizens have a right to not have their location traced, unless they chose to reveal their location to the respondent; with three Legal exceptions. An example of illicit tracking may be that robbers will know when to break into your house if they know that you are in another country. Another example is that local SPAM may be directed to your terminal as a nescience. [RCF]: There may be a general concern that communication across the public Internet is more easily eavesdropped (casually intercepted by unauthorised individuals) than communication across a private network (IP based or Circuit switched) Secondly, I have one question about the Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve a limited geographic region, ..." [hannes] maybe the term 'limited' should be read as 'specific'. the size of the region, however, does not matter for the purpose of location-based routing or for the mapping protocol. as such, it does not matter. [RCF]: I think there is room for agreement the around the text; I think that I agree with Brian on this that the Region is Limited to be within a Specific Nation it may be a more locally or specifically defined region with a nation. It may be the Entire National Area (in the case of Luxembourg for example). Ciao hannes Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Tschofenig, Hannes" Sent by: "emtel : Emtel" 09/01/2006 22:47 Please respond to "Tschofenig, Hannes" To: EMTEL@LIST.ETSI.ORG cc: Subject: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt hi all, a new version of our requirements document is available. please send review comments to the mailing list (see http://www.ietf.org/html.charters/ecrit-charter.html). ------------------------- Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-02.txt Pages : 27 Date : 2006-1-3 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt ------------------------- ciao hannes ------------------------------------------------------------------- Mail archive for EMTEL can be browsed at the following url: http://list.etsi.org/EMTEL.html ------------------------------------------------------------------- --=_alternative 00565465802570FF_= Content-Type: text/html; charset="US-ASCII"
Hannes,

See [RCF]: Below

[RCF]: According to the EU Data protection and Privacy Directive EU Citizens have a right to not have their location traced, unless they chose to reveal their location to the respondent; with three Legal exceptions. An example of illicit tracking may be that robbers will know when to break into your house if they know that you are in another country. Another example is that local SPAM may be directed to your terminal as a nescience.  

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


"Tschofenig, Hannes" <hannes.tschofenig@siemens.com>

22/01/2006 17:46

       
        To:        "Raymond Forbes" <raymond.forbes@marconi.com>, <ecrit@ietf.org>
        cc:        
        Subject:        AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt




[hannes] we had a long discussion about the term location validation and
i think that we use the terms differently.
do you have a pointer to your definition?

[RCF]: Read EU Commission Recommendation C(2003) 2657

                ETSI TS 102 164 Assumes that he Routing toward the PSAP is
generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward
the PSAP will be from Asserted Identity Information added of validated
by the ESRP; This is an option allowed in Title: Requirements for
Emergency Context Resolution with Internet Technologies Author(s): H.
Schulzrinne, R. Marshall
                Filename: draft-ietf-ecrit-requirements-02.txt
               

[hannes] i have to read into the details of ETSI TS 102 164 but the
described scenario seems to be supported by the requirements draft. the
ability for an outbound proxy to perform location-based  routing is
clearly in scope of our work. the ability of using the sip identity work
is also allowed  and might be quite useful.


                Real Geographic mapping in the TS 102 164 is calculated within
the PSAP by secure look up into the operators "directory" databases (by
a Private service IP link). The EU has special provision to allow and
require this with the EU data protection Directive. This is not
mentioned, but does not need to be mentioned. It is almost the same as
the case (8), acquisition of Location Information by a Call Routing
Entity in Title: Security Threats and Requirements for Emergency Calling
Author(s): H. Schulzrinne, et al. Filename:
draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8
Requirements for Interface .

               
                Firstly, Security Threats and Requirements for Emergency Calling
draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note
is not be true according to European Directive and Europe-wide laws. The
EU data protection directive states that Location is Private data to the
user that must be secured under the user's right to reveal, withstanding
the three very clear legal exceptions: which are 1. National Security;
2. Criminal Activity and 3. making an Emergency call or Request to the
Emergency services. These Authority must legally respect the rights of
the User not to reveal the location to third parties and commercial
organisations. I suggest that you delete the note. EU Directives and
European-wide law covers at least 30 countries. Under EU Directives the
User's Location is Private data that cannot be revealed except on the
commercial request of the User for a Location based service or under one
of the three provisions. The user's location falling inadvertently into
the wrong hands is a security threat that you do not mention. This means
that User's location cannot be held on a Publically accessible directory
database.

               

[hannes] here is the paragraph you are referring to:
(
http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-
01.txt)

"
  3.  The timeliness, integrity and privacy of call signalling must be
      ensured as it passes between the emergency caller's device and
      the PSAP.

         NOTE - a confidentiality requirement applies to the
         association of a location with an emergency (e.g., within call
         signalling) or with an individual.  The location data per se
         is not confidential.
"

i would like to hear your opinion about the following security aspect.
we have two places where confidentiality protection
is applicable:

a) between the access network and the end host when location information
is provided by the access network to the end host (e.g., using dhcp as
described in http://www.ietf.org/rfc/rfc3825.txt and in
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt
)

b) as part of the emergency call itself.

what problems do you see if confidentiality protection is not applied at
(a) and/or at (b) (with regard to the above-mentioned law)?

[RCF]: I can agree Option a) above, Option B is also true but is a human risk that people who know call content, including Location data may misuse their knowledge. I am not suggesting that there is a requirement to encrypt Emergency sessions, Or at least not from this EU data protection requirement.

[RCF]: According to the EU Data protection  and Privacy Directive EU Citizens have a right to not have their location traced, unless they chose to reveal their location to the respondent; with three Legal exceptions. An example of illicit tracking may be that robbers will know when to break into your house if they know that you are in another country. Another example is that local SPAM may be directed to your terminal as a nescience.  

[RCF]: There may be a general concern that communication across the public Internet is more easily eavesdropped (casually intercepted by unauthorised individuals) than communication across a private network (IP based or Circuit switched)

                Secondly, I have one question about the Requirements for
Emergency Context Resolution with Internet Technologies Author(s): H.
Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt
on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states
that the "PSAPS only serve a limited geographic region, ..." This in not
True. It may be true in the US and Germany, but in many countries the
PSAPs may server a wide area. The problem will be solved if the Words
are changed to "PSAPS may only serve a limited geographic region, ..."
               

[hannes] maybe the term 'limited' should be read as 'specific'. the size
of the region, however, does not matter for the purpose of
location-based routing or for the mapping protocol. as such, it does not
matter.

[RCF]: I think there is room for agreement the around the text; I think that I agree with Brian on this that the Region is Limited to be within a Specific Nation it may be a more locally or specifically defined region with a nation. It may be the Entire National Area (in the case of Luxembourg for example).

Ciao
hannes

               
                Regards,
               
                Ray Forbes.
               
                +44 24 7656 3106 phone
                +44 24 7656 3816 fax.
                +44 771 851 1361 Mobile/text
                ------------
                This e-mail and any attachments are confidential.  If you are
not the intended recipient, please notify us immediately by reply e-mail
and then delete this message from your system. Do not copy this e-mail
or any attachments, use the contents for any purpose, or disclose the
contents to any other person: to do so could be a breach of confidence.
               
               
               
               
                                 "Tschofenig, Hannes" <hannes.tschofenig@SIEMENS.COM>
                Sent by: "emtel : Emtel" <EMTEL@LIST.ETSI.ORG>

                09/01/2006 22:47
                Please respond to "Tschofenig, Hannes"

                                         
                        To:        EMTEL@LIST.ETSI.ORG
                        cc:        
                        Subject:        [EMTEL] I-D
ACTION:draft-ietf-ecrit-requirements-02.txt



                hi all,
               
                a new version of our requirements document is available. please
send
                review comments to the mailing list (see
                http://www.ietf.org/html.charters/ecrit-charter.html).
               
                -------------------------
               
                Title                : Requirements for Emergency Context
Resolution
                with Internet Technologies
                Author(s)        : H. Schulzrinne, R. Marshall
                Filename        : draft-ietf-ecrit-requirements-02.txt
                Pages                : 27
                Date                : 2006-1-3
               
                This document enumerates requirements for emergency calls placed
by
                the public using voice-over-IP (VoIP) and general Internet
multimedia
                systems, where Internet protocols are used end-to-end.
               
                A URL for this Internet-Draft is:
               
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt
               
               
                -------------------------
               
               
                ciao
                hannes
               
               
-------------------------------------------------------------------
                Mail archive for EMTEL can be browsed at the following url:
                http://list.etsi.org/EMTEL.html
               
-------------------------------------------------------------------
               
               


--=_alternative 00565465802570FF_=-- --===============1839634504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1839634504==-- From ecrit-bounces@ietf.org Mon Jan 23 10:51:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13ym-0002VO-74; Mon, 23 Jan 2006 10:51:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13yk-0002V1-6W for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 10:51:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29053 for ; Mon, 23 Jan 2006 10:50:09 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1486-0002qD-Cg for ecrit@ietf.org; Mon, 23 Jan 2006 11:01:19 -0500 Received: from lion.cs.columbia.edu (IDENT:kqOIW4R2ss9prwRtAV2/2/sE1UEMXpoZ@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0NFpGKG018527 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 23 Jan 2006 10:51:32 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0NFpGnE010199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Jan 2006 10:51:16 -0500 Message-ID: <43D4FB6E.6080305@cs.columbia.edu> Date: Mon, 23 Jan 2006 10:51:10 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Raymond Forbes Subject: Re: [Ecrit] Issue 30: Summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As was discussed previously, the 'longer list of numbers' approach isn't as workable for SIP, since (unlike for GSM), we also need to deal with PBX systems, where 3-digit extensions are common. I think the 112/911 default list, however, is quite workable in practice. (The biggest problem with that is that '9' is the common escape digit to get an outside line so that in many PBX systems, you actually have to dial 9-911 to reach a PSAP.) Raymond Forbes wrote: > > I was only pointing to the example in GSM (3GPP) today where there most > commonly used global numbers are stored in all SIM modules, and further > local national numbers may be additionally stored. > > This alleviates the need for having a Global address as the > Roaming/Nomadic terminal inter-works with the region it is in. A global > address has certain advantages. > > The GSM solution requires that other national numbers not in the Prime > list may be additionally stored. > > This solves the problem of encountered my the majority of tourists, US > or Japanese Tourists in London. who do not know that their national > number (911 or 110) needs translating to 112. It does not solve all > problems. For example 110 in Germany will reach the Police not the > Emergency services. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 11:19:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14Ph-00009R-M1; Mon, 23 Jan 2006 11:19:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14Pf-00009K-SO for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 11:19:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00334 for ; Mon, 23 Jan 2006 11:17:58 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14Z3-0003av-69 for ecrit@ietf.org; Mon, 23 Jan 2006 11:29:09 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0NGIiNI028052; Mon, 23 Jan 2006 16:18:45 GMT (envelope-from raymond.forbes@marconi.com) In-Reply-To: <43D4FB6E.6080305@cs.columbia.edu> To: "Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Summary MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Mon, 23 Jan 2006 16:21:35 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/01/2006 16:18:46, Serialize complete at 23/01/2006 16:18:46 X-Spam-Score: 2.4 (++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1477867098==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1477867098== Content-Type: multipart/alternative; boundary="=_alternative 00598E60802570FF_=" This is a multipart message in MIME format. --=_alternative 00598E60802570FF_= Content-Type: text/plain; charset="US-ASCII" The common PBX escape digit may be 9 in the UK and US, but it is 0 in most of the world. so 9-911, 9-112 and 0-112 would all be required. Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. Henning Schulzrinne 23/01/2006 15:51 To: Raymond Forbes cc: mhammer@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary As was discussed previously, the 'longer list of numbers' approach isn't as workable for SIP, since (unlike for GSM), we also need to deal with PBX systems, where 3-digit extensions are common. I think the 112/911 default list, however, is quite workable in practice. (The biggest problem with that is that '9' is the common escape digit to get an outside line so that in many PBX systems, you actually have to dial 9-911 to reach a PSAP.) Raymond Forbes wrote: > > I was only pointing to the example in GSM (3GPP) today where there most > commonly used global numbers are stored in all SIM modules, and further > local national numbers may be additionally stored. > > This alleviates the need for having a Global address as the > Roaming/Nomadic terminal inter-works with the region it is in. A global > address has certain advantages. > > The GSM solution requires that other national numbers not in the Prime > list may be additionally stored. > > This solves the problem of encountered my the majority of tourists, US > or Japanese Tourists in London. who do not know that their national > number (911 or 110) needs translating to 112. It does not solve all > problems. For example 110 in Germany will reach the Police not the > Emergency services. > --=_alternative 00598E60802570FF_= Content-Type: text/html; charset="US-ASCII"
The common PBX escape digit may be 9 in the UK and US, but it is 0 in most of the world.

so 9-911, 9-112 and 0-112 would all be required.

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


Henning Schulzrinne <hgs@cs.columbia.edu>

23/01/2006 15:51

       
        To:        Raymond Forbes <raymond.forbes@marconi.com>
        cc:        mhammer@cisco.com, ecrit@ietf.org
        Subject:        Re: [Ecrit] Issue 30: Summary



As was discussed previously, the 'longer list of numbers' approach isn't
as workable for SIP, since (unlike for GSM), we also need to deal with
PBX systems, where 3-digit extensions are common.

I think the 112/911 default list, however, is quite workable in
practice. (The biggest problem with that is that '9' is the common
escape digit to get an outside line so that in many PBX systems, you
actually have to dial 9-911 to reach a PSAP.)

Raymond Forbes wrote:
>
> I was only pointing to the example in GSM (3GPP) today where there most
> commonly used global numbers are stored in all SIM modules, and further
> local national numbers may be additionally stored.
>
> This alleviates the need for having a Global address as the
> Roaming/Nomadic terminal inter-works with the region it is in. A global
> address has certain advantages.
>
> The GSM solution requires that other national numbers not in the Prime
> list may be additionally stored.
>
> This solves the problem of encountered my the majority of tourists, US
> or Japanese Tourists in London. who do not know that their national
> number (911 or 110) needs translating to 112. It does not solve all
> problems. For example 110 in Germany will reach the Police not the
> Emergency services.
>

--=_alternative 00598E60802570FF_=-- --===============1477867098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1477867098==-- From ecrit-bounces@ietf.org Mon Jan 23 11:47:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14qb-0007PM-Hd; Mon, 23 Jan 2006 11:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14qa-0007P5-4e for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 11:47:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01868 for ; Mon, 23 Jan 2006 11:45:46 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14zv-0004R1-Mj for ecrit@ietf.org; Mon, 23 Jan 2006 11:56:58 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0NGlAvI007135Mon, 23 Jan 2006 16:47:10 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F14qU-00065R-00; Mon, 23 Jan 2006 16:47:10 +0000 Date: Mon, 23 Jan 2006 16:47:10 +0000 From: "Clive D.W. Feather" To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] Issue 30: Summary Message-ID: <20060123164710.GE3821@finch-staff-1.thus.net> References: <072C5B76F7CEAB488172C6F64B30B5E301030C9F@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301030C9F@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) said: > Not necessarily an issue, but I need to be able to correctly parse the > sentence. > > > When you talk about "emergency numbers", are you referring > > to an E.164 > > > number that the "emergency dial string" gets translated to? > > > > And what if there isn't such a thing? What if the "emergency dial string" is not translated to an E.164 number, but is simply routed directly through the network? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 11:55:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14yu-00018v-Jt; Mon, 23 Jan 2006 11:55:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14ys-00018q-Io for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 11:55:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02280 for ; Mon, 23 Jan 2006 11:54:21 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F158G-0004gr-Gk for ecrit@ietf.org; Mon, 23 Jan 2006 12:05:32 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F14yp-0003eM-Sk; Mon, 23 Jan 2006 10:55:48 -0600 From: "Brian Rosen" To: "'Clive D.W. Feather'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 11:53:53 -0500 Message-ID: <04d601c6203d$99ba86f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060123164710.GE3821@finch-staff-1.thus.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYgPMyjVBqbUgZ6Sja22HPHgCHPvQAADaQw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org "Routed through the network"? Few systems do this, but ones where the only emergency number is an E.164 do. In our work, we interpret an emergency dialstring within a dial plan to the universal emergency identifier. Then we map that, using the mechanisms we are discussing here in ecrit, to some routable URI, be it a tel URI routed as any other tel URI would, a SIP URI, routed as any other SIP URI would, etc. If in some location, mapping yields an e.164 in a tel uri, then we would route it appropriately, perhaps using an enum dip, ... Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Clive D.W. Feather Sent: Monday, January 23, 2006 11:47 AM To: Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary Michael Hammer (mhammer) said: > Not necessarily an issue, but I need to be able to correctly parse the > sentence. > > > When you talk about "emergency numbers", are you referring > > to an E.164 > > > number that the "emergency dial string" gets translated to? > > > > And what if there isn't such a thing? What if the "emergency dial string" is not translated to an E.164 number, but is simply routed directly through the network? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 11:58:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F151B-0001UN-Cp; Mon, 23 Jan 2006 11:58:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F151A-0001Tx-Bf for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 11:58:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02402 for ; Mon, 23 Jan 2006 11:56:42 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F15AW-0004kp-Gn for ecrit@ietf.org; Mon, 23 Jan 2006 12:07:54 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2006 11:58:01 -0500 X-IronPort-AV: i="4.01,212,1136178000"; d="scan'208,217"; a="80790577:sNHT49997276" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0NGvV6d026130; Mon, 23 Jan 2006 11:57:59 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 11:57:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 11:57:57 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301030D98@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgOLk71ikoMUtsSKezTsHZnqgoqQABQDoA From: "Michael Hammer \(mhammer\)" To: "Raymond Forbes" , "Henning Schulzrinne X-OriginalArrivalTime: 23 Jan 2006 16:57:58.0671 (UTC) FILETIME=[29B951F0:01C6203E] X-Spam-Score: 0.7 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571227884==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0571227884== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6203E.29617DF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6203E.29617DF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But, such digits are not part of the emergency string, though they are also part of the dial string. On my cell phone, I also have to push the "power-on" button, but I don't think it necessary to go down such rat-holes. =20 Mike =20 ________________________________ From: Raymond Forbes [mailto:raymond.forbes@marconi.com]=20 Sent: Monday, January 23, 2006 11:22 AM To: Henning Schulzrinne =20 23/01/2006 15:51=20 =20 To: Raymond Forbes =20 cc: mhammer@cisco.com, ecrit@ietf.org=20 Subject: Re: [Ecrit] Issue 30: Summary As was discussed previously, the 'longer list of numbers' approach isn't=20 as workable for SIP, since (unlike for GSM), we also need to deal with=20 PBX systems, where 3-digit extensions are common. =09 I think the 112/911 default list, however, is quite workable in=20 practice. (The biggest problem with that is that '9' is the common=20 escape digit to get an outside line so that in many PBX systems, you=20 actually have to dial 9-911 to reach a PSAP.) =09 Raymond Forbes wrote: >=20 > I was only pointing to the example in GSM (3GPP) today where there most=20 > commonly used global numbers are stored in all SIM modules, and further=20 > local national numbers may be additionally stored. >=20 > This alleviates the need for having a Global address as the=20 > Roaming/Nomadic terminal inter-works with the region it is in. A global=20 > address has certain advantages. >=20 > The GSM solution requires that other national numbers not in the Prime=20 > list may be additionally stored. >=20 > This solves the problem of encountered my the majority of tourists, US=20 > or Japanese Tourists in London. who do not know that their national=20 > number (911 or 110) needs translating to 112. It does not solve all=20 > problems. For example 110 in Germany will reach the Police not the=20 > Emergency services. >=20 =09 =09 ------_=_NextPart_001_01C6203E.29617DF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
But, such digits are not part of the emergency string, = though they=20 are also part of the dial string.  On my cell phone, I also have to = push=20 the "power-on" button, but I don't think it necessary to go down such=20 rat-holes.
 
Mike
 

From: Raymond Forbes=20 [mailto:raymond.forbes@marconi.com]
Sent: Monday, January = 23, 2006=20 11:22 AM
To: Henning Schulzrinne <hgs
Cc:=20 ecrit@ietf.org; Michael Hammer (mhammer)
Subject: Re: = [Ecrit] Issue=20 30: Summary


The common PBX escape = digit may be=20 9 in the UK and US, but it is 0 in most of the world. =

so 9-911, 9-112 and 0-112 would all be = required.=20

Regards,

Ray = Forbes.

+44 24=20 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361=20 Mobile/text
------------
This e-mail and any attachments are=20 confidential.  If you are not the intended recipient, please = notify us=20 immediately by reply e-mail and then delete this message from your = system. Do=20 not copy this e-mail or any attachments, use the contents for any = purpose, or=20 disclose the contents to any other person: to do so could be a breach = of=20 confidence.



Henning Schulzrinne=20 <hgs@cs.columbia.edu>=20

23/01/2006 15:51

        =
        To: =    =20    Raymond Forbes = <raymond.forbes@marconi.com>=20
        = cc:  =20      mhammer@cisco.com, ecrit@ietf.org =
        Subject: =  =20      Re: [Ecrit] Issue 30:=20 Summary



As = was=20 discussed previously, the 'longer list of numbers' approach isn't =
as=20 workable for SIP, since (unlike for GSM), we also need to deal with =
PBX=20 systems, where 3-digit extensions are common.

I think the = 112/911=20 default list, however, is quite workable in
practice. (The biggest = problem=20 with that is that '9' is the common
escape digit to get an outside = line so=20 that in many PBX systems, you
actually have to dial 9-911 to reach = a=20 PSAP.)

Raymond Forbes wrote:
>
> I was only = pointing to=20 the example in GSM (3GPP) today where there most
> commonly = used global=20 numbers are stored in all SIM modules, and further
> local = national=20 numbers may be additionally stored.
>
> This alleviates = the need=20 for having a Global address as the
> Roaming/Nomadic terminal=20 inter-works with the region it is in. A global
> address has = certain=20 advantages.
>
> The GSM solution requires that other = national=20 numbers not in the Prime
> list may be additionally = stored.
>=20
> This solves the problem of encountered my the majority of = tourists,=20 US
> or Japanese Tourists in London. who do not know that their = national
> number (911 or 110) needs translating to 112. It = does not=20 solve all
> problems. For example 110 in Germany will reach the = Police=20 not the
> Emergency services.
>=20

------_=_NextPart_001_01C6203E.29617DF8-- --===============0571227884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0571227884==-- From ecrit-bounces@ietf.org Mon Jan 23 12:24:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F15QV-0000wR-2l; Mon, 23 Jan 2006 12:24:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F15QT-0000wF-06 for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 12:24:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04062 for ; Mon, 23 Jan 2006 12:22:51 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F15Zp-0005d3-SB for ecrit@ietf.org; Mon, 23 Jan 2006 12:34:03 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0NHOGoB020650Mon, 23 Jan 2006 17:24:17 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F15QO-00071h-00; Mon, 23 Jan 2006 17:24:16 +0000 Date: Mon, 23 Jan 2006 17:24:16 +0000 From: "Clive D.W. Feather" To: Stastny Richard Subject: Re: [Ecrit] Issue 30: Summary Message-ID: <20060123172416.GF3821@finch-staff-1.thus.net> References: <32755D354E6B65498C3BD9FD496C7D461B235F@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B235F@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard said: > I suggest the following: > > The global emergency dial strings 911 and 112 MUST be supported by any > device I can find you 30 locations in the UK where 911345 is a valid dial string leading to a local telephone number. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 12:35:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F15b8-00040v-HM; Mon, 23 Jan 2006 12:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F15b5-00040k-Uz for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 12:35:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04866 for ; Mon, 23 Jan 2006 12:33:50 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F15kS-0005zL-Ux for ecrit@ietf.org; Mon, 23 Jan 2006 12:45:02 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0NHZEYr023373Mon, 23 Jan 2006 17:35:14 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F15b0-0007GG-00; Mon, 23 Jan 2006 17:35:14 +0000 Date: Mon, 23 Jan 2006 17:35:14 +0000 From: "Clive D.W. Feather" To: Brian Rosen Subject: Re: [Ecrit] Issue 30: Summary Message-ID: <20060123173514.GG3821@finch-staff-1.thus.net> References: <20060123164710.GE3821@finch-staff-1.thus.net> <04d601c6203d$99ba86f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04d601c6203d$99ba86f0$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen said: > "Routed through the network"? Few systems do this, but ones where the only > emergency number is an E.164 do. > > In our work, we interpret an emergency dialstring within a dial plan to the > universal emergency identifier. Then we map that, using the mechanisms we > are discussing here in ecrit, to some routable URI, be it a tel URI routed > as any other tel URI would, a SIP URI, routed as any other SIP URI would, > etc. We seem to be at cross-purposes. Someone seemed to be suggesting that any diallable (in the PSTN) emergency number mapped to an E.164 number, so enum systems could look up the latter. The only point I was trying to make is that in some countries there *is* no such E.164 number. E.g. in the UK "999" (on landlines, at least) is handled by special routeing in the telephone network, not by mapping it to an E.164 number. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 13:08:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F167Q-0004Qw-61; Mon, 23 Jan 2006 13:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F167O-0004Qm-3u for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 13:08:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06780 for ; Mon, 23 Jan 2006 13:07:11 -0500 (EST) Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F16Gj-00075W-EK for ecrit@ietf.org; Mon, 23 Jan 2006 13:18:24 -0500 Received: from ([90.152.52.46]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.104365442; Mon, 23 Jan 2006 13:08:05 -0500 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Jan 2006 12:08:05 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 12:08:05 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD19@bre2k61p-55> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgK8FRvBwnKPVJTyazk7qv6H0YPwAAQC1wAADYUoAAAHt/YAAAQd1g From: "Stark, Barbara" To: "Stastny Richard" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 23 Jan 2006 18:08:05.0475 (UTC) FILETIME=[F52CAB30:01C62047] X-Spam-Score: 0.9 (/) X-Scan-Signature: 34793307b79a1353c9d03ed8a398bb86 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1558919534==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1558919534== Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62047.F4E5C109" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62047.F4E5C109 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not all VoIP or SIP implementations are GSM or specified through 3GPP. I really don't think the IETF or ecrit has any business specifying emergency dial strings. That is the business of regulatory bodies that have jurisdiction over the offered SIP service. The ecrit architecture is completely independent of any particular dial string. All ecrit needs to be requiring is something like: =20 UAs MUST be able to recognize emergency dial strings, and translate these strings into the global emergency SIP URI (). =20 UAs MUST be able to support mapping of all "home" emergency dial strings, consistent with the "home" dialing plan of the UA. =20 By the way, it's come as quite a revelation to myself and my colleagues that our GSM phones do, indeed, support 112 (we've confirmed this with our cell colleagues). None of us had any idea that this was so. I'd be willing to go out on a limb and say that probably well over 99% of the people in the US have absolutely no idea that their GSM phones support 112. In fact, most people here are completely unaware that 112 is the EU emergency number, or that it's supposed to be a globally recognized GSM emergency number. My dual mode handset (GSM + WiFi, with outbound WiFi calls going to IP PBX) only supports 112 when in GSM mode. Since the IP PBX doesn't support 112, 112 doesn't work when the phone is in WiFi mode. 911 is supported in both modes. =20 Speaking of PBXs, most PBXs in the US will recognize "911", independent of any prefix that may be used for normal outbound dialing. They will also recognize + 911. While "9" is commonly used as a prefix, it's by no means a standard. From my desktop IP phone, I have to dial "99" as a prefix. If a requirement is desired that references IP PBX prefixes, perhaps: =20 If a prefix is normally required for outside-line dialing by a UA, the UA SHOULD support mapping of emergency dial strings with or without the prefix. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Monday, January 23, 2006 10:33 AM To: Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary IMHO basically all folks from countries having GSM implemented will accept or at least will know about 112, which includes all regions you mentioned Richard =20 =20 =20 _____ =20 From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Monday, January 23, 2006 4:19 PM To: Stastny Richard Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 I like your approach, but have only one question. =20 Do folks from Asia, Africa, Australia, and South America accept that 911 and 112 are the global emergency dial strings? =20 Mike =20 =20 _____ =20 From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, January 23, 2006 10:06 AM To: Raymond Forbes; Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary I am really getting tired of this discussion, which goes on now for years, simply because there is no solution to have home and local emergency dial strings working in any case because of conflicts that are not resolvable on a global scale, and especially NOT by ECRIT. =20 Since any user needs to have a dial plan agreed upon with his provider (which will be in most cases the home dial plan) and this dial plan can be configured into the device =20 I suggest the following: =20 The global emergency dial strings 911 and 112 MUST be supported by any device and MUST be mapped to the default sos identifier In addition, the emergency dial strings supported in the home dial plan MUST be supported and mapped accordingly =20 Local emergency dial strings may be supported if there exists no conflict. If the device is not aware of the local emergency dial strings or conflicting other dial strings, it MUST NOT support these dial strings (in doubt) =20 VoIP users should be made aware at subscription time that they SHALL only use 911 or 112 when abroad (also by NENA and EENA) =20 Regards Richard =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes Sent: Monday, January 23, 2006 3:23 PM To: mhammer@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.=20 This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages.=20 The GSM solution requires that other national numbers not in the Prime list may be additionally stored.=20 This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services.=20 Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =20 "Michael Hammer \(mhammer\)" =20 23/01/2006 13:45=20 =20 To: "Hannes Tschofenig" , "Raymond Forbes" =20 cc: , =20 Subject: RE: [Ecrit] Issue 30: Summary Hannes, We still seem to be glossing over terms and usage it seems. When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? Mike=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number=20 > (because it =20 > > > does > not know the local emergency number) and the home=20 > emergency=20 > > number is > different from the local emergency number and=20 > Alice/Bob=20 > > have different > home emergency numbers. > > > > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 118 ------_=_NextPart_001_01C62047.F4E5C109 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not=20 all VoIP or SIP implementations are GSM or specified through 3GPP. I = really=20 don't think the IETF or ecrit has any business specifying emergency dial = strings. That is the business of regulatory bodies that have = jurisdiction over=20 the offered SIP service. The ecrit architecture is completely = independent of any=20 particular dial string. All ecrit needs to be requiring is something=20 like:
 
UAs=20 MUST be able to recognize emergency dial strings, and translate these = strings=20 into the global emergency SIP URI (<reference to future=20 RFC>).
 
UAs=20 MUST be able to support mapping of all "home" emergency dial strings, = consistent=20 with the "home" dialing plan of the UA.
 
By the=20 way, it's come as quite a revelation to myself and my colleagues that = our GSM=20 phones do, indeed, support 112 (we've confirmed this with our cell = colleagues).=20 None of us had any idea that this was so. I'd be willing to go out on a = limb and=20 say that probably well over 99% of the people in the US have absolutely = no idea=20 that their GSM phones support 112. In fact, most people here = are=20 completely unaware that 112 is the EU emergency number, or that it's = supposed to=20 be a globally recognized GSM emergency number. My dual mode handset = (GSM +=20 WiFi, with outbound WiFi calls going to IP PBX) only supports 112 when = in GSM=20 mode. Since the IP PBX doesn't support 112, 112 doesn't work when the = phone is=20 in WiFi mode. 911 is supported in both modes.
 
Speaking of PBXs, most PBXs in the US will = recognize=20 "911", independent of any prefix that may be used for normal outbound = dialing.=20 They will also recognize <prefix> + 911. While "9" is commonly = used as a=20 prefix, it's by no means a standard. From my desktop IP phone, I have to = dial=20 "99" as a prefix. If a requirement is desired that references IP PBX = prefixes,=20 perhaps:
 
If a=20 prefix is normally required for outside-line dialing by a UA, the UA = SHOULD=20 support mapping of emergency dial strings with or without the=20 prefix.
Barbara
-----Original Message-----
From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org]On Behalf Of Stastny=20 Richard
Sent: Monday, January 23, 2006 10:33 = AM
To:=20 Michael Hammer (mhammer)
Cc: = ecrit@ietf.org
Subject: RE:=20 [Ecrit] Issue 30: Summary

IMHO = basically all=20 folks from countries having GSM implemented will accept or
at least = will=20 know about 112, which includes all regions you=20 mentioned

Richard

 

 

 

From: Michael=20 Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Monday, January 23, 2006 = 4:19=20 PM
To: Stastny=20 Richard
Cc:=20 ecrit@ietf.org
Subject: RE:=20 [Ecrit] Issue 30: Summary

 

I like = your=20 approach, but have only one question.

 

Do folks = from Asia,=20 Africa, Australia, and South America accept that 911 and 112 are the = global=20 emergency dial strings?

 

Mike

 

 

From: Stastny Richard=20 [mailto:Richard.Stastny@oefeg.at]
Sent: Monday, January 23, = 2006 10:06=20 AM
To: Raymond = Forbes;=20 Michael Hammer (mhammer)
Cc: = ecrit@ietf.org
Subject: RE: [Ecrit] Issue = 30:=20 Summary

I am = really getting=20 tired of this discussion, which goes on now for years,
simply = because=20 there is no solution to have home and local emergency
dial = strings=20 working in any case because of conflicts that are not = resolvable
on a=20 global scale, and especially NOT by = ECRIT.

 

Since any = user=20 needs to have a dial plan agreed upon with his provider
(which = will be in=20 most cases the home dial plan) and this dial plan
can be = configured into=20 the device

 

I suggest = the=20 following:

 

The = global=20 emergency dial strings 911 and 112 MUST be supported by any=20 device

and MUST = be mapped=20 to the default sos identifier
In addition, the emergency dial = strings=20 supported in the home dial plan MUST be=20 supported

and = mapped=20 accordingly

 

Local = emergency=20 dial strings may be supported if there exists no conflict. If the=20 device
is not aware of the local emergency dial strings or = conflicting=20 other dial strings, it MUST NOT
support these dial strings (in=20 doubt)

 

VoIP = users should=20 be made aware at subscription time that they SHALL only use
911 = or 112=20 when abroad (also by NENA and EENA)

 

Regards

Richard

 

From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of Raymond Forbes
Sent: Monday, January 23, = 2006 3:23=20 PM
To: = mhammer@cisco.com
Cc: = ecrit@ietf.org
Subject: RE: [Ecrit] Issue = 30:=20 Summary

 


I was = only pointing=20 to the example in GSM (3GPP) today where there most commonly used = global=20 numbers are stored in all SIM modules, and further local national = numbers=20 may be additionally stored.

This = alleviates the=20 need for having a Global address as the Roaming/Nomadic terminal = inter-works=20 with the region it is in. A global address has certain=20 advantages.

The GSM solution = requires that=20 other national numbers not in the Prime list may be additionally=20 stored.

This solves the = problem of=20 encountered my the majority of tourists, US or Japanese Tourists in = London.=20 who do not know that their national number (911 or 110) needs = translating to=20 112. It does not solve all problems. For example 110 in Germany will = reach=20 the Police not the Emergency services.

Regards,

Ray=20 Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 = fax.
+44 771=20 851 1361 Mobile/text
------------
This e-mail and any = attachments are=20 confidential.  If you are not the intended recipient, please = notify us=20 immediately by reply e-mail and then delete this message from your = system.=20 Do not copy this e-mail or any attachments, use the contents for any = purpose, or disclose the contents to any other person: to do so = could be a=20 breach of confidence.

 

"Michael=20 Hammer \(mhammer\)" = <mhammer@cisco.com>=20

23/01/2006=20 13:45

    =  =20  
    =  =20   To:        "Hannes Tschofenig"=20 <Hannes.Tschofenig@gmx.net>, "Raymond Forbes"=20 <raymond.forbes@marconi.com>
 =20       cc:      =20  <ecrit-bounces@ietf.org>,=20 <ecrit@ietf.org>
    =  =20   Subject:        RE: [Ecrit] Issue = 30:=20 Summary




Hannes,

We still seem to be glossing over terms and = usage it=20 seems.

When you = talk about=20 "emergency numbers", are you referring to an = E.164
number that the "emergency dial string" gets = translated=20 to?  Or, just
that 3 digit=20 emergency code?

Also, you=20 seem to suggest that each of the hundred or so emergency=20 dial
strings (112, = 911, etc.)=20 are reserved for emergency use globally.=20  Right
now I = understand=20 there are some conflicts.  Are you proposing that=20 all
those emergency = codes be=20 reserved for emergency use in all = countries.
That is, where any of those codes is used for = another=20 purpose, that
country = must=20 change their usage?  So, that the tourist from any=20 country
can visit any = country=20 and any emergency code will work?

Mike

> -----Original = Message-----
> From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org]
> On Behalf Of Hannes=20 Tschofenig
> Sent: = Monday,=20 January 23, 2006 5:15 AM
>=20 To: Raymond Forbes
> Cc:=20 ecrit-bounces@ietf.org; ecrit@ietf.org
> Subject: Re: [Ecrit] Issue 30:=20 Summary
>=20
> hi=20 raymond,
>=20
>=20 ~snip~
>=20
> >  > =   *=20 Tourist Alice collapses, another tourist Bob finds the=20 cell
> > =  > phone=20 of Alice and dials its own home emergency number =
> (because it =  
> > > does  > not know the = local=20 emergency number) and the home
> emergency
> > number is  > different from = the local=20 emergency number and
>=20 Alice/Bob
> > = have=20 different  > home emergency = numbers.
> >  >
> >
> > That seems essentially unsolvable. = Given=20 typical tourist
> = herds that=20 I
> > have = observed, they=20 tend to cluster by nationality (or at least =
> > region), if only to make the job of = the tour=20 guide a bit easier :-)
> >=20
> > [rcf]: GSM = Cell=20 Phones address this problem as they can
> dail a number
> > of Emergency numbers from the SIM = Card. The=20 Phone can translate the
>=20 > Dialled number into the Local Emergency number 112, 911,=20
> 110, 111, 000=20 etc...
>=20
> =
> in gsm there is no equivalent to the = global=20 emergency
> = identifier as we=20 discuss it here.
> = as such,=20 you need to have a mechanism to retrieve the local =
> emergency numbers in order todo the = translation from=20 the home
> = emergency number=20 to the local onces.
>=20
>=20 ciao
>=20 hannes
>=20
>=20 = _______________________________________________
> Ecrit mailing = list
> Ecrit@ietf.org
>=20 = https://www1.ietf.org/mailman/listinfo/ecrit
>=20 =

<= /BLOCKQUOTE>

*****

"The = information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers." 118

 ------_=_NextPart_001_01C62047.F4E5C109-- --===============1558919534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1558919534==-- From ecrit-bounces@ietf.org Mon Jan 23 13:12:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F16BG-0005BP-5R; Mon, 23 Jan 2006 13:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F16BE-0005BH-Qp for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 13:12:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06944 for ; Mon, 23 Jan 2006 13:11:10 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F16Ka-0007Cc-4L for ecrit@ietf.org; Mon, 23 Jan 2006 13:22:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 19:11:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C47A3@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgQmeJvwRnTVVxRlGA3dsc5haBOwABgkK6 From: "Stastny Richard" To: "Clive D.W. Feather" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >I can find you 30 locations in the UK where 911345 is a valid dial = string >leading to a local telephone number =20 In these special cases 911 shoild be made unavailable in the device by the operator. These customers normally would not dial 911. =20 There is also the question if devices for nomadic use should be used with local dial plans at all. It should be=20 recommended to operators to use in this case only national dial plans similar to mobile phones. =20 I once wrote an (long expired) I-D intended to give advice for implementing dial plans on VoIP. maybe I should revive it ;-) =20 Richard ________________________________ Von: Clive D.W. Feather [mailto:clive@demon.net] Gesendet: Mo 23.01.2006 18:24 An: Stastny Richard Cc: Raymond Forbes; mhammer@cisco.com; ecrit@ietf.org Betreff: Re: [Ecrit] Issue 30: Summary Stastny Richard said: > I suggest the following: > > The global emergency dial strings 911 and 112 MUST be supported by any > device I can find you 30 locations in the UK where 911345 is a valid dial = string leading to a local telephone number. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 = 6138 Internet Expert | Home: | Fax: +44 870 051 = 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 = 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 14:26:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Kn-00075S-59; Mon, 23 Jan 2006 14:26:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Kl-00075K-Vp for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 14:26:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11364 for ; Mon, 23 Jan 2006 14:25:05 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F17UA-00011f-61 for ecrit@ietf.org; Mon, 23 Jan 2006 14:36:19 -0500 Received: from [10.131.244.248] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Jan 2006 14:25:44 -0500 id 01588026.43D52DB8.00007F58 In-Reply-To: <20060123173514.GG3821@finch-staff-1.thus.net> References: <20060123164710.GE3821@finch-staff-1.thus.net> <04d601c6203d$99ba86f0$640fa8c0@cis.neustar.com> <20060123173514.GG3821@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 14:26:16 -0500 To: ECRIT X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jan 23, 2006, at 12:35 PM, Clive D.W. Feather wrote: > We seem to be at cross-purposes. No, we seem to have wondered into the weeds. I thought the issue here was: either the UA or some proxy needs to convert an emergency dialstring to a universal identifier (perhaps Henning's URN proposal) before making an LCMS query. The emergency dialstring comes in two varieties: "home" and "visited". Home emergency dialstrings can be preconfigured (details vary, but not necessarily important to this conversation). Visited emergency dialstrings are problematic as there needs to be a way to get them into the said UA or proxy. I was not under the impression that this requirement was about universal dialstrings, be they E.164 numbers or not. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 23 14:40:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17YT-0001r7-IQ; Mon, 23 Jan 2006 14:40:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17YR-0001qz-U0 for ecrit@megatron.ietf.org; Mon, 23 Jan 2006 14:40:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12211 for ; Mon, 23 Jan 2006 14:39:13 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F17hr-0001WL-8J for ecrit@ietf.org; Mon, 23 Jan 2006 14:50:27 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F17YJ-0008Rk-Vt; Mon, 23 Jan 2006 13:40:36 -0600 From: "Brian Rosen" To: "'Clive D.W. Feather'" Subject: RE: [Ecrit] Issue 30: Summary Date: Mon, 23 Jan 2006 14:38:30 -0500 Message-ID: <050c01c62054$985d4970$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060123173514.GG3821@finch-staff-1.thus.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYgQ16uw2SehwhvQAqx4fbWDdbhVwABCwGA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think we are at cross purposes, although I do think we are misunderstanding each other. SOME countries don't have emergency numbers; you must dial an e.164 to get help. Often, there is more than one (police, fire, ems, ...) SOME countries have emergency numbers. AFAIK, every one who does has special routing for them in the PSTN. In ecrit, we FIRST expect dial plan interpretation to translate the dialstring for the location where the caller is calling from to a universal emergency identifier. Where there is only one emergency number, that would be urn:service:sos. Where there is more than one, that would be e.g. urn:service:sos.police. That would get all emergency calls having the same URI regardless of where they are calling from. THEN we can use common (that is, country independent) routing mechanisms to route emergency calls to an entity that can determine the correct PSAP for that call. THEN, we use the ecrit mapping mechanism to translate location to the URI of the PSAP. THEN, when we have a URI of the PSAP, we route that. It may be an e.164 in a tel: uri, in which case we would use PSTN routing. That may involve an enum dip. It may be a sip uri which we would route with a DNS lookup and a normal SIP route method. Brian -----Original Message----- From: Clive D.W. Feather [mailto:clive@demon.net] Sent: Monday, January 23, 2006 12:35 PM To: Brian Rosen Cc: 'Michael Hammer (mhammer)'; ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary Brian Rosen said: > "Routed through the network"? Few systems do this, but ones where the only > emergency number is an E.164 do. > > In our work, we interpret an emergency dialstring within a dial plan to the > universal emergency identifier. Then we map that, using the mechanisms we > are discussing here in ecrit, to some routable URI, be it a tel URI routed > as any other tel URI would, a SIP URI, routed as any other SIP URI would, > etc. We seem to be at cross-purposes. Someone seemed to be suggesting that any diallable (in the PSTN) emergency number mapped to an E.164 number, so enum systems could look up the latter. The only point I was trying to make is that in some countries there *is* no such E.164 number. E.g. in the UK "999" (on landlines, at least) is handled by special routeing in the telephone network, not by mapping it to an E.164 number. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 05:09:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1L7F-0004in-LW; Tue, 24 Jan 2006 05:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1L7D-0004hu-Tm for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 05:09:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25278 for ; Tue, 24 Jan 2006 05:08:02 -0500 (EST) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1LGj-0002qT-VP for ecrit@ietf.org; Tue, 24 Jan 2006 05:19:22 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k0OA9Ene004258; Tue, 24 Jan 2006 10:09:14 GMT (envelope-from raymond.forbes@marconi.com) In-Reply-To: <20060123173514.GG3821@finch-staff-1.thus.net> To: clive@demon.net Subject: Re: [Ecrit] Issue 30: Summary MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: "Raymond Forbes" Message-ID: Date: Tue, 24 Jan 2006 10:12:03 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 24/01/2006 10:09:17, Serialize complete at 24/01/2006 10:09:17 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2073041732==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============2073041732== Content-Type: multipart/alternative; boundary="=_alternative 0036011380257100_=" This is a multipart message in MIME format. --=_alternative 0036011380257100_= Content-Type: text/plain; charset="US-ASCII" Clive, I am not aware that the IETF is interested in UK PSTN Routeing (999, 112 or otherwise) 911 is not supported in the UK, 911345 may be a local number, national dialling is not required. If you dial 911 in the UK it will respond with n/u tone as the 6 or 7 digit local number must be dialling in one sequence and mapped by the local exchange. Regards, Ray Forbes. +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. "Clive D.W. Feather" Sent by: ecrit-bounces@ietf.org 23/01/2006 17:35 To: Brian Rosen cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary Brian Rosen said: > "Routed through the network"? Few systems do this, but ones where the only > emergency number is an E.164 do. > > In our work, we interpret an emergency dialstring within a dial plan to the > universal emergency identifier. Then we map that, using the mechanisms we > are discussing here in ecrit, to some routable URI, be it a tel URI routed > as any other tel URI would, a SIP URI, routed as any other SIP URI would, > etc. We seem to be at cross-purposes. Someone seemed to be suggesting that any diallable (in the PSTN) emergency number mapped to an E.164 number, so enum systems could look up the latter. The only point I was trying to make is that in some countries there *is* no such E.164 number. E.g. in the UK "999" (on landlines, at least) is handled by special routeing in the telephone network, not by mapping it to an E.164 number. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 0036011380257100_= Content-Type: text/html; charset="US-ASCII"
Clive,

I am not aware that the IETF is interested in UK PSTN Routeing (999, 112 or otherwise)

911 is not supported in the UK, 911345 may be a local number, national dialling is not required. If you dial 911 in the UK it will respond with n/u tone as the 6 or 7 digit local number must be dialling in one sequence and mapped by the local exchange.

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.


"Clive D.W. Feather" <clive@demon.net>
Sent by: ecrit-bounces@ietf.org

23/01/2006 17:35

       
        To:        Brian Rosen <br@brianrosen.net>
        cc:        ecrit@ietf.org
        Subject:        Re: [Ecrit] Issue 30: Summary



Brian Rosen said:
> "Routed through the network"?  Few systems do this, but ones where the only
> emergency number is an E.164 do.
>
> In our work, we interpret an emergency dialstring within a dial plan to the
> universal emergency identifier.  Then we map that, using the mechanisms we
> are discussing here in ecrit, to some routable URI, be it a tel URI routed
> as any other tel URI would, a SIP URI, routed as any other SIP URI would,
> etc.

We seem to be at cross-purposes.

Someone seemed to be suggesting that any diallable (in the PSTN) emergency
number mapped to an E.164 number, so enum systems could look up the latter.
The only point I was trying to make is that in some countries there *is* no
such E.164 number. E.g. in the UK "999" (on landlines, at least) is handled
by special routeing in the telephone network, not by mapping it to an E.164
number.

--
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--=_alternative 0036011380257100_=-- --===============2073041732== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2073041732==-- From ecrit-bounces@ietf.org Tue Jan 24 05:15:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1LCf-0006py-HL; Tue, 24 Jan 2006 05:15:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1LCe-0006pn-Vz for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 05:15:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25844 for ; Tue, 24 Jan 2006 05:13:38 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1LM8-000388-Bl for ecrit@ietf.org; Tue, 24 Jan 2006 05:24:58 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0OAF3cr001822Tue, 24 Jan 2006 10:15:03 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F1LCZ-0001dp-00; Tue, 24 Jan 2006 10:15:03 +0000 Date: Tue, 24 Jan 2006 10:15:03 +0000 From: "Clive D.W. Feather" To: Raymond Forbes Subject: Re: [Ecrit] Issue 30: Summary Message-ID: <20060124101503.GC51621@finch-staff-1.thus.net> References: <20060123173514.GG3821@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Raymond Forbes said: > I am not aware that the IETF is interested in UK PSTN Routeing (999, 112 > or otherwise) It isn't. However, it is interested in PSTN numbering where that interacts with ecrit, enum, and so on. > 911 is not supported in the UK, Correct. > 911345 may be a local number, national > dialling is not required. As I said, there are about 30 locations where this is the case. > If you dial 911 in the UK it will respond with > n/u tone as the 6 or 7 digit local number must be dialling in one sequence > and mapped by the local exchange. Not so. While there is a timeout, my local exchange (I've just tested it) will accept a more than 10 second gap between digits. It so happens that, if I dial 911 here, I get an announcement immediately after the second 1. I get the same announcement if I dial 912 or 753, because none are valid prefixes. If, however, I'm in one of those 30 areas I would expect to get silence after dialling 911 until the timeout expires. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:08:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1MyN-0003ma-Qf; Tue, 24 Jan 2006 07:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1MyM-0003mK-VV for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05088 for ; Tue, 24 Jan 2006 07:07:00 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1N7u-0007Ek-MV for ecrit@ietf.org; Tue, 24 Jan 2006 07:18:23 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0OC8OJB003823; Tue, 24 Jan 2006 06:08:24 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Jan 2006 12:08:23 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290776@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Raymond Forbes'" Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 12:08:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org To clarify the existing GSM/UMTS CS domain emergency call functionality which is NOT as described below. When the ME recognises an emergency call, either from the numbers stored in the phone itself, or from those stored on the USIM, or from 3GPP release 5 onwards those downloaded from the local network, it will send an EMERGENCY SETUP message, as opposed to an ordinary SETUP message. This message has no provision for a called party number, and the message type itself acts as the identifier that this is an emergency call. It therefore does not contain any of the dial strings that Ray mentions. It can contain an emergency category, but this is merely a bit pattern, rather than a dial string. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Raymond Forbes Sent: 23 January 2006 09:18 To: Henning Schulzrinne Sent by: ecrit-bounces@ietf.org 22/01/2006 16:13 To: "Tschofenig, Hannes" cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary On Jan 22, 2006, at 8:21 AM, Tschofenig, Hannes wrote: > hi all, > > i am trying to summarize the discussion related to issue 30/issue 8. > > - there are location-dependent and global emergency identifiers. > global emergency identifiers are, for example the sos uris > introduced in > sipping-sos > draft. location-dependent emergency identifiers are those that are > used > today in specific countries (see, for example, > http://www.sccfd.org/travel.html) This is probably more nit-picking than substance, but I would avoid using the term "identifier" for dial strings such as "9 1 1". Calling them 'emergency dial strings' is a bit awkward, but avoids confusion. We try to make this distinction in the 2806/3966 RFCs, reserving "identifier" to something that has a URI. (Dial strings are not tel URIs, for example.) > > - location-dependent numbers might be further categorized into 'home' > emergency numbers (the definition of 'home' relates to a specific > user) > and numbers used in a 'local' region (here 'local emergency numbers'). > "local" here means the valid emergency telephone number used in the > geographic vicinity the user finds himself in. I prefer the term "visited", since this corresponds fairly closely to the mobile IP or 3GPP issues using the same terminology. > > - the sip ua should translate home emergency numbers to a global > emergency identifier. the ua is most likely pre-provisioned with this > information to be able to make such a translation. For SIP devices, we can probably reference the SIP configuration work in this regard, although I wouldn't want to require this. In particular, SIP configuration is, unfortunately, fairly heavy-weight. It is quite possible for a device to determine its home location and then use the same location-to-dial string mapping mechanism that it might use for the 'visited' emergency dial string. > > - there are cases where the sip ua does not recognize the home > emergency > number. in this case the home emergency number is not translated to a > global emergency identifier. a sip proxy (in the visited or the home > network) needs to understand that this is an emergency call. > > - the sip ua should translate local emergency numbers to a global > emergency identifier. I'm guessing that you do mean SHOULD. > > * Tourist Alice collapses, another tourist Bob finds the cell > phone of Alice and dials its own home emergency number (because it > does > not know the local emergency number) and the home emergency number is > different from the local emergency number and Alice/Bob have different > home emergency numbers. > That seems essentially unsolvable. Given typical tourist herds that I have observed, they tend to cluster by nationality (or at least region), if only to make the job of the tour guide a bit easier :-) [rcf]: GSM Cell Phones address this problem as they can dail a number of Emergency numbers from the SIM Card. The Phone can translate the Dialled number into the Local Emergency number 112, 911, 110, 111, 000 etc... > > the problem is only that local emergency numbers in one region are not > emergency numbers in another region. > And, more seriously, emergency numbers in one part of the world are used as regular numbers, for services (operator, directory assistance, etc.), prefixes or PBX extensions, elsewhere. > > it seems that some of you want to work on a solution for (1) (or have > already worked on it). > > ciao > hannes > > ps: the user interface is important to us and we need to be aware of > these aspects (as we need to be aware of many other aspects as > well). i > guess that most of you understood what i meant by "out-of-scope". I think we can, at best, reference some of the potential problems, such as the ones that Barbara Stark helpfully pointed out. I suspect that these trade-offs may differ a bit for mobile vs. landline devices. For example, if I'm getting service from the US, but live in Australia, it is probably a wise move to give the user of a stationary device the option of keeping '00' for international operator or using it as an emergency number, following local custom. Given that a one or two incidents of "baby sitter dials 9-1-1 on VoIP phone and gets no answer" caused major regulatory upheaval in the US, I suspect that the default will be to make emergency calls at the current location of the device work, even if that interferes with some other aspect of the dial plan. It is much better to force the user to dial #00 than having a house guest in Adelaide dial 000 to get an ambulance and talk to an international operator in New Jersey instead. As always, the IETF does not have the authority to regulate device manufacturers. It would be up to local regulatory bodies to give standards the force of law or regulation. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:15:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4p-0006hy-Ds; Tue, 24 Jan 2006 07:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4n-0006ho-Ba for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:15:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05482 for ; Tue, 24 Jan 2006 07:13:38 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NEJ-0007Ue-VL for ecrit@ietf.org; Tue, 24 Jan 2006 07:25:00 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEuie028800; Tue, 24 Jan 2006 13:14:58 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEr4c015488; Tue, 24 Jan 2006 13:14:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:14:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt Date: Tue, 24 Jan 2006 13:14:49 +0100 Message-ID: Thread-Topic: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt Thread-Index: AcYgMVYtd/7CD+wdQwKzDbWSRHJYLAAQiEZw From: "Tschofenig, Hannes" To: "Raymond Forbes" X-OriginalArrivalTime: 24 Jan 2006 12:14:51.0019 (UTC) FILETIME=[C6B515B0:01C620DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi raymond,=20 =20 thanks for the pointer to 'EU Commission Recommendation C(2003) 2657'. =20 with regard to the security threats: i think we commented the protential risk regarding the call content.=20 to address this threat encryption might be a reasonable approach but certainly not for free (with regard to the key management). it is interesting to know that there is no requirement from the EU data protection regulartion.=20 =20 with the next draft update we will try to clarify the text about psap serving a limited area.=20 =20 ciao hannes =20 ________________________________ Von: Raymond Forbes [mailto:raymond.forbes@marconi.com]=20 Gesendet: Montag, 23. Januar 2006 16:28 An: Tschofenig, Hannes Cc: ecrit@ietf.org Betreff: Re: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt =09 =09 Hannes,=20 =09 See [RCF]: Below=20 =09 Regards, =09 Ray Forbes. =09 +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =09 =09 =09 =09 "Tschofenig, Hannes" =20 22/01/2006 17:46=20 =20 To: "Raymond Forbes" , =20 cc: =20 Subject: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt =09 [hannes] we had a long discussion about the term location validation and i think that we use the terms differently.=20 do you have a pointer to your definition?=20 =09 [RCF]: Read EU Commission Recommendation C(2003) 2657 =09 ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be from Asserted Identity Information added of validated by the ESRP; This is an option allowed in Title: Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall=20 Filename: draft-ietf-ecrit-requirements-02.txt =20 =09 [hannes] i have to read into the details of ETSI TS 102 164 but the described scenario seems to be supported by the requirements draft. the ability for an outbound proxy to perform location-based routing is clearly in scope of our work. the ability of using the sip identity work is also allowed and might be quite useful.=20 =09 =09 Real Geographic mapping in the TS 102 164 is calculated within the PSAP by secure look up into the operators "directory" databases (by a Private service IP link). The EU has special provision to allow and require this with the EU data protection Directive. This is not mentioned, but does not need to be mentioned. It is almost the same as the case (8), acquisition of Location Information by a Call Routing Entity in Title: Security Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8 Requirements for Interface .=20 =09 =20 Firstly, Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is not be true according to European Directive and Europe-wide laws. The EU data protection directive states that Location is Private data to the user that must be secured under the user's right to reveal, withstanding the three very clear legal exceptions: which are 1. National Security; 2. Criminal Activity and 3. making an Emergency call or Request to the Emergency services. These Authority must legally respect the rights of the User not to reveal the location to third parties and commercial organisations. I suggest that you delete the note. EU Directives and European-wide law covers at least 30 countries. Under EU Directives the User's Location is Private data that cannot be revealed except on the commercial request of the User for a Location based service or under one of the three provisions. The user's location falling inadvertently into the wrong hands is a security threat that you do not mention. This means that User's location cannot be held on a Publically accessible directory database.=20 =09 =20 =09 [hannes] here is the paragraph you are referring to:=20 ( =09 http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 01.txt)=20 =09 " 3. The timeliness, integrity and privacy of call signalling must be ensured as it passes between the emergency caller's device and the PSAP. =09 NOTE - a confidentiality requirement applies to the association of a location with an emergency (e.g., within call signalling) or with an individual. The location data per se is not confidential. " =09 i would like to hear your opinion about the following security aspect. we have two places where confidentiality protection=20 is applicable:=20 =09 a) between the access network and the end host when location information is provided by the access network to the end host (e.g., using dhcp as described in http://www.ietf.org/rfc/rfc3825.txt and in =09 http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt )=20 =09 b) as part of the emergency call itself.=20 =09 what problems do you see if confidentiality protection is not applied at (a) and/or at (b) (with regard to the above-mentioned law)? =09 [RCF]: I can agree Option a) above, Option B is also true but is a human risk that people who know call content, including Location data may misuse their knowledge. I am not suggesting that there is a requirement to encrypt Emergency sessions, Or at least not from this EU data protection requirement.=20 =09 [RCF]: there may be a general concern that communication across the public Internet is more easily eavesdropped (casually intercepted by unauthorised individuals) than communication across a private network (IP based or Circuit switched)=20 =09 Secondly, I have one question about the Requirements for Emergency Context Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a limited geographic region, ..." This in not True. It may be true in the US and Germany, but in many countries the PSAPs may server a wide area. The problem will be solved if the Words are changed to "PSAPS may only serve a limited geographic region, ..."=20 =20 =09 [hannes] maybe the term 'limited' should be read as 'specific'. the size of the region, however, does not matter for the purpose of location-based routing or for the mapping protocol. as such, it does not matter.=20 =09 [RCF]: I think there is room for agreement the around the text; I think that I agree with Brian on this that the Region is Limited to be within a Specific Nation it may be a more locally or specifically defined region with a nation. It may be the Entire National Area (in the case of Luxembourg for example).=20 =09 Ciao hannes =09 =20 Regards, =20 Ray Forbes. =20 +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =20 =20 =20 =20 "Tschofenig, Hannes" =20 Sent by: "emtel : Emtel" =20 =09 09/01/2006 22:47=20 Please respond to "Tschofenig, Hannes"=20 =09 =20 To: EMTEL@LIST.ETSI.ORG=20 cc: =20 Subject: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt =09 =09 =09 hi all, =20 a new version of our requirements document is available. please send review comments to the mailing list (see =09 http://www.ietf.org/html.charters/ecrit-charter.html). =20 ------------------------- =20 Title : Requirements for Emergency Context Resolution with Internet Technologies=20 Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-02.txt Pages : 27 Date : 2006-1-3=20 =20 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. =20 A URL for this Internet-Draft is: =20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt =20 =20 ------------------------- =20 =20 ciao hannes =20 =20 =09 ------------------------------------------------------------------- Mail archive for EMTEL can be browsed at the following url:=20 http://list.etsi.org/EMTEL.html =20 =09 -------------------------------------------------------------------=20 =20 =20 =09 =09 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:15:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4r-0006ix-BX; Tue, 24 Jan 2006 07:15:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4p-0006iP-KP for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05489 for ; Tue, 24 Jan 2006 07:13:41 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NEN-0007Uj-84 for ecrit@ietf.org; Tue, 24 Jan 2006 07:25:03 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEuVr002986; Tue, 24 Jan 2006 13:14:56 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEres015486; Tue, 24 Jan 2006 13:14:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:14:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 13:14:49 +0100 Message-ID: Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgQ16uw2SehwhvQAqx4fbWDdbhVwABCwGAAAzYbTA= From: "Tschofenig, Hannes" To: , "Clive D.W. Feather" X-OriginalArrivalTime: 24 Jan 2006 12:14:51.0031 (UTC) FILETIME=[C6B6EA70:01C620DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi brian,=20 nice text - only a minor enhancement.=20 > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Brian Rosen > Gesendet: Montag, 23. Januar 2006 20:39 > An: 'Clive D.W. Feather' > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] Issue 30: Summary >=20 > I don't think we are at cross purposes, although I do think we are > misunderstanding each other. >=20 > SOME countries don't have emergency numbers; you must dial an=20 > e.164 to get > help. Often, there is more than one (police, fire, ems, ...) >=20 > SOME countries have emergency numbers. AFAIK, every one who does has > special routing for them in the PSTN. >=20 > In ecrit, we FIRST expect dial plan interpretation to translate the > dialstring for the location where the caller is calling from=20 > to a universal > emergency identifier. Where there is only one emergency=20 > number, that would > be urn:service:sos. Where there is more than one, that would be e.g. > urn:service:sos.police. That would get all emergency calls=20 > having the same > URI regardless of where they are calling from. =20 >=20 > THEN we can use common (that is, country independent) routing=20 > mechanisms to > route emergency calls to an entity that can determine the=20 > correct PSAP for > that call. =20 if the end host executes the mapping protocol we can skip the previous = step.=20 >=20 > THEN, we use the ecrit mapping mechanism to translate=20 > location to the URI of > the PSAP. >=20 > THEN, when we have a URI of the PSAP, we route that. It may=20 > be an e.164 in > a tel: uri, in which case we would use PSTN routing. That=20 > may involve an > enum dip. It may be a sip uri which we would route with a=20 > DNS lookup and a > normal SIP route method. we should probably copy-and-paste this text to the beginning of section = 6 of=20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt ciao hannes >=20 > Brian >=20 > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net]=20 > Sent: Monday, January 23, 2006 12:35 PM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > Brian Rosen said: > > "Routed through the network"? Few systems do this, but=20 > ones where the > only > > emergency number is an E.164 do. > >=20 > > In our work, we interpret an emergency dialstring within a=20 > dial plan to > the > > universal emergency identifier. Then we map that, using=20 > the mechanisms we > > are discussing here in ecrit, to some routable URI, be it a=20 > tel URI routed > > as any other tel URI would, a SIP URI, routed as any other=20 > SIP URI would, > > etc. >=20 > We seem to be at cross-purposes. >=20 > Someone seemed to be suggesting that any diallable (in the=20 > PSTN) emergency > number mapped to an E.164 number, so enum systems could look=20 > up the latter. > The only point I was trying to make is that in some countries=20 > there *is* no > such E.164 number. E.g. in the UK "999" (on landlines, at=20 > least) is handled > by special routeing in the telephone network, not by mapping=20 > it to an E.164 > number. >=20 > --=20 > Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495 6138 > Internet Expert | Home: | Fax: =20 > +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > +44 7973 377646 > Thus plc | | >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:15:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4r-0006jM-KI; Tue, 24 Jan 2006 07:15:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4q-0006iX-0V for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:15:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05492 for ; Tue, 24 Jan 2006 07:13:41 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NEN-0007Uk-BL for ecrit@ietf.org; Tue, 24 Jan 2006 07:25:04 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEv07003021; Tue, 24 Jan 2006 13:14:57 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCErew015486; Tue, 24 Jan 2006 13:14:56 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2006 13:14:49 +0100 Message-ID: Thread-Topic: Issue 30: Requirements Thread-Index: AcYgK8FRvBwnKPVJTyazk7qv6H0YPwAAQC1wAADYUoAAAHt/YAAAQd1gABE/0dA= From: "Tschofenig, Hannes" To: "Stark, Barbara" , "Stastny Richard" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 24 Jan 2006 12:14:50.0859 (UTC) FILETIME=[C69CABB0:01C620DF] X-Spam-Score: 0.2 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: [Ecrit] Issue 30: Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi barbara,=20 =20 you exactly hit the point. as an outcome of the discussion we need to add a few requirements to the requirements draft. we might need todo a little bit wording around your suggested text:=20 - UAs MUST be able to recognize emergency dial strings, and translate these strings into the global emergency SIP URI (). - UAs MUST be able to support mapping of all "home" emergency dial strings, consistent with the "home" dialing plan of the UA. we additionally need to add the requirements for the UA to be able to learn the "local" dial strings. the mechanism for learning local dial strings is likely to be different than the approach used for getting the home dialstrings pre-configured.=20 =20 ciao hannes =20 =20 ________________________________ Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im Auftrag von Stark, Barbara Gesendet: Montag, 23. Januar 2006 19:08 An: Stastny Richard; Michael Hammer (mhammer) Cc: ecrit@ietf.org Betreff: RE: [Ecrit] Issue 30: Summary =09 =09 Not all VoIP or SIP implementations are GSM or specified through 3GPP. I really don't think the IETF or ecrit has any business specifying emergency dial strings. That is the business of regulatory bodies that have jurisdiction over the offered SIP service. The ecrit architecture is completely independent of any particular dial string. All ecrit needs to be requiring is something like: =20 UAs MUST be able to recognize emergency dial strings, and translate these strings into the global emergency SIP URI (). =20 UAs MUST be able to support mapping of all "home" emergency dial strings, consistent with the "home" dialing plan of the UA. =20 By the way, it's come as quite a revelation to myself and my colleagues that our GSM phones do, indeed, support 112 (we've confirmed this with our cell colleagues). None of us had any idea that this was so. I'd be willing to go out on a limb and say that probably well over 99% of the people in the US have absolutely no idea that their GSM phones support 112. In fact, most people here are completely unaware that 112 is the EU emergency number, or that it's supposed to be a globally recognized GSM emergency number. My dual mode handset (GSM + WiFi, with outbound WiFi calls going to IP PBX) only supports 112 when in GSM mode. Since the IP PBX doesn't support 112, 112 doesn't work when the phone is in WiFi mode. 911 is supported in both modes. =20 Speaking of PBXs, most PBXs in the US will recognize "911", independent of any prefix that may be used for normal outbound dialing. They will also recognize + 911. While "9" is commonly used as a prefix, it's by no means a standard. From my desktop IP phone, I have to dial "99" as a prefix. If a requirement is desired that references IP PBX prefixes, perhaps: =20 If a prefix is normally required for outside-line dialing by a UA, the UA SHOULD support mapping of emergency dial strings with or without the prefix. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Monday, January 23, 2006 10:33 AM To: Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =09 =09 IMHO basically all folks from countries having GSM implemented will accept or at least will know about 112, which includes all regions you mentioned =09 Richard =20 =20 =20 ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Monday, January 23, 2006 4:19 PM To: Stastny Richard Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 I like your approach, but have only one question. =20 Do folks from Asia, Africa, Australia, and South America accept that 911 and 112 are the global emergency dial strings? =20 Mike =20 =20 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, January 23, 2006 10:06 AM To: Raymond Forbes; Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary I am really getting tired of this discussion, which goes on now for years, simply because there is no solution to have home and local emergency dial strings working in any case because of conflicts that are not resolvable on a global scale, and especially NOT by ECRIT. =20 Since any user needs to have a dial plan agreed upon with his provider (which will be in most cases the home dial plan) and this dial plan can be configured into the device =20 I suggest the following: =20 The global emergency dial strings 911 and 112 MUST be supported by any device and MUST be mapped to the default sos identifier In addition, the emergency dial strings supported in the home dial plan MUST be supported and mapped accordingly =20 Local emergency dial strings may be supported if there exists no conflict. If the device is not aware of the local emergency dial strings or conflicting other dial strings, it MUST NOT support these dial strings (in doubt) =20 VoIP users should be made aware at subscription time that they SHALL only use 911 or 112 when abroad (also by NENA and EENA) =20 Regards Richard =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Raymond Forbes Sent: Monday, January 23, 2006 3:23 PM To: mhammer@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 =09 I was only pointing to the example in GSM (3GPP) today where there most commonly used global numbers are stored in all SIM modules, and further local national numbers may be additionally stored.=20 =09 This alleviates the need for having a Global address as the Roaming/Nomadic terminal inter-works with the region it is in. A global address has certain advantages.=20 =09 The GSM solution requires that other national numbers not in the Prime list may be additionally stored.=20 =09 This solves the problem of encountered my the majority of tourists, US or Japanese Tourists in London. who do not know that their national number (911 or 110) needs translating to 112. It does not solve all problems. For example 110 in Germany will reach the Police not the Emergency services.=20 =09 Regards, =09 Ray Forbes. =09 +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. =09 =09 =20 "Michael Hammer \(mhammer\)" =20 23/01/2006 13:45=20 =20 To: "Hannes Tschofenig" , "Raymond Forbes" =20 cc: , =20 Subject: RE: [Ecrit] Issue 30: Summary =09 =09 =09 =09 Hannes, =09 We still seem to be glossing over terms and usage it seems. =09 When you talk about "emergency numbers", are you referring to an E.164 number that the "emergency dial string" gets translated to? Or, just that 3 digit emergency code? =09 Also, you seem to suggest that each of the hundred or so emergency dial strings (112, 911, etc.) are reserved for emergency use globally. Right now I understand there are some conflicts. Are you proposing that all those emergency codes be reserved for emergency use in all countries. That is, where any of those codes is used for another purpose, that country must change their usage? So, that the tourist from any country can visit any country and any emergency code will work? =09 Mike=20 =09 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Monday, January 23, 2006 5:15 AM > To: Raymond Forbes > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > hi raymond, >=20 > ~snip~ >=20 > > > * Tourist Alice collapses, another tourist Bob finds the cell > > > phone of Alice and dials its own home emergency number=20 > (because it =20 > > > does > not know the local emergency number) and the home=20 > emergency=20 > > number is > different from the local emergency number and=20 > Alice/Bob=20 > > have different > home emergency numbers. > > > > >=20 > > That seems essentially unsolvable. Given typical tourist=20 > herds that I=20 > > have observed, they tend to cluster by nationality (or at least=20 > > region), if only to make the job of the tour guide a bit easier :-) > >=20 > > [rcf]: GSM Cell Phones address this problem as they can=20 > dail a number=20 > > of Emergency numbers from the SIM Card. The Phone can translate the=20 > > Dialled number into the Local Emergency number 112, 911,=20 > 110, 111, 000 etc... >=20 >=20 > in gsm there is no equivalent to the global emergency=20 > identifier as we discuss it here. > as such, you need to have a mechanism to retrieve the local=20 > emergency numbers in order todo the translation from the home=20 > emergency number to the local onces. >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." 118 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:15:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4r-0006jl-TG; Tue, 24 Jan 2006 07:15:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4q-0006ij-I8 for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:15:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05495 for ; Tue, 24 Jan 2006 07:13:42 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NEK-0007Uf-3M for ecrit@ietf.org; Tue, 24 Jan 2006 07:25:01 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEtdN028782; Tue, 24 Jan 2006 13:14:55 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEr4Y015488; Tue, 24 Jan 2006 13:14:54 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:14:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 13:14:49 +0100 Message-ID: Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYgUxIBUxzB8pkmRVeHMKTh+ZnA/QAJm2Fw From: "Tschofenig, Hannes" To: "Andrew Newton" , "ECRIT" X-OriginalArrivalTime: 24 Jan 2006 12:14:51.0441 (UTC) FILETIME=[C6F57A10:01C620DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy,=20 > I thought the issue here was: either the UA or some proxy needs to =20 > convert an emergency dialstring to a universal identifier (perhaps =20 > Henning's URN proposal) before making an LCMS query. right.=20 > The emergency =20 > dialstring comes in two varieties: "home" and "visited". Home =20 > emergency dialstrings can be preconfigured (details vary, but not =20 > necessarily important to this conversation). Visited emergency =20 > dialstrings are problematic as there needs to be a way to get them =20 > into the said UA or proxy. true, again.=20 we are sometimes not really efficient in our discussions because we tend to get lost somewhere.=20 i wonder what the reason for this is.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:15:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4t-0006kA-6a; Tue, 24 Jan 2006 07:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N4r-0006io-4T for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:15:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05498 for ; Tue, 24 Jan 2006 07:13:42 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NEN-0007Ul-VJ for ecrit@ietf.org; Tue, 24 Jan 2006 07:25:04 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEtxh002974; Tue, 24 Jan 2006 13:14:55 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEreq015486; Tue, 24 Jan 2006 13:14:54 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2006 13:14:49 +0100 Message-ID: Thread-Topic: Issue#30: Scope Thread-Index: AcYgK0IFL3u3xeiHQqG+sRqhKzBz7gAATLGgABEsYkA= From: "Tschofenig, Hannes" To: , "Raymond Forbes" , X-OriginalArrivalTime: 24 Jan 2006 12:14:50.0203 (UTC) FILETIME=[C63892B0:01C620DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: [Ecrit] Issue#30: Scope X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi brian,=20 =20 > I think that while we do have to agree on terminology for our=20 > documents, we > don't have to agree here in ecrit on exactly what an endpoint=20 > does with > information we supply it. i agree with you.=20 > I'd rather not get into specifying=20 > a "prime" list > of numbers, for example. i again agree with you.=20 a discussion of these numbers and how they get used dos not belong to = the requirements, the security threats, to the sipping-sos, etc. = documents. it might be reasonable to discuss these issues in the bcp. we = are not yet there....=20 >=20 > What I do want to do is to specify the mechanisms by which an endpoint > learns the emergency dialstring for both its home and visited=20 > locations. that's also my conclusion of the recent discussion.=20 >=20 > It does seem like "dialstring" is the right noun, especially=20 > the way we > intend to use it, which is that an entity (the endpoint or a=20 > downstream > proxy) translates that digit sequence to the universal URN, which may > subsequently be translated to some other URI (be it a SIP uri=20 > or a tel uri > or even something else). So, I would propose that we=20 > henceforth agree to > use the term "emergency dialstring" to refer to the digit=20 > sequence dialed in > some location to reach emergency services. This avoids=20 > confusion with what > "emergency number" means. 'emergency dialstring' sounds good to me.=20 >=20 > Then, I do think we are better off referring to "visited" and=20 > "home" access > networks when talking about these issues. It does seem to=20 > make it wireless > centric, which I don't intend to, but I think it eliminates=20 > confusion. The > term "local" and "remote" are too ambiguous to be used for=20 > either "home" or > "visited" (is it remote from where you normally are, or=20 > remote from where > you are now?). 'visited', 'local' or 'serving' network: i don't care.=20 ciao hannes >=20 > Brian > ________________________________________ > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of > Raymond Forbes > Sent: Monday, January 23, 2006 9:23 AM > To: mhammer@cisco.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 > I was only pointing to the example in GSM (3GPP) today where=20 > there most > commonly used global numbers are stored in all SIM modules,=20 > and further > local national numbers may be additionally stored.=20 >=20 > This alleviates the need for having a Global address as the=20 > Roaming/Nomadic > terminal inter-works with the region it is in. A global=20 > address has certain > advantages.=20 >=20 > The GSM solution requires that other national numbers not in=20 > the Prime list > may be additionally stored.=20 >=20 > This solves the problem of encountered my the majority of=20 > tourists, US or > Japanese Tourists in London. who do not know that their=20 > national number (911 > or 110) needs translating to 112. It does not solve all problems. For > example 110 in Germany will reach the Police not the=20 > Emergency services.=20 >=20 > Regards, >=20 > Ray Forbes. >=20 > +44 24 7656 3106 phone > +44 24 7656 3816 fax. > +44 771 851 1361 Mobile/text > ------------ > This e-mail and any attachments are confidential. =A0If you are not = the > intended recipient, please notify us immediately by reply=20 > e-mail and then > delete this message from your system. Do not copy this e-mail or any > attachments, use the contents for any purpose, or disclose=20 > the contents to > any other person: to do so could be a breach of confidence. >=20 >=20 >=20 > "Michael Hammer \(mhammer\)" =20 > 23/01/2006 13:45=20 > =A0 =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Hannes Tschofenig"=20 > , "Raymond > Forbes" =20 > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0, = =20 > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [Ecrit] Issue 30: Summary >=20 >=20 >=20 > Hannes, >=20 > We still seem to be glossing over terms and usage it seems. >=20 > When you talk about "emergency numbers", are you referring to an E.164 > number that the "emergency dial string" gets translated to? =A0Or, = just > that 3 digit emergency code? >=20 > Also, you seem to suggest that each of the hundred or so=20 > emergency dial > strings (112, 911, etc.) are reserved for emergency use=20 > globally. =A0Right > now I understand there are some conflicts. =A0Are you proposing that = all > those emergency codes be reserved for emergency use in all countries. > That is, where any of those codes is used for another purpose, that > country must change their usage? =A0So, that the tourist from=20 > any country > can visit any country and any emergency code will work? >=20 > Mike=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > On Behalf Of Hannes Tschofenig > > Sent: Monday, January 23, 2006 5:15 AM > > To: Raymond Forbes > > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > >=20 > > hi raymond, > >=20 > > ~snip~ > >=20 > > > =A0> =A0 * Tourist Alice collapses, another tourist Bob finds the = cell > > > =A0> phone of Alice and dials its own home emergency number=20 > > (because it =A0 > > > > does =A0> not know the local emergency number) and the home=20 > > emergency=20 > > > number is =A0> different from the local emergency number and=20 > > Alice/Bob=20 > > > have different =A0> home emergency numbers. > > > =A0> > > >=20 > > > That seems essentially unsolvable. Given typical tourist=20 > > herds that I=20 > > > have observed, they tend to cluster by nationality (or at least=20 > > > region), if only to make the job of the tour guide a bit=20 > easier :-) > > >=20 > > > [rcf]: GSM Cell Phones address this problem as they can=20 > > dail a number=20 > > > of Emergency numbers from the SIM Card. The Phone can=20 > translate the=20 > > > Dialled number into the Local Emergency number 112, 911,=20 > > 110, 111, 000 etc... > >=20 > >=20 > > in gsm there is no equivalent to the global emergency=20 > > identifier as we discuss it here. > > as such, you need to have a mechanism to retrieve the local=20 > > emergency numbers in order todo the translation from the home=20 > > emergency number to the local onces. > >=20 > > ciao > > hannes > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:16:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N5c-0006pi-9B; Tue, 24 Jan 2006 07:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1N5a-0006pa-9a for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:15:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05564 for ; Tue, 24 Jan 2006 07:14:28 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NF8-0007WC-2O for ecrit@ietf.org; Tue, 24 Jan 2006 07:25:50 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEtbs002975; Tue, 24 Jan 2006 13:14:55 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCEr4a015488; Tue, 24 Jan 2006 13:14:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2006 13:14:49 +0100 Message-ID: Thread-Topic: Steven Kent's Review text Thread-Index: AcYflej/mpSr4XfPTr2Di+lBn8vyuQA3v5KA From: "Tschofenig, Hannes" To: "Murugaraj Shanmugam" , X-OriginalArrivalTime: 24 Jan 2006 12:14:50.0675 (UTC) FILETIME=[C6809830:01C620DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: "Shanmugam, Murugaraj" Subject: [Ecrit] Steven Kent's Review text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 =20 please find the two long reviews by steven kent at: =20 http://www.ietf-ecrit.org/TEMP/ecrit-security-threats-00.pdf http://www.ietf-ecrit.org/TEMP/ECRIT_security.doc =20 ciao hannes ________________________________ Von: Murugaraj Shanmugam [mailto:murugaraj@gmail.com]=20 Gesendet: Sonntag, 22. Januar 2006 21:54 An: ecrit@ietf.org Cc: Tom-PT Taylor; Tschofenig, Hannes; hgs@cs.columbia.edu; Shanmugam, Murugaraj Betreff: Re: [Ecrit] re: I-D ACTION:draft-taylor-ecrit-security-threats-01.txt =09 =09 Hi all, =09 the interim meeting is getting closer and Hannes asked me to summarize the changes after Steven Kent's draft review (provided after IETF#64). Based on his feedback we produced the current draft version draft-taylor-ecrit-security-threats-01.txt. =09 The crux of Steven's comments is as follows: =09 a) The draft should explain the architecture of the emergency calling functionality, describe the operation model, present the threat model with different classes of adversaries, motivations and their capabilities and articulate the security requirments.=20 =09 b) No counter measures should be discussed in this draft, since the counter measures were not self-explanatory. =09 As a consequence this version of the draft has been rewritten from the scratch to reflect Steven Kent's comments.=20 =09 * Emergency call routing system overview to describe the operation of the model, =09 * listed and discussed the diffenrent variants of potenial attacks, =09 * presented the security requirements with respect to the emergency model described in this document.=20 =09 * removed the discussion of countermeasures. =09 A more detailed mail was sent to the list at the end of last year: =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg01251.html =20 =09 ciao, Raj _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:21:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NAr-0007Pe-5i; Tue, 24 Jan 2006 07:21:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NAq-0007PZ-7d for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:21:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06010 for ; Tue, 24 Jan 2006 07:19:53 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NKM-0007iT-6q for ecrit@ietf.org; Tue, 24 Jan 2006 07:31:16 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0OCLF1F022524 for ; Tue, 24 Jan 2006 06:21:16 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Jan 2006 12:21:15 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290777@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 12:21:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org To try and make a suggestion based on the discussion so far. I think the key to this is the ability to configure the SIP phone. I would suggest requirements something like the following: - All SIP phones MUST support recognition of emergency numbers keyed by the user, and if recognised, make the call as an emergency call using the universal emergency identifier (i.e. the sos SIP URI or whatever it is). - All SIP phones that are configurable, either locally or remotely, MUST support configuration of recognisable emergency numbers by that mechanism. - SIP phones that are not configurable MUST recognise 112 and 911. I dont think the last will ever need to be implemented in practice as I suspect all SIP phones needs to support some form of configuration. As such I think that if someone wants to provide such a restricted phone, it will only be able to dial full E.164 numbers anyway (i.e. international format), and such numbers do not conflict with 112 and 911. This is why such numbers are defined as stored on the GSM phone, rather than on the UICC/SIM. We do need to add the optional emergency category requirements into the above, but this in my view deals with the generally recognisable numbers issue. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > Clive D.W. Feather > Sent: 24 January 2006 10:15 > To: Raymond Forbes > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary > > > Raymond Forbes said: > > I am not aware that the IETF is interested in UK PSTN > Routeing (999, 112 > > or otherwise) > > It isn't. However, it is interested in PSTN numbering where > that interacts > with ecrit, enum, and so on. > > > 911 is not supported in the UK, > > Correct. > > > 911345 may be a local number, national > > dialling is not required. > > As I said, there are about 30 locations where this is the case. > > > If you dial 911 in the UK it will respond with > > n/u tone as the 6 or 7 digit local number must be dialling > in one sequence > > and mapped by the local exchange. > > Not so. While there is a timeout, my local exchange (I've > just tested it) > will accept a more than 10 second gap between digits. > > It so happens that, if I dial 911 here, I get an announcement > immediately > after the second 1. I get the same announcement if I dial 912 or 753, > because none are valid prefixes. If, however, I'm in one of > those 30 areas > I would expect to get silence after dialling 911 until the > timeout expires. > > -- > Clive D.W. Feather | Work: | Tel: > +44 20 8495 6138 > Internet Expert | Home: | Fax: > +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: > +44 7973 377646 > Thus plc | | > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:21:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NAx-0007RN-N9; Tue, 24 Jan 2006 07:21:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NAw-0007RI-1C for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:21:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06017 for ; Tue, 24 Jan 2006 07:19:59 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1NKT-0007i5-Dq for ecrit@ietf.org; Tue, 24 Jan 2006 07:31:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2006 13:25:04 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2369@oefeg-s04.oefeg.loc> Thread-Topic: Issue 30: Requirements Thread-Index: AcYgK8FRvBwnKPVJTyazk7qv6H0YPwAAQC1wAADYUoAAAHt/YAAAQd1gABE/0dAAGirwMA== From: "Stastny Richard" To: "Tschofenig, Hannes" , "Stark, Barbara" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.2 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: [Ecrit] RE: Issue 30: Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I forgot who proposed it recently to use the term "visited" instead of "local" to avoid confusion. I would also prefer this terminology. Richard > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Tuesday, January 24, 2006 1:15 PM > To: Stark, Barbara; Stastny Richard; Michael Hammer (mhammer) > Cc: ecrit@ietf.org > Subject: Issue 30: Requirements >=20 > hi barbara, >=20 > you exactly hit the point. as an outcome of the discussion we need to > add a few requirements to the requirements draft. we might need todo a > little bit wording around your suggested text: > - UAs MUST be able to recognize emergency dial strings, and translate > these strings into the global emergency SIP URI ( RFC>). > - UAs MUST be able to support mapping of all "home" emergency dial > strings, consistent with the "home" dialing plan of the UA. >=20 > we additionally need to add the requirements for the UA to be able to > learn the "local" dial strings. the mechanism for learning local dial > strings is likely to be different than the approach used for getting the > home dialstrings pre-configured. >=20 > ciao > hannes >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im > Auftrag von Stark, Barbara > Gesendet: Montag, 23. Januar 2006 19:08 > An: Stastny Richard; Michael Hammer (mhammer) > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] Issue 30: Summary >=20 >=20 > Not all VoIP or SIP implementations are GSM or specified through > 3GPP. I really don't think the IETF or ecrit has any business specifying > emergency dial strings. That is the business of regulatory bodies that > have jurisdiction over the offered SIP service. The ecrit architecture > is completely independent of any particular dial string. All ecrit needs > to be requiring is something like: >=20 > UAs MUST be able to recognize emergency dial strings, and > translate these strings into the global emergency SIP URI ( future RFC>). >=20 > UAs MUST be able to support mapping of all "home" emergency dial > strings, consistent with the "home" dialing plan of the UA. >=20 > By the way, it's come as quite a revelation to myself and my > colleagues that our GSM phones do, indeed, support 112 (we've confirmed > this with our cell colleagues). None of us had any idea that this was > so. I'd be willing to go out on a limb and say that probably well over > 99% of the people in the US have absolutely no idea that their GSM > phones support 112. In fact, most people here are completely unaware > that 112 is the EU emergency number, or that it's supposed to be a > globally recognized GSM emergency number. My dual mode handset (GSM + > WiFi, with outbound WiFi calls going to IP PBX) only supports 112 when > in GSM mode. Since the IP PBX doesn't support 112, 112 doesn't work when > the phone is in WiFi mode. 911 is supported in both modes. >=20 > Speaking of PBXs, most PBXs in the US will recognize "911", > independent of any prefix that may be used for normal outbound dialing. > They will also recognize + 911. While "9" is commonly used as a > prefix, it's by no means a standard. From my desktop IP phone, I have to > dial "99" as a prefix. If a requirement is desired that references IP > PBX prefixes, perhaps: >=20 > If a prefix is normally required for outside-line dialing by a > UA, the UA SHOULD support mapping of emergency dial strings with or > without the prefix. > Barbara >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of Stastny Richard > Sent: Monday, January 23, 2006 10:33 AM > To: Michael Hammer (mhammer) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 >=20 > IMHO basically all folks from countries having GSM > implemented will accept or > at least will know about 112, which includes all regions > you mentioned >=20 > Richard >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Michael Hammer (mhammer) > [mailto:mhammer@cisco.com] > Sent: Monday, January 23, 2006 4:19 PM > To: Stastny Richard > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 >=20 > I like your approach, but have only one question. >=20 >=20 >=20 > Do folks from Asia, Africa, Australia, and South America > accept that 911 and 112 are the global emergency dial strings? >=20 >=20 >=20 > Mike >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Stastny Richard > [mailto:Richard.Stastny@oefeg.at] > Sent: Monday, January 23, 2006 10:06 AM > To: Raymond Forbes; Michael Hammer (mhammer) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 > I am really getting tired of this discussion, > which goes on now for years, > simply because there is no solution to have home > and local emergency > dial strings working in any case because of > conflicts that are not resolvable > on a global scale, and especially NOT by ECRIT. >=20 >=20 >=20 > Since any user needs to have a dial plan agreed > upon with his provider > (which will be in most cases the home dial plan) > and this dial plan > can be configured into the device >=20 >=20 >=20 > I suggest the following: >=20 >=20 >=20 > The global emergency dial strings 911 and 112 > MUST be supported by any device >=20 > and MUST be mapped to the default sos identifier > In addition, the emergency dial strings > supported in the home dial plan MUST be supported >=20 > and mapped accordingly >=20 >=20 >=20 > Local emergency dial strings may be supported if > there exists no conflict. If the device > is not aware of the local emergency dial strings > or conflicting other dial strings, it MUST NOT > support these dial strings (in doubt) >=20 >=20 >=20 > VoIP users should be made aware at subscription > time that they SHALL only use > 911 or 112 when abroad (also by NENA and EENA) >=20 >=20 >=20 > Regards >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > From: > ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Raymond Forbes > Sent: Monday, January 23, 2006 3:23 PM > To: mhammer@cisco.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 >=20 >=20 > I was only pointing to the example in GSM (3GPP) > today where there most commonly used global numbers are stored in all > SIM modules, and further local national numbers may be additionally > stored. >=20 > This alleviates the need for having a Global > address as the Roaming/Nomadic terminal inter-works with the region it > is in. A global address has certain advantages. >=20 > The GSM solution requires that other national > numbers not in the Prime list may be additionally stored. >=20 > This solves the problem of encountered my the > majority of tourists, US or Japanese Tourists in London. who do not know > that their national number (911 or 110) needs translating to 112. It > does not solve all problems. For example 110 in Germany will reach the > Police not the Emergency services. >=20 > Regards, >=20 > Ray Forbes. >=20 > +44 24 7656 3106 phone > +44 24 7656 3816 fax. > +44 771 851 1361 Mobile/text > ------------ > This e-mail and any attachments are > confidential. If you are not the intended recipient, please notify us > immediately by reply e-mail and then delete this message from your > system. Do not copy this e-mail or any attachments, use the contents for > any purpose, or disclose the contents to any other person: to do so > could be a breach of confidence. >=20 >=20 >=20 >=20 >=20 > "Michael Hammer \(mhammer\)" > >=20 > 23/01/2006 13:45 >=20 >=20 > To: "Hannes Tschofenig" > , "Raymond Forbes" > > cc: , > > Subject: RE: [Ecrit] Issue 30: > Summary >=20 >=20 >=20 >=20 >=20 >=20 > Hannes, >=20 > We still seem to be glossing over terms and > usage it seems. >=20 > When you talk about "emergency numbers", are you > referring to an E.164 > number that the "emergency dial string" gets > translated to? Or, just > that 3 digit emergency code? >=20 > Also, you seem to suggest that each of the > hundred or so emergency dial > strings (112, 911, etc.) are reserved for > emergency use globally. Right > now I understand there are some conflicts. Are > you proposing that all > those emergency codes be reserved for emergency > use in all countries. > That is, where any of those codes is used for > another purpose, that > country must change their usage? So, that the > tourist from any country > can visit any country and any emergency code > will work? >=20 > Mike >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Hannes Tschofenig > > Sent: Monday, January 23, 2006 5:15 AM > > To: Raymond Forbes > > Cc: ecrit-bounces@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > > > > hi raymond, > > > > ~snip~ > > > > > > * Tourist Alice collapses, another > tourist Bob finds the cell > > > > phone of Alice and dials its own home > emergency number > > (because it > > > > does > not know the local emergency > number) and the home > > emergency > > > number is > different from the local > emergency number and > > Alice/Bob > > > have different > home emergency numbers. > > > > > > > > > > That seems essentially unsolvable. Given > typical tourist > > herds that I > > > have observed, they tend to cluster by > nationality (or at least > > > region), if only to make the job of the tour > guide a bit easier :-) > > > > > > [rcf]: GSM Cell Phones address this problem > as they can > > dail a number > > > of Emergency numbers from the SIM Card. The > Phone can translate the > > > Dialled number into the Local Emergency > number 112, 911, > > 110, 111, 000 etc... > > > > > > in gsm there is no equivalent to the global > emergency > > identifier as we discuss it here. > > as such, you need to have a mechanism to > retrieve the local > > emergency numbers in order todo the > translation from the home > > emergency number to the local onces. > > > > ciao > > hannes > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > ***** >=20 > "The information transmitted is intended only for the > person or entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance upon > this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please contact > the sender and delete the material from all computers." 118 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 07:35:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NOa-0005cy-TP; Tue, 24 Jan 2006 07:35:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NOW-0005cc-8r for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 07:35:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07559 for ; Tue, 24 Jan 2006 07:34:01 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NY4-0008MU-EP for ecrit@ietf.org; Tue, 24 Jan 2006 07:45:24 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F1NON-0004nb-1O; Tue, 24 Jan 2006 06:35:23 -0600 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 07:33:22 -0500 Message-ID: <06c401c620e2$5f1e0b20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290777@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYg4NhIbrOa/0PGS+KB8SR8rmQVnQAAJuiw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I suppose this is more terminology confusion, but would you call learning your, let's say, DNS gateway from DHCP "configuration"? If so, then I think you have the requirements pretty close. If learning information from the local environment is not "configuration" then we would have a problem. Unlike Barbara, I think it is the VISITED network's emergency dialstring that must be recognized above all else. Also recognizing the home dialstring would be a good idea. This would mirror current practice, and in the absence of some good evidence that it's the wrong way to go, I think we ought not to change it. If you bring your phone from the UK to the US, then you dial 9-1-1 to get emergency help, and not 9-9-9. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: Tuesday, January 24, 2006 7:21 AM To: ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary To try and make a suggestion based on the discussion so far. I think the key to this is the ability to configure the SIP phone. I would suggest requirements something like the following: - All SIP phones MUST support recognition of emergency numbers keyed by the user, and if recognised, make the call as an emergency call using the universal emergency identifier (i.e. the sos SIP URI or whatever it is). - All SIP phones that are configurable, either locally or remotely, MUST support configuration of recognisable emergency numbers by that mechanism. - SIP phones that are not configurable MUST recognise 112 and 911. I dont think the last will ever need to be implemented in practice as I suspect all SIP phones needs to support some form of configuration. As such I think that if someone wants to provide such a restricted phone, it will only be able to dial full E.164 numbers anyway (i.e. international format), and such numbers do not conflict with 112 and 911. This is why such numbers are defined as stored on the GSM phone, rather than on the UICC/SIM. We do need to add the optional emergency category requirements into the above, but this in my view deals with the generally recognisable numbers issue. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > Clive D.W. Feather > Sent: 24 January 2006 10:15 > To: Raymond Forbes > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary > > > Raymond Forbes said: > > I am not aware that the IETF is interested in UK PSTN > Routeing (999, 112 > > or otherwise) > > It isn't. However, it is interested in PSTN numbering where > that interacts > with ecrit, enum, and so on. > > > 911 is not supported in the UK, > > Correct. > > > 911345 may be a local number, national > > dialling is not required. > > As I said, there are about 30 locations where this is the case. > > > If you dial 911 in the UK it will respond with > > n/u tone as the 6 or 7 digit local number must be dialling > in one sequence > > and mapped by the local exchange. > > Not so. While there is a timeout, my local exchange (I've > just tested it) > will accept a more than 10 second gap between digits. > > It so happens that, if I dial 911 here, I get an announcement > immediately > after the second 1. I get the same announcement if I dial 912 or 753, > because none are valid prefixes. If, however, I'm in one of > those 30 areas > I would expect to get silence after dialling 911 until the > timeout expires. > > -- > Clive D.W. Feather | Work: | Tel: > +44 20 8495 6138 > Internet Expert | Home: | Fax: > +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: > +44 7973 377646 > Thus plc | | > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 10:06:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Pkw-0007BM-BR; Tue, 24 Jan 2006 10:06:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Pku-0007BC-ES for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 10:06:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18346 for ; Tue, 24 Jan 2006 10:05:16 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1PuT-0005We-HP for ecrit@ietf.org; Tue, 24 Jan 2006 10:16:41 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0OF6WjQ023576; Tue, 24 Jan 2006 09:06:34 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Jan 2006 15:05:23 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29077F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'br@brianrosen.net'" , ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 15:05:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well I was going to let someone else turn it into real specification words. By configuration, I guess I mean any mechanism whereby the terminal has the means of learning information about how it should operate, and therefore I guess I would include DHCP in that (if DHCP supports such a mechanism). Thus if the terminal has the means of learning any information, it should also support within that mechanism the learning of information about the emergency dial strings it should recognise. I do not know whether your DHCP mechanism operates on a per emergency request basis, or whether the information is retained in the same way as more normal configuration, but I guess any putting into words should include that distinction. I would also guess that if there were multiple mechanisms, then they would have to be prioritised by some means in order to avoid information conflicts. regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 24 January 2006 12:33 > To: 'Drage, Keith (Keith)'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary > > > I suppose this is more terminology confusion, but would you > call learning > your, let's say, DNS gateway from DHCP "configuration"? If > so, then I think > you have the requirements pretty close. If learning > information from the > local environment is not "configuration" then we would have a problem. > > Unlike Barbara, I think it is the VISITED network's emergency > dialstring > that must be recognized above all else. Also recognizing the home > dialstring would be a good idea. This would mirror current > practice, and in > the absence of some good evidence that it's the wrong way to > go, I think we > ought not to change it. If you bring your phone from the UK > to the US, then > you dial 9-1-1 to get emergency help, and not 9-9-9. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of > Drage, Keith (Keith) > Sent: Tuesday, January 24, 2006 7:21 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary > > To try and make a suggestion based on the discussion so far. > I think the key > to this is the ability to configure the SIP phone. I would suggest > requirements something like the following: > > - All SIP phones MUST support recognition of emergency > numbers keyed > by the user, and if recognised, make the call as an emergency > call using the > universal emergency identifier (i.e. the sos SIP URI or > whatever it is). > > - All SIP phones that are configurable, either locally or > remotely, > MUST support configuration of recognisable emergency numbers by that > mechanism. > > - SIP phones that are not configurable MUST recognise 112 and 911. > > I dont think the last will ever need to be implemented in > practice as I > suspect all SIP phones needs to support some form of > configuration. As such > I think that if someone wants to provide such a restricted > phone, it will > only be able to dial full E.164 numbers anyway (i.e. > international format), > and such numbers do not conflict with 112 and 911. This is > why such numbers > are defined as stored on the GSM phone, rather than on the UICC/SIM. > > We do need to add the optional emergency category > requirements into the > above, but this in my view deals with the generally > recognisable numbers > issue. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > Clive D.W. Feather > > Sent: 24 January 2006 10:15 > > To: Raymond Forbes > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > > > > > > Raymond Forbes said: > > > I am not aware that the IETF is interested in UK PSTN > > Routeing (999, 112 > > > or otherwise) > > > > It isn't. However, it is interested in PSTN numbering where > > that interacts > > with ecrit, enum, and so on. > > > > > 911 is not supported in the UK, > > > > Correct. > > > > > 911345 may be a local number, national > > > dialling is not required. > > > > As I said, there are about 30 locations where this is the case. > > > > > If you dial 911 in the UK it will respond with > > > n/u tone as the 6 or 7 digit local number must be dialling > > in one sequence > > > and mapped by the local exchange. > > > > Not so. While there is a timeout, my local exchange (I've > > just tested it) > > will accept a more than 10 second gap between digits. > > > > It so happens that, if I dial 911 here, I get an announcement > > immediately > > after the second 1. I get the same announcement if I dial > 912 or 753, > > because none are valid prefixes. If, however, I'm in one of > > those 30 areas > > I would expect to get silence after dialling 911 until the > > timeout expires. > > > > -- > > Clive D.W. Feather | Work: | Tel: > > +44 20 8495 6138 > > Internet Expert | Home: | Fax: > > +44 870 051 9937 > > Demon Internet | WWW: http://www.davros.org | Mobile: > > +44 7973 377646 > > Thus plc | | > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 11:00:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QbA-0007An-Ur; Tue, 24 Jan 2006 11:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Qb9-0007AI-G2 for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 11:00:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24733 for ; Tue, 24 Jan 2006 10:59:15 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Qkh-0008KB-OU for ecrit@ietf.org; Tue, 24 Jan 2006 11:10:41 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F1Qb0-0002dg-83; Tue, 24 Jan 2006 10:00:38 -0600 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 10:58:53 -0500 Message-ID: <071601c620ff$154153f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29077F@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYg98WMoWEyZsXORBuPnzou9fSmawAAtH+g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I didn't mean to necessarily imply DHCP was the right mechanism. It was just a convenient example of how a device learns from its environment rather than something pushed into it, which is the usual meaning of "configured". I happen to think that DHCP would be a good way to pass a visited network emergency dialstring IF it is also providing location, but there could be other mechanisms. Brian -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Tuesday, January 24, 2006 10:05 AM To: 'br@brianrosen.net'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Well I was going to let someone else turn it into real specification words. By configuration, I guess I mean any mechanism whereby the terminal has the means of learning information about how it should operate, and therefore I guess I would include DHCP in that (if DHCP supports such a mechanism). Thus if the terminal has the means of learning any information, it should also support within that mechanism the learning of information about the emergency dial strings it should recognise. I do not know whether your DHCP mechanism operates on a per emergency request basis, or whether the information is retained in the same way as more normal configuration, but I guess any putting into words should include that distinction. I would also guess that if there were multiple mechanisms, then they would have to be prioritised by some means in order to avoid information conflicts. regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 24 January 2006 12:33 > To: 'Drage, Keith (Keith)'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary > > > I suppose this is more terminology confusion, but would you > call learning > your, let's say, DNS gateway from DHCP "configuration"? If > so, then I think > you have the requirements pretty close. If learning > information from the > local environment is not "configuration" then we would have a problem. > > Unlike Barbara, I think it is the VISITED network's emergency > dialstring > that must be recognized above all else. Also recognizing the home > dialstring would be a good idea. This would mirror current > practice, and in > the absence of some good evidence that it's the wrong way to > go, I think we > ought not to change it. If you bring your phone from the UK > to the US, then > you dial 9-1-1 to get emergency help, and not 9-9-9. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of > Drage, Keith (Keith) > Sent: Tuesday, January 24, 2006 7:21 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary > > To try and make a suggestion based on the discussion so far. > I think the key > to this is the ability to configure the SIP phone. I would suggest > requirements something like the following: > > - All SIP phones MUST support recognition of emergency > numbers keyed > by the user, and if recognised, make the call as an emergency > call using the > universal emergency identifier (i.e. the sos SIP URI or > whatever it is). > > - All SIP phones that are configurable, either locally or > remotely, > MUST support configuration of recognisable emergency numbers by that > mechanism. > > - SIP phones that are not configurable MUST recognise 112 and 911. > > I dont think the last will ever need to be implemented in > practice as I > suspect all SIP phones needs to support some form of > configuration. As such > I think that if someone wants to provide such a restricted > phone, it will > only be able to dial full E.164 numbers anyway (i.e. > international format), > and such numbers do not conflict with 112 and 911. This is > why such numbers > are defined as stored on the GSM phone, rather than on the UICC/SIM. > > We do need to add the optional emergency category > requirements into the > above, but this in my view deals with the generally > recognisable numbers > issue. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > Clive D.W. Feather > > Sent: 24 January 2006 10:15 > > To: Raymond Forbes > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > > > > > > Raymond Forbes said: > > > I am not aware that the IETF is interested in UK PSTN > > Routeing (999, 112 > > > or otherwise) > > > > It isn't. However, it is interested in PSTN numbering where > > that interacts > > with ecrit, enum, and so on. > > > > > 911 is not supported in the UK, > > > > Correct. > > > > > 911345 may be a local number, national > > > dialling is not required. > > > > As I said, there are about 30 locations where this is the case. > > > > > If you dial 911 in the UK it will respond with > > > n/u tone as the 6 or 7 digit local number must be dialling > > in one sequence > > > and mapped by the local exchange. > > > > Not so. While there is a timeout, my local exchange (I've > > just tested it) > > will accept a more than 10 second gap between digits. > > > > It so happens that, if I dial 911 here, I get an announcement > > immediately > > after the second 1. I get the same announcement if I dial > 912 or 753, > > because none are valid prefixes. If, however, I'm in one of > > those 30 areas > > I would expect to get silence after dialling 911 until the > > timeout expires. > > > > -- > > Clive D.W. Feather | Work: | Tel: > > +44 20 8495 6138 > > Internet Expert | Home: | Fax: > > +44 870 051 9937 > > Demon Internet | WWW: http://www.davros.org | Mobile: > > +44 7973 377646 > > Thus plc | | > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 12:04:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1RbB-0001vb-IT; Tue, 24 Jan 2006 12:04:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1RbA-0001vV-On for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 12:04:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00286 for ; Tue, 24 Jan 2006 12:03:22 -0500 (EST) From: g.caron@bell.ca Received: from bellwecs1.bellnexxia.net ([207.236.237.113] helo=bellwecs1.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1Rkh-0002Yp-CT for ecrit@ietf.org; Tue, 24 Jan 2006 12:14:47 -0500 Received: (qmail 1613 invoked from network); 24 Jan 2006 17:03:48 -0000 Received: from g.caron@bell.ca by bellwecs1.srvr.bell.ca with EntrustECS-Server-7.4; 24 Jan 2006 17:03:48 -0000 Received: from bellwfep2.bellnexxia.net (HELO bellwfep2-srv.bellnexxia.net) (207.236.237.108) by bellwecs1.srvr.bell.ca with SMTP; 24 Jan 2006 17:03:48 -0000 Received: from toroondc550.bell.corp.bce.ca ([142.182.84.162]) by bellwfep2-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20060124170337.YUFA6632.bellwfep2-srv.bellnexxia.net@toroondc550.bell.corp.bce.ca>; Tue, 24 Jan 2006 12:03:37 -0500 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 12:03:38 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 12:03:38 -0500 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF303A907A9@toroondc912> Thread-Topic: [Ecrit] Issue 30: Summary thread-index: AcYg98WMoWEyZsXORBuPnzou9fSmawAAtH+gAAKh+VA= To: , , X-OriginalArrivalTime: 24 Jan 2006 17:03:38.0689 (UTC) FILETIME=[1ECDB310:01C62108] X-Spam-Score: 0.3 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >From a user experience stand point, I would like to learn only my "home" = emergency dialstring and use it wherever I am and let the "network" do = the translation into a standardized and recognisable URI. So if, for = example, I'm used to dial "9-1-1" for help and I'm travelling in = Australia, I would still dial "9-1-1" and get appropriately routed to = the Australian PSAP as an emergency call. This to me would clearly be = added value to VoIP services. Now, depending if the Network interfaces or not with PSTN gears to route = the call (i.e, Selective routers), may impedes this functionality as = those would likely need to interpret the emergency dialstring to = properly process the call. If there are no such things, I don't = understand why "visited" dialstrings would be required. My 2 cents... Guy Caron -----Message d'origine----- De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part = de Brian Rosen Envoy=E9=A0: 24 janvier 2006 10:59 =C0=A0: 'Drage, Keith (Keith)'; ecrit@ietf.org Objet=A0: RE: [Ecrit] Issue 30: Summary I didn't mean to necessarily imply DHCP was the right mechanism. It was just a convenient example of how a device learns from its environment = rather than something pushed into it, which is the usual meaning of = "configured". I happen to think that DHCP would be a good way to pass a visited = network emergency dialstring IF it is also providing location, but there could = be other mechanisms. Brian -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Tuesday, January 24, 2006 10:05 AM To: 'br@brianrosen.net'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Well I was going to let someone else turn it into real specification = words. By configuration, I guess I mean any mechanism whereby the terminal has = the means of learning information about how it should operate, and therefore = I guess I would include DHCP in that (if DHCP supports such a mechanism). = Thus if the terminal has the means of learning any information, it should = also support within that mechanism the learning of information about the emergency dial strings it should recognise. I do not know whether your DHCP mechanism operates on a per emergency request basis, or whether the information is retained in the same way as more normal configuration, but I guess any putting into words should = include that distinction. I would also guess that if there were multiple mechanisms, then they = would have to be prioritised by some means in order to avoid information conflicts.=20 regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 24 January 2006 12:33 > To: 'Drage, Keith (Keith)'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 > I suppose this is more terminology confusion, but would you=20 > call learning > your, let's say, DNS gateway from DHCP "configuration"? If=20 > so, then I think > you have the requirements pretty close. If learning=20 > information from the > local environment is not "configuration" then we would have a problem. >=20 > Unlike Barbara, I think it is the VISITED network's emergency=20 > dialstring > that must be recognized above all else. Also recognizing the home > dialstring would be a good idea. This would mirror current=20 > practice, and in > the absence of some good evidence that it's the wrong way to=20 > go, I think we > ought not to change it. If you bring your phone from the UK=20 > to the US, then > you dial 9-1-1 to get emergency help, and not 9-9-9. =20 >=20 > Brian =20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of > Drage, Keith (Keith) > Sent: Tuesday, January 24, 2006 7:21 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 > To try and make a suggestion based on the discussion so far.=20 > I think the key > to this is the ability to configure the SIP phone. I would suggest > requirements something like the following: >=20 > - All SIP phones MUST support recognition of emergency=20 > numbers keyed > by the user, and if recognised, make the call as an emergency=20 > call using the > universal emergency identifier (i.e. the sos SIP URI or=20 > whatever it is). >=20 > - All SIP phones that are configurable, either locally or=20 > remotely, > MUST support configuration of recognisable emergency numbers by that > mechanism.=20 >=20 > - SIP phones that are not configurable MUST recognise 112 and 911. >=20 > I dont think the last will ever need to be implemented in=20 > practice as I > suspect all SIP phones needs to support some form of=20 > configuration. As such > I think that if someone wants to provide such a restricted=20 > phone, it will > only be able to dial full E.164 numbers anyway (i.e.=20 > international format), > and such numbers do not conflict with 112 and 911. This is=20 > why such numbers > are defined as stored on the GSM phone, rather than on the UICC/SIM. >=20 > We do need to add the optional emergency category=20 > requirements into the > above, but this in my view deals with the generally=20 > recognisable numbers > issue. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > Clive D.W. Feather > > Sent: 24 January 2006 10:15 > > To: Raymond Forbes > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > >=20 > >=20 > > Raymond Forbes said: > > > I am not aware that the IETF is interested in UK PSTN=20 > > Routeing (999, 112=20 > > > or otherwise) > >=20 > > It isn't. However, it is interested in PSTN numbering where=20 > > that interacts > > with ecrit, enum, and so on. > >=20 > > > 911 is not supported in the UK, > >=20 > > Correct. > >=20 > > > 911345 may be a local number, national=20 > > > dialling is not required. > >=20 > > As I said, there are about 30 locations where this is the case. > >=20 > > > If you dial 911 in the UK it will respond with=20 > > > n/u tone as the 6 or 7 digit local number must be dialling=20 > > in one sequence=20 > > > and mapped by the local exchange. > >=20 > > Not so. While there is a timeout, my local exchange (I've=20 > > just tested it) > > will accept a more than 10 second gap between digits. > >=20 > > It so happens that, if I dial 911 here, I get an announcement=20 > > immediately > > after the second 1. I get the same announcement if I dial=20 > 912 or 753, > > because none are valid prefixes. If, however, I'm in one of=20 > > those 30 areas > > I would expect to get silence after dialling 911 until the=20 > > timeout expires. > >=20 > > --=20 > > Clive D.W. Feather | Work: | Tel: =20 > > +44 20 8495 6138 > > Internet Expert | Home: | Fax: =20 > > +44 870 051 9937 > > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > > +44 7973 377646 > > Thus plc | | > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 24 12:17:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1RnS-00005q-Rr; Tue, 24 Jan 2006 12:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1RnR-00005Q-7M for ecrit@megatron.ietf.org; Tue, 24 Jan 2006 12:17:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01496 for ; Tue, 24 Jan 2006 12:16:03 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Rwz-00037p-AU for ecrit@ietf.org; Tue, 24 Jan 2006 12:27:28 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F1RnE-0005ha-Ne; Tue, 24 Jan 2006 11:17:21 -0600 From: "Brian Rosen" To: , , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 24 Jan 2006 12:15:47 -0500 Message-ID: <073f01c62109$d3464d60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF303A907A9@toroondc912> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYg98WMoWEyZsXORBuPnzou9fSmawAAtH+gAAKh+VAAAN5mkA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think it is desirable for your phone to respond to the emergency dialstring from your home location. I think it is required that it = respond to the visited emergency dialstring. We can make it work with either; = it's not a requirement because of any other element. The emergency number in North America is 9-1-1, and it's the emergency number in North America whether you are a resident or a visitor. That should not change. It may even be law in some places. Signs tell you = that. They don't say "For help, call your home emergency number", around here = they say "For help, dial 9-1-1". Pick up any phone, on any carrier, wireline = or wireless, and you dial 9-1-1 to get help in North America. Other = numbers may work (1-1-2 for example), but 9-1-1 ALWAYS works. We need to keep = it that way. Brian -----Original Message----- From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 Sent: Tuesday, January 24, 2006 12:04 PM To: br@brianrosen.net; drage@lucent.com; ecrit@ietf.org Subject: RE : [Ecrit] Issue 30: Summary >From a user experience stand point, I would like to learn only my = "home" emergency dialstring and use it wherever I am and let the "network" do = the translation into a standardized and recognisable URI. So if, for = example, I'm used to dial "9-1-1" for help and I'm travelling in Australia, I = would still dial "9-1-1" and get appropriately routed to the Australian PSAP = as an emergency call. This to me would clearly be added value to VoIP = services. Now, depending if the Network interfaces or not with PSTN gears to route = the call (i.e, Selective routers), may impedes this functionality as those = would likely need to interpret the emergency dialstring to properly process = the call. If there are no such things, I don't understand why "visited" dialstrings would be required. My 2 cents... Guy Caron -----Message d'origine----- De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part = de Brian Rosen Envoy=E9=A0: 24 janvier 2006 10:59 =C0=A0: 'Drage, Keith (Keith)'; ecrit@ietf.org Objet=A0: RE: [Ecrit] Issue 30: Summary I didn't mean to necessarily imply DHCP was the right mechanism. It was just a convenient example of how a device learns from its environment = rather than something pushed into it, which is the usual meaning of = "configured". I happen to think that DHCP would be a good way to pass a visited = network emergency dialstring IF it is also providing location, but there could = be other mechanisms. Brian -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Tuesday, January 24, 2006 10:05 AM To: 'br@brianrosen.net'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Well I was going to let someone else turn it into real specification = words. By configuration, I guess I mean any mechanism whereby the terminal has = the means of learning information about how it should operate, and therefore = I guess I would include DHCP in that (if DHCP supports such a mechanism). = Thus if the terminal has the means of learning any information, it should = also support within that mechanism the learning of information about the emergency dial strings it should recognise. I do not know whether your DHCP mechanism operates on a per emergency request basis, or whether the information is retained in the same way as more normal configuration, but I guess any putting into words should = include that distinction. I would also guess that if there were multiple mechanisms, then they = would have to be prioritised by some means in order to avoid information conflicts.=20 regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 24 January 2006 12:33 > To: 'Drage, Keith (Keith)'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 > I suppose this is more terminology confusion, but would you=20 > call learning > your, let's say, DNS gateway from DHCP "configuration"? If=20 > so, then I think > you have the requirements pretty close. If learning=20 > information from the > local environment is not "configuration" then we would have a problem. >=20 > Unlike Barbara, I think it is the VISITED network's emergency=20 > dialstring > that must be recognized above all else. Also recognizing the home > dialstring would be a good idea. This would mirror current=20 > practice, and in > the absence of some good evidence that it's the wrong way to=20 > go, I think we > ought not to change it. If you bring your phone from the UK=20 > to the US, then > you dial 9-1-1 to get emergency help, and not 9-9-9. =20 >=20 > Brian =20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of > Drage, Keith (Keith) > Sent: Tuesday, January 24, 2006 7:21 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 > To try and make a suggestion based on the discussion so far.=20 > I think the key > to this is the ability to configure the SIP phone. I would suggest > requirements something like the following: >=20 > - All SIP phones MUST support recognition of emergency=20 > numbers keyed > by the user, and if recognised, make the call as an emergency=20 > call using the > universal emergency identifier (i.e. the sos SIP URI or=20 > whatever it is). >=20 > - All SIP phones that are configurable, either locally or=20 > remotely, > MUST support configuration of recognisable emergency numbers by that > mechanism.=20 >=20 > - SIP phones that are not configurable MUST recognise 112 and 911. >=20 > I dont think the last will ever need to be implemented in=20 > practice as I > suspect all SIP phones needs to support some form of=20 > configuration. As such > I think that if someone wants to provide such a restricted=20 > phone, it will > only be able to dial full E.164 numbers anyway (i.e.=20 > international format), > and such numbers do not conflict with 112 and 911. This is=20 > why such numbers > are defined as stored on the GSM phone, rather than on the UICC/SIM. >=20 > We do need to add the optional emergency category=20 > requirements into the > above, but this in my view deals with the generally=20 > recognisable numbers > issue. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > Clive D.W. Feather > > Sent: 24 January 2006 10:15 > > To: Raymond Forbes > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Issue 30: Summary > >=20 > >=20 > > Raymond Forbes said: > > > I am not aware that the IETF is interested in UK PSTN=20 > > Routeing (999, 112=20 > > > or otherwise) > >=20 > > It isn't. However, it is interested in PSTN numbering where=20 > > that interacts > > with ecrit, enum, and so on. > >=20 > > > 911 is not supported in the UK, > >=20 > > Correct. > >=20 > > > 911345 may be a local number, national=20 > > > dialling is not required. > >=20 > > As I said, there are about 30 locations where this is the case. > >=20 > > > If you dial 911 in the UK it will respond with=20 > > > n/u tone as the 6 or 7 digit local number must be dialling=20 > > in one sequence=20 > > > and mapped by the local exchange. > >=20 > > Not so. While there is a timeout, my local exchange (I've=20 > > just tested it) > > will accept a more than 10 second gap between digits. > >=20 > > It so happens that, if I dial 911 here, I get an announcement=20 > > immediately > > after the second 1. I get the same announcement if I dial=20 > 912 or 753, > > because none are valid prefixes. If, however, I'm in one of=20 > > those 30 areas > > I would expect to get silence after dialling 911 until the=20 > > timeout expires. > >=20 > > --=20 > > Clive D.W. Feather | Work: | Tel: =20 > > +44 20 8495 6138 > > Internet Expert | Home: | Fax: =20 > > +44 870 051 9937 > > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > > +44 7973 377646 > > Thus plc | | > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 25 11:27:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1nUM-0004ar-K4; Wed, 25 Jan 2006 11:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1nUK-0004ag-Oi for ecrit@megatron.ietf.org; Wed, 25 Jan 2006 11:27:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26638 for ; Wed, 25 Jan 2006 11:25:44 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ne5-00072R-LD for ecrit@ietf.org; Wed, 25 Jan 2006 11:37:23 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0PGQsbj018456; Wed, 25 Jan 2006 10:26:58 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Jan 2006 16:26:53 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29078D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'br@brianrosen.net'" , ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Date: Wed, 25 Jan 2006 16:27:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I consider this very much a fixed line view of the world. In the = wireless environment, people still expect the same thing to happen on = the same phone, even if it has crossed the national border. Conversely, = if they see an emergency vehicle in the visited country that says dial = 9-1-1 then they will try that. Therefore you will get all possible = combinations of expectations, and in emergency calls, one cannot afford = not to resolve the problem. As a result the 3GPP cellphone standards try to take account of both = views of the world, but this does involve both giving the customers = information on their SIM/UICC card, downloading the local numbers to = the terminal, and still having to catch the emergency calls that have = escaped prior recognition in the network. This complexity is the reason I have argued for configuration = requirements. regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 24 January 2006 17:16 > To: g.caron@bell.ca; drage@lucent.com; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 >=20 > include the big > picture, but I don't think it currently is. Defining=20 > universal identifiers, > and even figuring out what visited/local emergency=20 > dialstrings probably is, > but actual phone behavior probably is not. This material=20 > would have to live > in a phone BCP if we were to document it> >=20 > I think it is desirable for your phone to respond to the emergency > dialstring from your home location. I think it is required=20 > that it respond > to the visited emergency dialstring. We can make it work=20 > with either; it's > not a requirement because of any other element. >=20 > The emergency number in North America is 9-1-1, and it's the = emergency > number in North America whether you are a resident or a visitor. = That > should not change. It may even be law in some places. Signs=20 > tell you that. > They don't say "For help, call your home emergency number",=20 > around here they > say "For help, dial 9-1-1". Pick up any phone, on any=20 > carrier, wireline or > wireless, and you dial 9-1-1 to get help in North America. =20 > Other numbers > may work (1-1-2 for example), but 9-1-1 ALWAYS works. We=20 > need to keep it > that way. >=20 > Brian >=20 > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 > Sent: Tuesday, January 24, 2006 12:04 PM > To: br@brianrosen.net; drage@lucent.com; ecrit@ietf.org > Subject: RE : [Ecrit] Issue 30: Summary >=20 >=20 >=20 > >From a user experience stand point, I would like to learn=20 > only my "home" > emergency dialstring and use it wherever I am and let the=20 > "network" do the > translation into a standardized and recognisable URI. So if,=20 > for example, > I'm used to dial "9-1-1" for help and I'm travelling in=20 > Australia, I would > still dial "9-1-1" and get appropriately routed to the=20 > Australian PSAP as an > emergency call. This to me would clearly be added value to=20 > VoIP services. >=20 > Now, depending if the Network interfaces or not with PSTN=20 > gears to route the > call (i.e, Selective routers), may impedes this functionality=20 > as those would > likely need to interpret the emergency dialstring to properly=20 > process the > call. If there are no such things, I don't understand why "visited" > dialstrings would be required. >=20 > My 2 cents... >=20 >=20 > Guy Caron >=20 >=20 > -----Message d'origine----- > De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > De la part de > Brian Rosen > Envoy=E9=A0: 24 janvier 2006 10:59 > =C0=A0: 'Drage, Keith (Keith)'; ecrit@ietf.org > Objet=A0: RE: [Ecrit] Issue 30: Summary >=20 > I didn't mean to necessarily imply DHCP was the right=20 > mechanism. It was > just a convenient example of how a device learns from its > environment rather > than something pushed into it, which is the usual meaning of=20 > "configured". >=20 > I happen to think that DHCP would be a good way to pass a=20 > visited network > emergency dialstring IF it is also providing location, but=20 > there could be > other mechanisms. >=20 > Brian >=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Tuesday, January 24, 2006 10:05 AM > To: 'br@brianrosen.net'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 > Well I was going to let someone else turn it into real=20 > specification words. >=20 > By configuration, I guess I mean any mechanism whereby the=20 > terminal has the > means of learning information about how it should operate,=20 > and therefore I > guess I would include DHCP in that (if DHCP supports such a=20 > mechanism). Thus > if the terminal has the means of learning any information, it=20 > should also > support within that mechanism the learning of information about the > emergency dial strings it should recognise. >=20 > I do not know whether your DHCP mechanism operates on a per emergency > request basis, or whether the information is retained in the=20 > same way as > more normal configuration, but I guess any putting into words=20 > should include > that distinction. >=20 > I would also guess that if there were multiple mechanisms,=20 > then they would > have to be prioritised by some means in order to avoid information > conflicts.=20 >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 24 January 2006 12:33 > > To: 'Drage, Keith (Keith)'; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue 30: Summary > >=20 > >=20 > > I suppose this is more terminology confusion, but would you=20 > > call learning > > your, let's say, DNS gateway from DHCP "configuration"? If=20 > > so, then I think > > you have the requirements pretty close. If learning=20 > > information from the > > local environment is not "configuration" then we would have=20 > a problem. > >=20 > > Unlike Barbara, I think it is the VISITED network's emergency=20 > > dialstring > > that must be recognized above all else. Also recognizing the home > > dialstring would be a good idea. This would mirror current=20 > > practice, and in > > the absence of some good evidence that it's the wrong way to=20 > > go, I think we > > ought not to change it. If you bring your phone from the UK=20 > > to the US, then > > you dial 9-1-1 to get emergency help, and not 9-9-9. =20 > >=20 > > Brian =20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > On Behalf Of > > Drage, Keith (Keith) > > Sent: Tuesday, January 24, 2006 7:21 AM > > To: ecrit@ietf.org > > Subject: RE: [Ecrit] Issue 30: Summary > >=20 > > To try and make a suggestion based on the discussion so far.=20 > > I think the key > > to this is the ability to configure the SIP phone. I would suggest > > requirements something like the following: > >=20 > > - All SIP phones MUST support recognition of emergency=20 > > numbers keyed > > by the user, and if recognised, make the call as an emergency=20 > > call using the > > universal emergency identifier (i.e. the sos SIP URI or=20 > > whatever it is). > >=20 > > - All SIP phones that are configurable, either locally or=20 > > remotely, > > MUST support configuration of recognisable emergency numbers by = that > > mechanism.=20 > >=20 > > - SIP phones that are not configurable MUST recognise 112 and 911. > >=20 > > I dont think the last will ever need to be implemented in=20 > > practice as I > > suspect all SIP phones needs to support some form of=20 > > configuration. As such > > I think that if someone wants to provide such a restricted=20 > > phone, it will > > only be able to dial full E.164 numbers anyway (i.e.=20 > > international format), > > and such numbers do not conflict with 112 and 911. This is=20 > > why such numbers > > are defined as stored on the GSM phone, rather than on the = UICC/SIM. > >=20 > > We do need to add the optional emergency category=20 > > requirements into the > > above, but this in my view deals with the generally=20 > > recognisable numbers > > issue. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org=20 > > > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > > Clive D.W. Feather > > > Sent: 24 January 2006 10:15 > > > To: Raymond Forbes > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Issue 30: Summary > > >=20 > > >=20 > > > Raymond Forbes said: > > > > I am not aware that the IETF is interested in UK PSTN=20 > > > Routeing (999, 112=20 > > > > or otherwise) > > >=20 > > > It isn't. However, it is interested in PSTN numbering where=20 > > > that interacts > > > with ecrit, enum, and so on. > > >=20 > > > > 911 is not supported in the UK, > > >=20 > > > Correct. > > >=20 > > > > 911345 may be a local number, national=20 > > > > dialling is not required. > > >=20 > > > As I said, there are about 30 locations where this is the case. > > >=20 > > > > If you dial 911 in the UK it will respond with=20 > > > > n/u tone as the 6 or 7 digit local number must be dialling=20 > > > in one sequence=20 > > > > and mapped by the local exchange. > > >=20 > > > Not so. While there is a timeout, my local exchange (I've=20 > > > just tested it) > > > will accept a more than 10 second gap between digits. > > >=20 > > > It so happens that, if I dial 911 here, I get an announcement=20 > > > immediately > > > after the second 1. I get the same announcement if I dial=20 > > 912 or 753, > > > because none are valid prefixes. If, however, I'm in one of=20 > > > those 30 areas > > > I would expect to get silence after dialling 911 until the=20 > > > timeout expires. > > >=20 > > > --=20 > > > Clive D.W. Feather | Work: | Tel: =20 > > > +44 20 8495 6138 > > > Internet Expert | Home: | Fax: =20 > > > +44 870 051 9937 > > > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > > > +44 7973 377646 > > > Thus plc | | > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 25 19:15:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1un6-0006jQ-K0; Wed, 25 Jan 2006 19:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1un5-0006j9-48 for ecrit@megatron.ietf.org; Wed, 25 Jan 2006 19:15:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13521 for ; Wed, 25 Jan 2006 19:13:36 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1uwu-0001jV-Fb for ecrit@ietf.org; Wed, 25 Jan 2006 19:25:17 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0Q0Eui2003748 for ; Thu, 26 Jan 2006 01:14:56 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k0Q0EMd0015999 for ; Thu, 26 Jan 2006 01:14:56 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 01:14:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2006 01:14:24 +0100 Message-ID: Thread-Topic: Reading List for the Interim Meeting Thread-Index: AcYiBH/7t9yCy0jdQ+SLlKwdM9b5wA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 26 Jan 2006 00:14:24.0523 (UTC) FILETIME=[7688BDB0:01C6220D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Reading List for the Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please do not forget to read the working group documents:=20 http://www.ietf-ecrit.org/Interim2006/ecrit-interim.txt additionally, take a look at:=20 http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-0 1.txt if you still have time you might want to take a look at ongoing emergency work by the 3gpp: http://www.3gpp.org/ftp/Specs/archive/23_series/23.867/23867-710.zip ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 25 19:44:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1vFD-00033Q-2h; Wed, 25 Jan 2006 19:44:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1vFC-00031q-2w for ecrit@megatron.ietf.org; Wed, 25 Jan 2006 19:44:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18219 for ; Wed, 25 Jan 2006 19:42:39 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1vP0-0003Zl-53 for ecrit@ietf.org; Wed, 25 Jan 2006 19:54:21 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2006 16:43:58 -0800 X-IronPort-AV: i="4.01,219,1136188800"; d="scan'208"; a="251407940:sNHT29226834" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0Q0hvWF026546 for ; Wed, 25 Jan 2006 16:43:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 16:43:57 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.121.103]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 16:43:56 -0800 Message-Id: <4.3.2.7.2.20060125183951.018c2d90@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jan 2006 18:43:55 -0600 To: From: "James M. Polk" Subject: Re: [Ecrit] Reading List for the Interim Meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jan 2006 00:43:57.0128 (UTC) FILETIME=[9716CC80:01C62211] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:14 AM 1/26/2006 +0100, Tschofenig, Hannes wrote: >hi all, > >additionally, take a look at: >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-0 >1.txt I hope to have a new version of this ID out before the interim. A lot of what's said in -01 will be in -02, it'll just be said differently (more succinct, better arranged, etc). Plus I have a plan to take all the fully decoded message flow examples into a separate SIPPING ID. >ciao >hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 03:18:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F22L6-0001Nb-By; Thu, 26 Jan 2006 03:18:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F22L5-0001NI-KT for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 03:18:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21867 for ; Thu, 26 Jan 2006 03:17:11 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F22Uy-0001yP-Ur for ecrit@ietf.org; Thu, 26 Jan 2006 03:28:58 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0Q8IUOF012366; Thu, 26 Jan 2006 09:18:30 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k0Q8IUJO015926; Thu, 26 Jan 2006 09:18:30 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 09:18:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Reading List for the Interim Meeting Date: Thu, 26 Jan 2006 09:18:19 +0100 Message-ID: Thread-Topic: [Ecrit] Reading List for the Interim Meeting Thread-Index: AcYiEdOXZRBlba3lSFab1HoSw2urTQAPpngg From: "Tschofenig, Hannes" To: "James M. Polk" , X-OriginalArrivalTime: 26 Jan 2006 08:18:29.0979 (UTC) FILETIME=[16F99AB0:01C62251] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi james,=20 thanks for this information. why would you like to split the examples = into a separate document? maybe you can briefly give us an overview what is needed to finish this = document.=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von James M. Polk > Gesendet: Donnerstag, 26. Januar 2006 01:44 > An: ecrit@ietf.org > Betreff: Re: [Ecrit] Reading List for the Interim Meeting >=20 > At 01:14 AM 1/26/2006 +0100, Tschofenig, Hannes wrote: > >hi all, > > > >additionally, take a look at: > >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-c > onveyance-0 > >1.txt >=20 > I hope to have a new version of this ID out before the=20 > interim. A lot of=20 > what's said in -01 will be in -02, it'll just be said=20 > differently (more=20 > succinct, better arranged, etc). Plus I have a plan to take=20 > all the fully=20 > decoded message flow examples into a separate SIPPING ID. >=20 >=20 > >ciao > >hannes > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 04:31:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F23T9-00039r-TP; Thu, 26 Jan 2006 04:31:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F23T7-00039h-En for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 04:31:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26621 for ; Thu, 26 Jan 2006 04:29:32 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F23d1-0004HM-RH for ecrit@ietf.org; Thu, 26 Jan 2006 04:41:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Issue 30: Summary Date: Thu, 26 Jan 2006 10:34:38 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2379@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYhzPJFAXzMyi9nQ+qBuSqf78HxwwAi4o4Q From: "Stastny Richard" To: "Drage, Keith \(Keith\)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As I said before that this problem is in principle unsolvable, If you only consider dialing numbers (and not an SOS button, which has been proven to be not a good idea) Every VoIP provider is providing his users with a dialing plan (normally his home dialing plan, whatever this is) and this dialing plan is the same if the user is at home or nomadic. Changing the dialing plan depending on location is not a good idea, because: 1. the device needs to know the location 2. this will be very confusing for the users, especially in countries where you have a local dialing plan. So by default home emergency numbers and 112 will work 911 seems to have problems Even if you load the emergency numbers in the visited network from somewhere into the device, the question remains, which numbers take preference if a clash occurs (and we have seen that there is a number of clashes) One way out of this problem would be to establish a (currently not existing) global DIALING plan for VoIP devices. This would be very simple, all E.164 numbers need to be dialled in the international format using the "+", such as +1-234-567-8900 This seems to be more nasty as it is, because users of mobile phones in non-US countries, say in Europe, are already used to store their numbers in the contact list in this format anyway (to be able to use their contact list anywhere) and most calls are made via the contact list, last calls or missed calls list ect anyway. This would open the whole number space for non-E164 numbers (service numbers) and within this number space the problem should be solvable, first defining 112 and 911 and then=20 Other service numbers (eg escape codes for national or provider specific service codes) It is up to an international standards body (say ITU-T) to define this number space. This cannot be solved in ECRIT, although ECRIT may deliver input. Regards Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Drage, Keith (Keith) > Sent: Wednesday, January 25, 2006 5:28 PM > To: 'br@brianrosen.net'; ecrit@ietf.org > Subject: RE: [Ecrit] Issue 30: Summary >=20 > I consider this very much a fixed line view of the world. In the = wireless > environment, people still expect the same thing to happen on the same > phone, even if it has crossed the national border. Conversely, if they = see > an emergency vehicle in the visited country that says dial 9-1-1 then = they > will try that. Therefore you will get all possible combinations of > expectations, and in emergency calls, one cannot afford not to resolve = the > problem. >=20 > As a result the 3GPP cellphone standards try to take account of both = views > of the world, but this does involve both giving the customers = information > on their SIM/UICC card, downloading the local numbers to the terminal, = and > still having to catch the emergency calls that have escaped prior > recognition in the network. >=20 > This complexity is the reason I have argued for configuration > requirements. >=20 > regards >=20 > Keith >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 24 January 2006 17:16 > > To: g.caron@bell.ca; drage@lucent.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue 30: Summary > > > > > > > include the big > > picture, but I don't think it currently is. Defining > > universal identifiers, > > and even figuring out what visited/local emergency > > dialstrings probably is, > > but actual phone behavior probably is not. This material > > would have to live > > in a phone BCP if we were to document it> > > > > I think it is desirable for your phone to respond to the emergency > > dialstring from your home location. I think it is required > > that it respond > > to the visited emergency dialstring. We can make it work > > with either; it's > > not a requirement because of any other element. > > > > The emergency number in North America is 9-1-1, and it's the = emergency > > number in North America whether you are a resident or a visitor. = That > > should not change. It may even be law in some places. Signs > > tell you that. > > They don't say "For help, call your home emergency number", > > around here they > > say "For help, dial 9-1-1". Pick up any phone, on any > > carrier, wireline or > > wireless, and you dial 9-1-1 to get help in North America. > > Other numbers > > may work (1-1-2 for example), but 9-1-1 ALWAYS works. We > > need to keep it > > that way. > > > > Brian > > > > -----Original Message----- > > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > > Sent: Tuesday, January 24, 2006 12:04 PM > > To: br@brianrosen.net; drage@lucent.com; ecrit@ietf.org > > Subject: RE : [Ecrit] Issue 30: Summary > > > > > > > > >From a user experience stand point, I would like to learn > > only my "home" > > emergency dialstring and use it wherever I am and let the > > "network" do the > > translation into a standardized and recognisable URI. So if, > > for example, > > I'm used to dial "9-1-1" for help and I'm travelling in > > Australia, I would > > still dial "9-1-1" and get appropriately routed to the > > Australian PSAP as an > > emergency call. This to me would clearly be added value to > > VoIP services. > > > > Now, depending if the Network interfaces or not with PSTN > > gears to route the > > call (i.e, Selective routers), may impedes this functionality > > as those would > > likely need to interpret the emergency dialstring to properly > > process the > > call. If there are no such things, I don't understand why "visited" > > dialstrings would be required. > > > > My 2 cents... > > > > > > Guy Caron > > > > > > -----Message d'origine----- > > De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > De la part de > > Brian Rosen > > Envoy=E9=A0: 24 janvier 2006 10:59 > > =C0=A0: 'Drage, Keith (Keith)'; ecrit@ietf.org > > Objet=A0: RE: [Ecrit] Issue 30: Summary > > > > I didn't mean to necessarily imply DHCP was the right > > mechanism. It was > > just a convenient example of how a device learns from its > > environment rather > > than something pushed into it, which is the usual meaning of > > "configured". > > > > I happen to think that DHCP would be a good way to pass a > > visited network > > emergency dialstring IF it is also providing location, but > > there could be > > other mechanisms. > > > > Brian > > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Tuesday, January 24, 2006 10:05 AM > > To: 'br@brianrosen.net'; ecrit@ietf.org > > Subject: RE: [Ecrit] Issue 30: Summary > > > > Well I was going to let someone else turn it into real > > specification words. > > > > By configuration, I guess I mean any mechanism whereby the > > terminal has the > > means of learning information about how it should operate, > > and therefore I > > guess I would include DHCP in that (if DHCP supports such a > > mechanism). Thus > > if the terminal has the means of learning any information, it > > should also > > support within that mechanism the learning of information about the > > emergency dial strings it should recognise. > > > > I do not know whether your DHCP mechanism operates on a per = emergency > > request basis, or whether the information is retained in the > > same way as > > more normal configuration, but I guess any putting into words > > should include > > that distinction. > > > > I would also guess that if there were multiple mechanisms, > > then they would > > have to be prioritised by some means in order to avoid information > > conflicts. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: 24 January 2006 12:33 > > > To: 'Drage, Keith (Keith)'; ecrit@ietf.org > > > Subject: RE: [Ecrit] Issue 30: Summary > > > > > > > > > I suppose this is more terminology confusion, but would you > > > call learning > > > your, let's say, DNS gateway from DHCP "configuration"? If > > > so, then I think > > > you have the requirements pretty close. If learning > > > information from the > > > local environment is not "configuration" then we would have > > a problem. > > > > > > Unlike Barbara, I think it is the VISITED network's emergency > > > dialstring > > > that must be recognized above all else. Also recognizing the home > > > dialstring would be a good idea. This would mirror current > > > practice, and in > > > the absence of some good evidence that it's the wrong way to > > > go, I think we > > > ought not to change it. If you bring your phone from the UK > > > to the US, then > > > you dial 9-1-1 to get emergency help, and not 9-9-9. > > > > > > Brian > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of > > > Drage, Keith (Keith) > > > Sent: Tuesday, January 24, 2006 7:21 AM > > > To: ecrit@ietf.org > > > Subject: RE: [Ecrit] Issue 30: Summary > > > > > > To try and make a suggestion based on the discussion so far. > > > I think the key > > > to this is the ability to configure the SIP phone. I would suggest > > > requirements something like the following: > > > > > > - All SIP phones MUST support recognition of emergency > > > numbers keyed > > > by the user, and if recognised, make the call as an emergency > > > call using the > > > universal emergency identifier (i.e. the sos SIP URI or > > > whatever it is). > > > > > > - All SIP phones that are configurable, either locally or > > > remotely, > > > MUST support configuration of recognisable emergency numbers by = that > > > mechanism. > > > > > > - SIP phones that are not configurable MUST recognise 112 and 911. > > > > > > I dont think the last will ever need to be implemented in > > > practice as I > > > suspect all SIP phones needs to support some form of > > > configuration. As such > > > I think that if someone wants to provide such a restricted > > > phone, it will > > > only be able to dial full E.164 numbers anyway (i.e. > > > international format), > > > and such numbers do not conflict with 112 and 911. This is > > > why such numbers > > > are defined as stored on the GSM phone, rather than on the = UICC/SIM. > > > > > > We do need to add the optional emergency category > > > requirements into the > > > above, but this in my view deals with the generally > > > recognisable numbers > > > issue. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > > > Clive D.W. Feather > > > > Sent: 24 January 2006 10:15 > > > > To: Raymond Forbes > > > > Cc: ecrit@ietf.org > > > > Subject: Re: [Ecrit] Issue 30: Summary > > > > > > > > > > > > Raymond Forbes said: > > > > > I am not aware that the IETF is interested in UK PSTN > > > > Routeing (999, 112 > > > > > or otherwise) > > > > > > > > It isn't. However, it is interested in PSTN numbering where > > > > that interacts > > > > with ecrit, enum, and so on. > > > > > > > > > 911 is not supported in the UK, > > > > > > > > Correct. > > > > > > > > > 911345 may be a local number, national > > > > > dialling is not required. > > > > > > > > As I said, there are about 30 locations where this is the case. > > > > > > > > > If you dial 911 in the UK it will respond with > > > > > n/u tone as the 6 or 7 digit local number must be dialling > > > > in one sequence > > > > > and mapped by the local exchange. > > > > > > > > Not so. While there is a timeout, my local exchange (I've > > > > just tested it) > > > > will accept a more than 10 second gap between digits. > > > > > > > > It so happens that, if I dial 911 here, I get an announcement > > > > immediately > > > > after the second 1. I get the same announcement if I dial > > > 912 or 753, > > > > because none are valid prefixes. If, however, I'm in one of > > > > those 30 areas > > > > I would expect to get silence after dialling 911 until the > > > > timeout expires. > > > > > > > > -- > > > > Clive D.W. Feather | Work: | Tel: > > > > +44 20 8495 6138 > > > > Internet Expert | Home: | Fax: > > > > +44 870 051 9937 > > > > Demon Internet | WWW: http://www.davros.org | Mobile: > > > > +44 7973 377646 > > > > Thus plc | | > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 04:40:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F23ce-0006HX-1C; Thu, 26 Jan 2006 04:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F23cb-0006ES-SU for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 04:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27207 for ; Thu, 26 Jan 2006 04:39:21 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F23mV-0004ZW-Jc for ecrit@ietf.org; Thu, 26 Jan 2006 04:51:10 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0Q9elmu013202Thu, 26 Jan 2006 09:40:47 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F23cV-00095H-00; Thu, 26 Jan 2006 09:40:47 +0000 Date: Thu, 26 Jan 2006 09:40:47 +0000 From: "Clive D.W. Feather" To: Stastny Richard Subject: Re: [Ecrit] Issue 30: Summary Message-ID: <20060126094047.GE29036@finch-staff-1.thus.net> References: <32755D354E6B65498C3BD9FD496C7D461B2379@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2379@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard said: > One way out of this problem would be to establish a (currently > not existing) global DIALING plan for VoIP devices. > > This would be very simple, all E.164 numbers need to be dialled > in the international format using the "+", such as +1-234-567-8900 I don't believe this meets commercial reality. There is a piece of the VoIP market - possibly a large one - which is competing head-to-head with the fixed line market. These phones need to be able to dial short-form numbers in the same way as that market (this may also be a regulatory requirement in the UK). At the same time, these accounts may be nomadic. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 05:14:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2492-00012g-Mk; Thu, 26 Jan 2006 05:14:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2490-00012W-Ow for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 05:14:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00430 for ; Thu, 26 Jan 2006 05:12:50 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F24Iv-0005wf-RP for ecrit@ietf.org; Thu, 26 Jan 2006 05:24:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Issue 30: Summary Date: Thu, 26 Jan 2006 11:18:04 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B237E@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYiXShhRgHLc/AtQkO7gJBzNVKnNQABCglw From: "Stastny Richard" To: "Clive D.W. Feather" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In future there will be only one market: Personal devices accessing the Internet (or NGN or whatever) via BB access. The BB access may be fixed or wireless, whatever you choose or have available at your location The devices will be multi-mode: quad-band, WiFi (and WiMAX) Richard PS: the convergence is at the user's device. > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Thursday, January 26, 2006 10:41 AM > To: Stastny Richard > Cc: Drage, Keith (Keith); br@brianrosen.net; ecrit@ietf.org > Subject: Re: [Ecrit] Issue 30: Summary >=20 > Stastny Richard said: > > One way out of this problem would be to establish a (currently > > not existing) global DIALING plan for VoIP devices. > > > > This would be very simple, all E.164 numbers need to be dialled > > in the international format using the "+", such as +1-234-567-8900 >=20 > I don't believe this meets commercial reality. >=20 > There is a piece of the VoIP market - possibly a large one - which is > competing head-to-head with the fixed line market. These phones need to be > able to dial short-form numbers in the same way as that market (this may > also be a regulatory requirement in the UK). At the same time, these > accounts may be nomadic. >=20 > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > Internet Expert | Home: | Fax: +44 870 051 > 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 08:53:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27ZE-0003FZ-PQ; Thu, 26 Jan 2006 08:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27ZC-0003EN-SE for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 08:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16611 for ; Thu, 26 Jan 2006 08:52:06 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F27j9-0004sL-Cr for ecrit@ietf.org; Thu, 26 Jan 2006 09:03:56 -0500 Received: (qmail invoked by alias); 26 Jan 2006 13:53:21 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp027) with SMTP; 26 Jan 2006 14:53:21 +0100 X-Authenticated: #29516787 Message-ID: <43D8D450.3070002@gmx.net> Date: Thu, 26 Jan 2006 14:53:20 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Conference Bridge Details for ECRIT Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, Lucent has kindly provided a conference bridge for us: Bridge number: 877-237-7156 Code: 257752 For international callers, dial 011-1-908-516-0200 then use the same code. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 09:06:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27lh-0007q9-Be; Thu, 26 Jan 2006 09:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27lf-0007oV-W9 for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 09:06:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18084 for ; Thu, 26 Jan 2006 09:04:59 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F27va-0005TK-Fz for ecrit@ietf.org; Thu, 26 Jan 2006 09:16:49 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k0QE6FOC011278Thu, 26 Jan 2006 14:06:15 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F27lP-000GCE-00; Thu, 26 Jan 2006 14:06:15 +0000 Date: Thu, 26 Jan 2006 14:06:15 +0000 From: "Clive D.W. Feather" To: Hannes Tschofenig Subject: Re: [Ecrit] Conference Bridge Details for ECRIT Interim Meeting Message-ID: <20060126140615.GC57109@finch-staff-1.thus.net> References: <43D8D450.3070002@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D8D450.3070002@gmx.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig said: > Lucent has kindly provided a conference bridge for us: > > Bridge number: 877-237-7156 > Code: 257752 > > For international callers, dial 011-1-908-516-0200 then use the same code. Given the context of this list, that's an interesting error on your part :-) If I were to dial 0111908 I would expect an error; I need to dial 001908. You, of course, actually mean: Bridge number: +1 877 237 7156 or +1 908 516 0200 (NANP 8nn numbers can be called from many countries at the normal country- to-country rate). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 11:18:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F29pK-0007iW-Eg; Thu, 26 Jan 2006 11:18:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F29pG-0007hj-HQ for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 11:18:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01149 for ; Thu, 26 Jan 2006 11:16:49 -0500 (EST) Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29z9-0002fb-ML for ecrit@ietf.org; Thu, 26 Jan 2006 11:28:38 -0500 Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QGHsv20782; Thu, 26 Jan 2006 11:17:54 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zharhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 16:17:50 +0000 Received: from [127.0.0.1] ([47.130.16.247] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 11:17:48 -0500 Message-ID: <43D8F627.3050001@nortel.com> Date: Thu, 26 Jan 2006 11:17:43 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2006 16:17:48.0229 (UTC) FILETIME=[0C3A4F50:01C62294] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The note is certainly expendable, but I think the point is valid. Surely the information: "Ottawa, Ontario" has no privacy implications, but the information: "Tom Taylor, Ottawa, Ontario" does. This is the distinction I was trying to make in the note. Tschofenig, Hannes wrote: > hi raymond, > > thanks for reading our documents. > please find some feedback inline: > > ________________________________ > > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im > Auftrag von Raymond Forbes > Gesendet: Freitag, 20. Januar 2006 14:17 > An: ecrit@ietf.org > Betreff: [Ecrit] Fw: [EMTEL] I-D > ACTION:draft-ietf-ecrit-requirements-02.txt > ...> > > Firstly, Security Threats and Requirements for Emergency Calling > draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note > is not be true according to European Directive and Europe-wide laws. The > EU data protection directive states that Location is Private data to the > user that must be secured under the user's right to reveal, withstanding > the three very clear legal exceptions: which are 1. National Security; > 2. Criminal Activity and 3. making an Emergency call or Request to the > Emergency services. These Authority must legally respect the rights of > the User not to reveal the location to third parties and commercial > organisations. I suggest that you delete the note. EU Directives and > European-wide law covers at least 30 countries. Under EU Directives the > User's Location is Private data that cannot be revealed except on the > commercial request of the User for a Location based service or under one > of the three provisions. The user's location falling inadvertently into > the wrong hands is a security threat that you do not mention. This means > that User's location cannot be held on a Publically accessible directory > database. > > > > [hannes] here is the paragraph you are referring to: > ( > http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- > 01.txt) > > " > 3. The timeliness, integrity and privacy of call signalling must be > ensured as it passes between the emergency caller's device and > the PSAP. > > NOTE - a confidentiality requirement applies to the > association of a location with an emergency (e.g., within call > signalling) or with an individual. The location data per se > is not confidential. > " > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 26 13:08:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BY3-0007Ze-Qz; Thu, 26 Jan 2006 13:08:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BY1-0007X7-CO for ecrit@megatron.ietf.org; Thu, 26 Jan 2006 13:08:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11160 for ; Thu, 26 Jan 2006 13:07:10 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Bi0-0008JT-Cw for ecrit@ietf.org; Thu, 26 Jan 2006 13:19:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2006 10:08:30 -0800 X-IronPort-AV: i="4.01,221,1136188800"; d="scan'208"; a="251622301:sNHT247086416" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0QI8QKZ018898; Thu, 26 Jan 2006 10:08:30 -0800 (PST) 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.211); Thu, 26 Jan 2006 10:08:26 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 10:08:26 -0800 Message-Id: <4.3.2.7.2.20060126115755.01995700@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jan 2006 12:08:25 -0600 To: "Tschofenig, Hannes" , From: "James M. Polk" Subject: Re: AW: [Ecrit] Reading List for the Interim Meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 26 Jan 2006 18:08:26.0368 (UTC) FILETIME=[80DDF000:01C622A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:18 AM 1/26/2006 +0100, Tschofenig, Hannes wrote: >hi james, > >thanks for this information. why would you like to split the examples into= =20 >a separate document? Hannes - to remove nearly all the message decodes from the doc. I have now= =20 only full message decodes (including full PIDF-LO message bodies showing=20 either coordinate or civic locations) in every SIP Request message. I=20 think that may be a little too much. I was moving the fully decoded flows= =20 to a series of Appendices, but that still seems clumbersome. So the=20 thought now is to more those into a usage examples type document in SIPPING. >maybe you can briefly give us an overview what is needed to finish this=20 >document. well, right now I have the document arranged in this way I need to rearrange the doc from the UAC's, then the UAS's, and then the=20 Proxy Server's points of view, each with their own section. >ciao >hannes > > > > -----Urspr=FCngliche Nachricht----- > > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > Im Auftrag von James M. Polk > > Gesendet: Donnerstag, 26. Januar 2006 01:44 > > An: ecrit@ietf.org > > Betreff: Re: [Ecrit] Reading List for the Interim Meeting > > > > At 01:14 AM 1/26/2006 +0100, Tschofenig, Hannes wrote: > > >hi all, > > > > > >additionally, take a look at: > > >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-c > > onveyance-0 > > >1.txt > > > > I hope to have a new version of this ID out before the > > interim. A lot of > > what's said in -01 will be in -02, it'll just be said > > differently (more > > succinct, better arranged, etc). Plus I have a plan to take > > all the fully > > decoded message flow examples into a separate SIPPING ID. > > > > > > >ciao > > >hannes > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 28 12:04:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2tUw-0002eW-SI; Sat, 28 Jan 2006 12:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2tUs-0002Zs-L9 for ecrit@megatron.ietf.org; Sat, 28 Jan 2006 12:04:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29618 for ; Sat, 28 Jan 2006 12:02:40 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2tf7-0007ur-0C for ecrit@ietf.org; Sat, 28 Jan 2006 12:14:59 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0SH3tjd028282 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 28 Jan 2006 12:03:56 -0500 (EST) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2379@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B2379@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <757B7D9A-7157-4479-9476-9ECE3A209C24@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Summary Date: Sat, 28 Jan 2006 12:03:54 -0500 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think we can simplify the problem slightly if we look at some plausible deployment scenarios for traveling users. [Travel] User takes mobile device or laptop software to foreign country; keeps home service provider. Here, there is no concern about PBX dial plans and the like. Since all mobile devices and soft phones use en-bloc ("press send") rather than overlap dialing, there are no issues with prefix overlap. Thus, the only concern are if a visited emergency number is also serving some important, but different, function back home. The number of such collisions of practical interest seem to be small. The reason for having a visited emergency number is user expectation: the "dial number seen on fire truck". [ex-pat] The ex-pat user takes a terminal adapter or Ethernet phone to a foreign country, but gets service from a service provider back home, e.g., so that he can maintain a local number in his home country. (I use a German SIP provider, for example.) The reason for having a visited emergency number is the babysitter problem: the babysitter won't know that the ex-pat is getting phone service from a different country and will dial the emergency number she is familiar with. Relying on users to program their phone manually is unlikely to be done consistently. Again, PBX extension collisions seem unlikely in this case as most phones would treat the foreign provider as its own "line", with its own dial plan. Overlap dialing is more of a concern here, due to the use of terminal adapters rather than IP phones. I suspect most users would rather have the babysitter get the fire department than worrying about messing up directory assistance (to take the Finnish 118 example) in a far-away place. Thus, a simple rule that makes the visited emergency number match first would seem to satisfy almost all practical considerations. This requires no cooperation from the service provider. Henning (more comments inline) On Jan 26, 2006, at 4:34 AM, Stastny Richard wrote: > 1. the device needs to know the location > This is not quite true. Brian has suggested DHCP, since it is likely local. In addition, we assume that the device, in many cases, will need to know its location for call routing in any event. > 2. this will be very confusing for the users, especially > in countries where you have a local dialing plan. Given the cases above, I don't see this as a big issue in practice. Most people will never see this except on their mobile phone. Almost all service numbers on mobile phones are #something, so I think the number of non-emergency 3-digit dial strings used on mobile phones is minuscule. I can't remember ever dialing such a number on my mobile phone. > > So by default home emergency numbers and 112 will work > 911 seems to have problems > > Even if you load the emergency numbers in the visited network > from somewhere into the device, > the question remains, which numbers take preference if a clash > occurs (and we have seen that there is a number of clashes) > > One way out of this problem would be to establish a (currently > not existing) global DIALING plan for VoIP devices. > > This would be very simple, all E.164 numbers need to be dialled > in the international format using the "+", such as +1-234-567-8900 > > This seems to be more nasty as it is, because users of mobile > phones in non-US countries, say in Europe, are already used to > store their numbers in the contact list in this format anyway > (to be able to use their contact list anywhere) and most calls > are made via the contact list, last calls or missed calls list > ect anyway. > > This would open the whole number space for non-E164 numbers > (service numbers) and within this number space the problem > should be solvable, first defining 112 and 911 and then > Other service numbers (eg escape codes for national or provider > specific service codes) > > It is up to an international standards body (say ITU-T) to > define this number space. This cannot be solved in ECRIT, although > ECRIT may deliver input. > > Regards > Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 28 12:22:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2tm5-0004NC-1D; Sat, 28 Jan 2006 12:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2tm3-0004GY-7y for ecrit@megatron.ietf.org; Sat, 28 Jan 2006 12:22:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01038 for ; Sat, 28 Jan 2006 12:20:22 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2twF-000064-KE for ecrit@ietf.org; Sat, 28 Jan 2006 12:32:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Issue 30: Summary Date: Sat, 28 Jan 2006 18:25:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C47D5@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYkLW3zs0z41saOSwqBtbF8Qb2RvQAASXYU From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >Thus, a simple rule that makes the visited emergency number match=20 >first would seem to satisfy almost all practical considerations. This=20 >requires no cooperation from the service provider. Ok, if this is acceptable it could be a way out of this endless = discussion. I also agree with your most likely scenarios To summarize: 1. By default, the device is set to use the home dialplan and home emergency numbers, either directly or via the home provider. 2. If not at home, the device get its location and also the visited emergency numbers via some means 3. The visited emergency numbers take precendence over the home dialling plan, if a clash occurs. (Note: your home provider may provide you with an escape code to override this, but then you definitely know what you are doing - e.g. to reach 911xxx local numbers in UK if you happen to be in the US.) Note: this may cause some emergency calls done wrong, but this is preferrable to missroute some real emergency calls regards Richard ________________________________ Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Gesendet: Sa 28.01.2006 18:03 An: Stastny Richard Cc: ecrit@ietf.org Betreff: Re: [Ecrit] Issue 30: Summary I think we can simplify the problem slightly if we look at some=20 plausible deployment scenarios for traveling users. [Travel] User takes mobile device or laptop software to foreign=20 country; keeps home service provider. Here, there is no concern about=20 PBX dial plans and the like. Since all mobile devices and soft phones=20 use en-bloc ("press send") rather than overlap dialing, there are no=20 issues with prefix overlap. Thus, the only concern are if a visited=20 emergency number is also serving some important, but different,=20 function back home. The number of such collisions of practical=20 interest seem to be small. The reason for having a visited emergency number is user expectation:=20 the "dial number seen on fire truck". [ex-pat] The ex-pat user takes a terminal adapter or Ethernet phone=20 to a foreign country, but gets service from a service provider back=20 home, e.g., so that he can maintain a local number in his home=20 country. (I use a German SIP provider, for example.) The reason for having a visited emergency number is the babysitter=20 problem: the babysitter won't know that the ex-pat is getting phone=20 service from a different country and will dial the emergency number=20 she is familiar with. Relying on users to program their phone manually is unlikely to be=20 done consistently. Again, PBX extension collisions seem unlikely in this case as most=20 phones would treat the foreign provider as its own "line", with its=20 own dial plan. Overlap dialing is more of a concern here, due to the=20 use of terminal adapters rather than IP phones. I suspect most users=20 would rather have the babysitter get the fire department than=20 worrying about messing up directory assistance (to take the Finnish=20 118 example) in a far-away place. Thus, a simple rule that makes the visited emergency number match=20 first would seem to satisfy almost all practical considerations. This=20 requires no cooperation from the service provider. Henning (more comments inline) On Jan 26, 2006, at 4:34 AM, Stastny Richard wrote: > 1. the device needs to know the location > This is not quite true. Brian has suggested DHCP, since it is likely=20 local. In addition, we assume that the device, in many cases, will=20 need to know its location for call routing in any event. > 2. this will be very confusing for the users, especially > in countries where you have a local dialing plan. Given the cases above, I don't see this as a big issue in practice.=20 Most people will never see this except on their mobile phone. Almost=20 all service numbers on mobile phones are #something, so I think the=20 number of non-emergency 3-digit dial strings used on mobile phones is=20 minuscule. I can't remember ever dialing such a number on my mobile=20 phone. > > So by default home emergency numbers and 112 will work > 911 seems to have problems > > Even if you load the emergency numbers in the visited network > from somewhere into the device, > the question remains, which numbers take preference if a clash > occurs (and we have seen that there is a number of clashes) > > One way out of this problem would be to establish a (currently > not existing) global DIALING plan for VoIP devices. > > This would be very simple, all E.164 numbers need to be dialled > in the international format using the "+", such as +1-234-567-8900 > > This seems to be more nasty as it is, because users of mobile > phones in non-US countries, say in Europe, are already used to > store their numbers in the contact list in this format anyway > (to be able to use their contact list anywhere) and most calls > are made via the contact list, last calls or missed calls list > ect anyway. > > This would open the whole number space for non-E164 numbers > (service numbers) and within this number space the problem > should be solvable, first defining 112 and 911 and then > Other service numbers (eg escape codes for national or provider > specific service codes) > > It is up to an international standards body (say ITU-T) to > define this number space. This cannot be solved in ECRIT, although > ECRIT may deliver input. > > Regards > Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 28 13:10:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2uX5-0007Xg-N8; Sat, 28 Jan 2006 13:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2uX4-0007VE-1M for ecrit@megatron.ietf.org; Sat, 28 Jan 2006 13:10:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03222 for ; Sat, 28 Jan 2006 13:08:59 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2uhK-0001Eu-J5 for ecrit@ietf.org; Sat, 28 Jan 2006 13:21:19 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0SIASHG021522 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 28 Jan 2006 13:10:29 -0500 (EST) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C47D5@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C47D5@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03E595D4-CCC4-471A-9FB0-6C07D764B6C5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Issue 30: Summary Date: Sat, 28 Jan 2006 13:10:27 -0500 To: "Stastny Richard" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with your summary. There is no perfect solution, but I'm also hoping that the number of devices that only support overlap dialing will be decreasing over time. Even my new, but cheap Panasonic PSTN cordless phone now does en-bloc dialing, so that you can edit the number. On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: > 1. By default, the device is set to use the home dialplan > and home emergency numbers, either directly or via > the home provider. > > 2. If not at home, the device get its location and also > the visited emergency numbers via some means > > 3. The visited emergency numbers take precendence > over the home dialling plan, if a clash occurs. > (Note: your home provider may provide you with an > escape code to override this, but then you definitely know > what you are doing - e.g. to reach 911xxx local numbers in UK > if you happen to be in the US.) > > Note: this may cause some emergency calls done wrong, > but this is preferrable to missroute some real emergency calls _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 31 10:44:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xgT-00028D-Pn; Tue, 31 Jan 2006 10:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xgS-00026r-An for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 10:44:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27947 for ; Tue, 31 Jan 2006 10:43:02 -0500 (EST) Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xrM-00080U-E5 for ecrit@ietf.org; Tue, 31 Jan 2006 10:56:01 -0500 Received: from ([90.152.52.44]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.107486839; Tue, 31 Jan 2006 10:43:55 -0500 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 31 Jan 2006 09:43:55 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 09:43:55 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD30@bre2k61p-55> Thread-Topic: Re: [Ecrit] Issue 30: Summary thread-index: AcYmfSOlgpUAdiSMRRC/MEOER29aYg== From: "Stark, Barbara" To: X-OriginalArrivalTime: 31 Jan 2006 15:43:55.0875 (UTC) FILETIME=[24EA7330:01C6267D] X-Spam-Score: 0.7 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0373213149==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0373213149== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6267D.24868E03" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6267D.24868E03 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This seems generally reasonable to me, also. However, there is an implicit expectation in the description below that = I'm not quite comfortable with, in the "precedence" statement. That is, = whether or not end of dialing string is automatically recognized for = visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must = always be pressed to indicate "end of dialing". For these, there would = be no clash between a US "911" and UK "911xxx" dial string. If the user = enters "911xxx" + "Send", then this must never be interpreted as "911". = Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of = mechanisms to recognize "end of dialing".=20 1. Some strings are automatically recognized; for example, when a user = dials any "N11" string and has an ATA configured for US dialing plans, = the ATA recognizes this string and automatically sends the SIP Invite = without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many = users are unaware of this fact. 3. If the user does not press another digit in 4 or 5 seconds (differs = by device), this is interpreted as end of dialing, and the SIP Invite is = sent. What this means, is that, if a user enters a string that is not = automatically recognized as being "complete", and the user doesn't press = "#", there will be a 4 or 5 second delay between the time when the last = digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer = that there be no requirement to automatically recognize "end of dialing" = for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an = automatically escaped string that is shorter than the visited emergency = number (e.g., an ATA might automatically recognize "00" as a complete = string, and the visited emergency number is "000"), then the ATA logic = needs to stop recognizing "00" as a complete string. I'm fine with this. = The user can then dial "00" (+ timeout) or "00#", and also "000" (+ = timeout) or "000#". If done this way, the only clashes would be for exact matches. Barbara =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: 1. By default, the device is set to use the home dialplan and home emergency numbers, either directly or via the home provider. 2. If not at home, the device get its location and also the visited emergency numbers via some means 3. The visited emergency numbers take precendence over the home dialling plan, if a clash occurs. (Note: your home provider may provide you with an escape code to override this, but then you definitely know what you are doing - e.g. to reach 911xxx local numbers in UK if you happen to be in the US.) Note: this may cause some emergency calls done wrong, but this is preferrable to missroute some real emergency calls ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 117 ------_=_NextPart_001_01C6267D.24868E03 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary

This seems generally reasonable = to me, also.
However, there is an implicit = expectation in the description below that I'm not quite comfortable = with, in the "precedence" statement. That is, whether or not = end of dialing string is automatically recognized for visited emergency = numbers.

For devices that use a = "Send" button, this isn't a problem. "Send" must = always be pressed to indicate "end of dialing". For these, = there would be no clash between a US "911" and UK = "911xxx" dial string. If the user enters "911xxx" = + "Send", then this must never be interpreted as = "911". Similarly, "911" + "Send" is = equally unambiguous (in this example).

SIP devices without a = "Send" button generally employ a variety of mechanisms to = recognize "end of dialing".
 1. Some strings are = automatically recognized; for example, when a user dials any = "N11" string and has an ATA configured for US dialing plans, = the ATA recognizes this string and automatically sends the SIP Invite = without waiting any further.

 2. The user can usually = press "#" to indicate end of dialing. Many users are unaware = of this fact.
 3. If the user does not = press another digit in 4 or 5 seconds (differs by device), this is = interpreted as end of dialing, and the SIP Invite is sent.

What this means, is that, if a = user enters a string that is not automatically recognized as being = "complete", and the user doesn't press "#", there = will be a 4 or 5 second delay between the time when the last digit is = pressed and SIP signaling begins.

While I realize that this delay = is generally undesirable, I would prefer that there be no requirement to = automatically recognize "end of dialing" for visited emergency = strings.

The flip side of this is that if = the ATA's current dialing plan has an automatically escaped string that = is shorter than the visited emergency number (e.g., an ATA might = automatically recognize "00" as a complete string, and the = visited emergency number is "000"), then the ATA logic needs = to stop recognizing "00" as a complete string. I'm fine with = this. The user can then dial "00" (+ timeout) or = "00#", and also "000" (+ timeout) or = "000#".

If done this way, the only = clashes would be for exact matches.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Jan 28, 2006, at 12:25 PM, = Stastny Richard wrote:

    1. By default, the device is set = to use the home dialplan
    and home emergency numbers, = either directly or via
    the home provider.
    2. If not at home, the device = get its location and also
    the visited emergency numbers = via some means
    3. The visited emergency numbers = take precendence
    over the home dialling plan, if = a clash occurs.
    (Note: your home provider may = provide you with an
    escape code to override this, = but then you definitely know
    what you are doing - e.g. to = reach 911xxx local numbers in UK
    if you happen to be in the = US.)
    Note: this may cause some = emergency calls done wrong,
    but this is preferrable to = missroute some real emergency calls

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. 117

 ------_=_NextPart_001_01C6267D.24868E03-- --===============0373213149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0373213149==-- From ecrit-bounces@ietf.org Tue Jan 31 13:00:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3znU-0005Qx-C8; Tue, 31 Jan 2006 13:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3znR-0005Nv-0q for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 13:00:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13407 for ; Tue, 31 Jan 2006 12:58:22 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zyJ-0005yg-Uf for ecrit@ietf.org; Tue, 31 Jan 2006 13:11:20 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F3znB-0005ug-LO; Tue, 31 Jan 2006 11:59:50 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 12:55:20 -0500 Message-ID: <040401c6268f$82bb9c70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD30@bre2k61p-55> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9Sg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0859401706==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0859401706== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0405_01C62665.99E8A1B0" This is a multi-part message in MIME format. ------=_NextPart_000_0405_01C62665.99E8A1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary This seems generally reasonable to me, also. However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing". 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact. 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches. Barbara ======================================== On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: 1. By default, the device is set to use the home dialplan and home emergency numbers, either directly or via the home provider. 2. If not at home, the device get its location and also the visited emergency numbers via some means 3. The visited emergency numbers take precendence over the home dialling plan, if a clash occurs. (Note: your home provider may provide you with an escape code to override this, but then you definitely know what you are doing - e.g. to reach 911xxx local numbers in UK if you happen to be in the US.) Note: this may cause some emergency calls done wrong, but this is preferrable to missroute some real emergency calls ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------=_NextPart_000_0405_01C62665.99E8A1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary

If you would like, I’ll raise = this with the PSAP and NENA folks.  I don’t think they will agree = with you.

The visited emergency number has to = work immediately, which means it has to be recognized by a dial plan, and not = depend on timeouts or # key presses.

I think they would say that the = home emergency number could have the delay or #.

 

You are proposing to change current behavior; as it stands now, if you bring a phone into a country, = it’s the visited emergency number that works.  I do understand that if you = use an enterprise phone from a VPN or something equivalent, everything breaks = (you don’t have the local emergency number, you don’t have correct location, = and the call goes to the home psap).   I think we really are better = off with “both”, even if that causes some kinds of problems with home dial plans. =  It’s much easier to deal with Extension 999 doesn’t work as a 3 digit = number when I call from the UK as it does “please remember to hit # or = wait 4 seconds” to get help when you are in the middle of = London.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara
Sent: Tuesday, January = 31, 2006 10:44 AM
To: ecrit@ietf.org
Subject: Re: [Ecrit] = Issue 30: Summary

 

This seems generally reasonable to me, = also.
However, there is an implicit expectation in the description below that I'm not = quite comfortable with, in the "precedence" statement. That is, = whether or not end of dialing string is automatically recognized for visited = emergency numbers.

For devices that use a "Send" button, this = isn't a problem. "Send" must always be pressed to indicate "end = of dialing". For these, there would be no clash between a = US "911" and = UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as = "911". Similarly, "911" + "Send" is equally unambiguous (in = this example).

SIP devices without a "Send" button generally = employ a variety of mechanisms to recognize "end of dialing". =
 1. Some strings are automatically recognized; for example, when a user = dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without = waiting any further.

 2. The user can usually press "#" to = indicate end of dialing. Many users are unaware of this fact.
 3. If the user does not press another digit in 4 or 5 seconds (differs by = device), this is interpreted as end of dialing, and the SIP Invite is = sent.

What this means, is that, if a user enters a string that = is not automatically recognized as being "complete", and the user = doesn't press "#", there will be a 4 or 5 second delay between the = time when the last digit is pressed and SIP signaling = begins.

While I realize that this delay is generally undesirable, = I would prefer that there be no requirement to automatically recognize = "end of dialing" for visited emergency = strings.

The flip side of this is that if the ATA's current = dialing plan has an automatically escaped string that is shorter than the visited = emergency number (e.g., an ATA might automatically recognize "00" as a = complete string, and the visited emergency number is "000"), then the = ATA logic needs to stop recognizing "00" as a complete string. I'm = fine with this. The user can then dial "00" (+ timeout) or = "00#", and also "000" (+ timeout) or = "000#".

If done this way, the only clashes would be for exact = matches.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: =

1. By default, the = device is set to use the home dialplan
and home emergency numbers, either directly or via
the home provider.
2. If not at home, the device get its location and also
the visited emergency numbers via some means
3. The visited emergency numbers take precendence
over the home dialling plan, if a clash occurs.
(Note: your home provider may provide you with an
escape code to override this, but then you definitely know
what you are doing - e.g. to reach 911xxx local numbers in = UK
if you happen to be in the US.)
Note: this may cause some emergency calls done wrong,
but this is preferrable to missroute some real emergency calls =

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. 117

 ------=_NextPart_000_0405_01C62665.99E8A1B0-- --===============0859401706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0859401706==-- From ecrit-bounces@ietf.org Tue Jan 31 13:45:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40VU-0008SP-1S; Tue, 31 Jan 2006 13:45:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40VS-0008Ob-4v for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 13:45:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17575 for ; Tue, 31 Jan 2006 13:43:57 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F40gR-0007l9-T4 for ecrit@ietf.org; Tue, 31 Jan 2006 13:56:57 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 Jan 2006 13:45:23 -0500 X-IronPort-AV: i="4.01,240,1136178000"; d="scan'208,217"; a="81403435:sNHT64899600" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0VIig6r019633; Tue, 31 Jan 2006 13:45:20 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 13:45:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 13:45:10 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30108D448@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHBJkA= From: "Michael Hammer \(mhammer\)" To: , "Stark, Barbara" , X-OriginalArrivalTime: 31 Jan 2006 18:45:11.0597 (UTC) FILETIME=[7759EDD0:01C62696] X-Spam-Score: 0.8 (/) X-Scan-Signature: 4297a3b9ddbbc388d94c1425bc2288b8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0837431380==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0837431380== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62696.7721B300" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62696.7721B300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, =20 I thought Barbara stated the problem well and a solution for disambiguating the overlap in dial plans. Note that plans is plural. This is a question of conflicts in dial plans. =20 The core of this is that *** the endpoint doesn't know *** it is an "emergency number" until the process for separating out the overlaps is complete. The delay or # or immediate is *how it knows*. =20 Your reasoning is circular here. There is a Latin name for this, but hey, I didn't study Latin. =20 Mike =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, January 31, 2006 12:55 PM To: 'Stark, Barbara'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =09 =09 If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. =20 You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. =20 Brian =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary =20 This seems generally reasonable to me, also.=20 However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing".=20 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact.=20 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches.=20 Barbara=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote:=20 1. By default, the device is set to use the home dialplan=20 and home emergency numbers, either directly or via=20 the home provider.=20 2. If not at home, the device get its location and also=20 the visited emergency numbers via some means=20 3. The visited emergency numbers take precendence=20 over the home dialling plan, if a clash occurs.=20 (Note: your home provider may provide you with an=20 escape code to override this, but then you definitely know=20 what you are doing - e.g. to reach 911xxx local numbers in UK=20 if you happen to be in the US.)=20 Note: this may cause some emergency calls done wrong,=20 but this is preferrable to missroute some real emergency calls=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------_=_NextPart_001_01C62696.7721B300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = Issue 30: Summary
Brian,
 
I thought Barbara stated the problem well and a solution = for=20 disambiguating the overlap in dial plans.  Note that plans is = plural. =20 This is a question of conflicts in dial plans.
 
The core of this is that *** the endpoint doesn't know = *** it=20 is an "emergency number" until the process for separating out the = overlaps is=20 complete.  The delay or # or immediate is *how it=20 knows*.
 
Your=20 reasoning is circular here.  There is a Latin name for this, but = hey, I=20 didn't study Latin.
 
Mike
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian=20 Rosen
Sent: Tuesday, January 31, 2006 12:55 PM
To: = 'Stark,=20 Barbara'; ecrit@ietf.org
Subject: RE: [Ecrit] Issue 30:=20 Summary

If you = would like,=20 I’ll raise this with the PSAP and NENA folks.  I = don’t think they will=20 agree with you.

The visited = emergency=20 number has to work immediately, which means it has to be recognized by = a dial=20 plan, and not depend on timeouts or # key=20 presses.

I think = they would=20 say that the home emergency number could have the delay or=20 #.

 

You are = proposing to=20 change current behavior; as it stands now, if you bring a phone into a = country, it’s the visited emergency number that works.  I = do understand=20 that if you use an enterprise phone from a VPN or something = equivalent,=20 everything breaks (you don’t have the local emergency number, = you don’t have=20 correct location, and the call goes to the home psap).   I = think we=20 really are better off with “both”, even if that causes = some kinds of problems=20 with home dial plans.  It’s much easier to deal with = Extension 999=20 doesn’t work as a 3 digit number when I call from the UK as it = does “please=20 remember to hit # or wait 4 seconds” to get help when you are in = the middle of=20 London.

 

Brian

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, = Barbara
Sent: Tuesday, January 31, 2006 = 10:44=20 AM
To:=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] Issue 30: Summary

 

This seems = generally=20 reasonable to me, also.
However,=20 there is an implicit expectation in the description below that I'm not = quite=20 comfortable with, in the "precedence" statement. That is, whether or = not end=20 of dialing string is automatically recognized for visited emergency=20 numbers.

For devices that = use a=20 "Send" button, this isn't a problem. "Send" must always be pressed to = indicate=20 "end of dialing". For these, there would be no clash between a=20 US "911" and=20 UK "911xxx" dial string. = If the=20 user enters "911xxx" + "Send", then this must never be interpreted as = "911".=20 Similarly, "911" + "Send" is equally unambiguous (in this=20 example).

SIP devices = without a=20 "Send" button generally employ a variety of mechanisms to recognize = "end of=20 dialing".
 1. Some = strings are=20 automatically recognized; for example, when a user dials any "N11" = string and=20 has an ATA configured for US dialing plans, the ATA = recognizes this string and automatically sends the SIP Invite without = waiting=20 any further.

 2. The = user can=20 usually press "#" to indicate end of dialing. Many users are unaware = of this=20 fact.
 3. If the = user does=20 not press another digit in 4 or 5 seconds (differs by device), this is = interpreted as end of dialing, and the SIP Invite is=20 sent.

What this means, = is that,=20 if a user enters a string that is not automatically recognized as = being=20 "complete", and the user doesn't press "#", there will be a 4 or 5 = second=20 delay between the time when the last digit is pressed and SIP = signaling=20 begins.

While I realize = that this=20 delay is generally undesirable, I would prefer that there be no = requirement to=20 automatically recognize "end of dialing" for visited emergency=20 strings.

The flip side of = this is=20 that if the ATA's current dialing plan has an automatically escaped = string=20 that is shorter than the visited emergency number (e.g., an ATA might=20 automatically recognize "00" as a complete string, and the visited = emergency=20 number is "000"), then the ATA logic needs to stop recognizing "00" as = a=20 complete string. I'm fine with this. The user can then dial "00" (+ = timeout)=20 or "00#", and also "000" (+ timeout) or = "000#".

If done this = way, the only=20 clashes would be for exact matches.
Barbara=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
On Jan 28, 2006, = at 12:25=20 PM, Stastny Richard wrote:

1. By default, = the device=20 is set to use the home dialplan
and home=20 emergency numbers, either directly or via
the home=20 provider.
2. If not at = home, the=20 device get its location and also
the visited=20 emergency numbers via some means
3. The=20 visited emergency numbers take precendence
over the home = dialling=20 plan, if a clash occurs.
(Note: your=20 home provider may provide you with an
escape code to = override=20 this, but then you definitely know
what you are=20 doing - e.g. to reach 911xxx local numbers in UK
if you happen=20 to be in the US.) =
Note: this may = cause some=20 emergency calls done wrong,
but this is=20 preferrable to missroute some real emergency calls=20

*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and = may=20 contain confidential, proprietary, and/or privileged material. Any = review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 117

------_=_NextPart_001_01C62696.7721B300-- --===============0837431380== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0837431380==-- From ecrit-bounces@ietf.org Tue Jan 31 14:09:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40sT-0006iS-KA; Tue, 31 Jan 2006 14:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40sS-0006h9-6C for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 14:09:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20088 for ; Tue, 31 Jan 2006 14:07:36 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F413L-0000Kl-8p for ecrit@ietf.org; Tue, 31 Jan 2006 14:20:36 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F40sG-0000Ji-L3; Tue, 31 Jan 2006 13:09:09 -0600 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stark, Barbara'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 14:04:02 -0500 Message-ID: <041f01c62699$1b2acf40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30108D448@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHBJkAAAF5i8A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.7 (/) X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1997592955==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1997592955== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0420_01C6266F.3254C740" This is a multi-part message in MIME format. ------=_NextPart_000_0420_01C6266F.3254C740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You are trying to come at this by claiming that the engineering works a particular way, so users should adapt. I understand that the problem is that you are putting a visited emergency number into a home dial plan. That is, in general, hard. But I think the operative phrase is English: "get over it". The REQUIREMENT is, I think, that the visited emergency number works, always, without anything funny. That's an end user experience requirement. We have to figure out how to make the devices meet that requirement. So, if you had an overlap, it is the emergency number that "wins" (that is, is recognized as the end of dialing), with some escape mechanism needed for whatever it overlapped in the original dial plan. Brian _____ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Tuesday, January 31, 2006 1:45 PM To: br@brianrosen.net; Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary Brian, I thought Barbara stated the problem well and a solution for disambiguating the overlap in dial plans. Note that plans is plural. This is a question of conflicts in dial plans. The core of this is that *** the endpoint doesn't know *** it is an "emergency number" until the process for separating out the overlaps is complete. The delay or # or immediate is *how it knows*. Your reasoning is circular here. There is a Latin name for this, but hey, I didn't study Latin. Mike _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, January 31, 2006 12:55 PM To: 'Stark, Barbara'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary This seems generally reasonable to me, also. However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing". 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact. 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches. Barbara ======================================== On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: 1. By default, the device is set to use the home dialplan and home emergency numbers, either directly or via the home provider. 2. If not at home, the device get its location and also the visited emergency numbers via some means 3. The visited emergency numbers take precendence over the home dialling plan, if a clash occurs. (Note: your home provider may provide you with an escape code to override this, but then you definitely know what you are doing - e.g. to reach 911xxx local numbers in UK if you happen to be in the US.) Note: this may cause some emergency calls done wrong, but this is preferrable to missroute some real emergency calls ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------=_NextPart_000_0420_01C6266F.3254C740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary

You are trying to come at this by = claiming that the engineering works a particular way, so users should = adapt.  I understand that the problem is that you are putting a visited emergency = number into a home dial plan.  That is, in general, = hard.

 

But I think the operative phrase is = English: “get over it”. The REQUIREMENT is, I think, that the visited emergency number works, always, without anything funny.  = That’s an end user experience requirement.  We have to figure out how to make = the devices meet that requirement.

 

So, if you had an overlap, it is = the emergency number that “wins” (that is, is recognized as the = end of dialing), with some escape mechanism needed for whatever it overlapped = in the original dial plan.

 

Brian

 

From: = Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Tuesday, January = 31, 2006 1:45 PM
To: br@brianrosen.net; = Stark, Barbara; ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 

Brian,

 

I thought Barbara stated the = problem well and a solution for disambiguating the overlap in dial plans.  = Note that plans is plural.  This is a question of conflicts in dial = plans.

 

The core of this is that *** the endpoint doesn't know *** it is an "emergency number" = until the process for separating out the overlaps is complete.  The = delay or # or immediate is *how it knows*.

 

Your reasoning is circular = here.  There is a Latin name for this, but hey, I didn't study = Latin.

 

Mike

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, January = 31, 2006 12:55 PM
To: 'Stark, Barbara'; ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

If you would like, I’ll raise = this with the PSAP and NENA folks.  I don’t think they will agree = with you.

The visited emergency number has to = work immediately, which means it has to be recognized by a dial plan, and not = depend on timeouts or # key presses.

I think they would say that the = home emergency number could have the delay or #.

 

You are proposing to change current behavior; as it stands now, if you bring a phone into a country, = it’s the visited emergency number that works.  I do understand that if you = use an enterprise phone from a VPN or something equivalent, everything breaks = (you don’t have the local emergency number, you don’t have = correct location, and the call goes to the home psap).   I think we = really are better off with “both”, even if that causes some kinds = of problems with home dial plans.  It’s much easier to deal with Extension 999 doesn’t work as a 3 digit number when I call from = the UK as it does “please remember to hit # or wait 4 seconds” to get = help when you are in the middle of London.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara
Sent: Tuesday, January = 31, 2006 10:44 AM
To: ecrit@ietf.org
Subject: Re: [Ecrit] = Issue 30: Summary

 

This seems generally reasonable to me, = also.
However, there is an implicit expectation in the description below that I'm not = quite comfortable with, in the "precedence" statement. That is, = whether or not end of dialing string is automatically recognized for visited = emergency numbers.

For devices that use a "Send" button, this = isn't a problem. "Send" must always be pressed to indicate "end = of dialing". For these, there would be no clash between a = US "911" and UK "911xxx" dial = string. If the user enters "911xxx" + "Send", then this must = never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this = example).

SIP devices without a "Send" button generally = employ a variety of mechanisms to recognize "end of dialing". =
 1. Some strings are automatically recognized; for example, when a user = dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without = waiting any further.

 2. The user can usually press "#" to = indicate end of dialing. Many users are unaware of this fact.
 3. If the user does not press another digit in 4 or 5 seconds (differs by = device), this is interpreted as end of dialing, and the SIP Invite is = sent.

What this means, is that, if a user enters a string that = is not automatically recognized as being "complete", and the user = doesn't press "#", there will be a 4 or 5 second delay between the = time when the last digit is pressed and SIP signaling = begins.

While I realize that this delay is generally undesirable, = I would prefer that there be no requirement to automatically recognize = "end of dialing" for visited emergency = strings.

The flip side of this is that if the ATA's current = dialing plan has an automatically escaped string that is shorter than the visited = emergency number (e.g., an ATA might automatically recognize "00" as a = complete string, and the visited emergency number is "000"), then the = ATA logic needs to stop recognizing "00" as a complete string. I'm = fine with this. The user can then dial "00" (+ timeout) or = "00#", and also "000" (+ timeout) or = "000#".

If done this way, the only clashes would be for exact = matches.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: =

1. By default, the = device is set to use the home dialplan
and home emergency numbers, either directly or via
the home provider.
2. If not at home, the device get its location and also
the visited emergency numbers via some means
3. The visited emergency numbers take precendence
over the home dialling plan, if a clash occurs.
(Note: your home provider may provide you with an
escape code to override this, but then you definitely know
what you are doing - e.g. to reach 911xxx local numbers in = UK
if you happen to be in the US.)
Note: this may cause some emergency calls done wrong,
but this is preferrable to missroute some real emergency calls =

*****

The information transmitted is intended = only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon = this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and = delete the material from all computers. 117

------=_NextPart_000_0420_01C6266F.3254C740-- --===============1997592955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1997592955==-- From ecrit-bounces@ietf.org Tue Jan 31 14:28:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41BQ-0005F2-GS; Tue, 31 Jan 2006 14:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F418b-0004PR-8h for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 14:26:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20468 for ; Tue, 31 Jan 2006 14:24:15 -0500 (EST) Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41JS-00015P-NE for ecrit@ietf.org; Tue, 31 Jan 2006 14:37:15 -0500 Received: from ([90.152.53.183]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.106867034; Tue, 31 Jan 2006 14:16:45 -0500 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 31 Jan 2006 13:17:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 13:17:07 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD32@bre2k61p-55> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHKMGA= From: "Stark, Barbara" To: , X-OriginalArrivalTime: 31 Jan 2006 19:17:07.0804 (UTC) FILETIME=[ED7FE9C0:01C6269A] X-Spam-Score: 1.2 (+) X-Scan-Signature: 3d2cbbe10c97d56c753ea98882cec394 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0547419081==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0547419081== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6269A.ED086D9D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6269A.ED086D9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you bring a GSM phone into a foreign country, it's the visited emergency number which will work, and the dialing plan will be local to where you're visiting. =20 If you bring a SIP ATA into a foreign country, today, it will have absolutely no knowledge of the visited emergency number. For a US-based SIP service (provided by a Voice Service Provider) it will know the home emergency number (although the actual recognition of the string as an emergency string will happen at the proxy server, and not at the device itself -- today's VSP-provided devices don't have special "emergency recognition" code in their software). However, an emergency call from a foreign country today will be misrouted, since it will be based on the static location information the subscriber provided. Since the US VSP will not provide service without an emegency location for which it is able to provide emergency service, and US VSPs are only able to provide emergency routing for a subset of US locations, the location will be extremely inaccurate. =20 For SIP ATAs, current behavior, as it stands, is that emergency dialing does not work when calling from a foreign country. The visited emergency string isn't recognized at all. Yes, I am proposing that this behavior be changed. But to try to force GSM-like behavior on a VSP service isn't reasonable. The expectations of the customer are completely different. The GSM customer expects their entire dialing plan to change and to become local to the visited location. The VSP customer (today) expects their dialing plan to be completely static, independent of where they visit. The purpose for using a German VSP service in the US is so that you can dial German phone numbers locally, and be reached locally from Germany. This is completely and totally different from the expectations of the GSM customer. =20 The GSM customer's dialing plan is always determined by the owner of the cell tower they're connected to. The VSP customer's dialing plan is always determined by the same proxy server, no matter where in the world they are. This means, by the way, that unless the device itself recognizes the visited emergency number, visited location numbers will never, ever work for these customers. If the visited emergency dial string reaches the proxy without having been changed to the SIP Emergency URI, then the proxy will NOT recognize it as an emergency dial string. The proxy will only recognize home strings, and the emergency URI. Because the VSP may not be able to control whether the user's device can recognize visited emergency numbers, it is likely that VSPs will instruct customers to always use the home emergency number, independent of where they are. Furthermore, the VSP would probably tell the customer that a visited emergency number may or may not work, depending on the capabilities of the device they are using, and depending on the capabilities of the LAN and ISP they are connected through; therefore, absolutely no assurances can be made as to whether or not the visited emergency number will work. Barbara=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, January 31, 2006 12:55 PM To: Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. =20 You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. =20 Brian =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary =20 This seems generally reasonable to me, also.=20 However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing".=20 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact.=20 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches.=20 Barbara=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote:=20 1. By default, the device is set to use the home dialplan=20 and home emergency numbers, either directly or via=20 the home provider.=20 2. If not at home, the device get its location and also=20 the visited emergency numbers via some means=20 3. The visited emergency numbers take precendence=20 over the home dialling plan, if a clash occurs.=20 (Note: your home provider may provide you with an=20 escape code to override this, but then you definitely know=20 what you are doing - e.g. to reach 911xxx local numbers in UK=20 if you happen to be in the US.)=20 Note: this may cause some emergency calls done wrong,=20 but this is preferrable to missroute some real emergency calls=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------_=_NextPart_001_01C6269A.ED086D9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary
If you=20 bring a GSM phone into a foreign country, it's the visited emergency = number=20 which will work, and the dialing plan will be local to where you're=20 visiting.
 
If you=20 bring a SIP ATA into a foreign country, today, it will have absolutely = no=20 knowledge of the visited emergency number. For a US-based SIP service = (provided=20 by a Voice Service Provider) it will know the home emergency number = (although=20 the actual recognition of the string as an emergency string will happen = at the=20 proxy server, and not at the device itself -- today's VSP-provided = devices don't=20 have special "emergency recognition" code in their software). However, = an=20 emergency call from a foreign country today will be misrouted, since it = will be=20 based on the static location information the subscriber provided. Since = the US=20 VSP will not provide service without an emegency location for which it = is able=20 to provide emergency service, and US VSPs are only able to provide = emergency=20 routing for a subset of US locations, the location will be extremely=20 inaccurate.
 
For=20 SIP ATAs, current behavior, as it stands, is that emergency dialing does = not=20 work when calling from a foreign country. The visited emergency string = isn't=20 recognized at all. Yes, I am proposing that this behavior be changed. = But to try=20 to force GSM-like behavior on a VSP service isn't reasonable. The = expectations=20 of the customer are completely different. The GSM customer expects their = entire=20 dialing plan to change and to become local to the visited location. The = VSP=20 customer (today) expects their dialing plan to be completely static, = independent=20 of where they visit. The purpose for using a  German VSP service in = the US=20 is so that you can dial German phone numbers locally, and be reached = locally=20 from Germany. This is completely and totally different from the = expectations of=20 the GSM customer.
 
The=20 GSM customer's dialing plan is always determined by the owner of the = cell tower=20 they're connected to. The VSP customer's dialing plan is always = determined by=20 the same proxy server, no matter where in the world they are. This = means, by the=20 way, that unless the device itself recognizes the visited emergency = number,=20 visited location numbers will never, ever work for these customers. If = the=20 visited emergency dial string reaches the proxy without having been = changed to=20 the SIP Emergency URI, then the proxy will NOT recognize it as an = emergency dial=20 string. The proxy will only recognize home strings, and the emergency = URI.=20 Because the VSP may not be able to control whether the user's device can = recognize visited emergency numbers, it is likely that VSPs will = instruct=20 customers to always use the home emergency number, independent of where = they=20 are. Furthermore, the VSP would probably tell the customer that a = visited=20 emergency number may or may not work, depending on the capabilities of = the=20 device they are using, and depending on the capabilities of the LAN and = ISP they=20 are connected through; therefore, absolutely no assurances can be made = as to=20 whether or not the visited emergency number will = work.
Barbara 
-----Original Message-----
From: Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: Tuesday, January 31, 2006 = 12:55=20 PM
To: Stark, Barbara; ecrit@ietf.org
Subject: RE: = [Ecrit]=20 Issue 30: Summary

If you = would like,=20 I’ll raise this with the PSAP and NENA folks.  I = don’t think they will=20 agree with you.

The visited = emergency=20 number has to work immediately, which means it has to be recognized by = a dial=20 plan, and not depend on timeouts or # key=20 presses.

I think = they would=20 say that the home emergency number could have the delay or=20 #.

 

You are = proposing to=20 change current behavior; as it stands now, if you bring a phone into a = country, it’s the visited emergency number that works.  I = do understand=20 that if you use an enterprise phone from a VPN or something = equivalent,=20 everything breaks (you don’t have the local emergency number, = you don’t have=20 correct location, and the call goes to the home psap).   I = think we=20 really are better off with “both”, even if that causes = some kinds of problems=20 with home dial plans.  It’s much easier to deal with = Extension 999=20 doesn’t work as a 3 digit number when I call from the UK as it = does “please=20 remember to hit # or wait 4 seconds” to get help when you are in = the middle of=20 London.

 

Brian

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, = Barbara
Sent: Tuesday, January 31, 2006 = 10:44=20 AM
To:=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] Issue 30: Summary

 

This seems = generally=20 reasonable to me, also.
However,=20 there is an implicit expectation in the description below that I'm not = quite=20 comfortable with, in the "precedence" statement. That is, whether or = not end=20 of dialing string is automatically recognized for visited emergency=20 numbers.

For devices that = use a=20 "Send" button, this isn't a problem. "Send" must always be pressed to = indicate=20 "end of dialing". For these, there would be no clash between a=20 US "911" and=20 UK "911xxx" dial string. = If the=20 user enters "911xxx" + "Send", then this must never be interpreted as = "911".=20 Similarly, "911" + "Send" is equally unambiguous (in this=20 example).

SIP devices = without a=20 "Send" button generally employ a variety of mechanisms to recognize = "end of=20 dialing".
 1. Some = strings are=20 automatically recognized; for example, when a user dials any "N11" = string and=20 has an ATA configured for US dialing plans, the ATA = recognizes this string and automatically sends the SIP Invite without = waiting=20 any further.

 2. The = user can=20 usually press "#" to indicate end of dialing. Many users are unaware = of this=20 fact.
 3. If the = user does=20 not press another digit in 4 or 5 seconds (differs by device), this is = interpreted as end of dialing, and the SIP Invite is=20 sent.

What this means, = is that,=20 if a user enters a string that is not automatically recognized as = being=20 "complete", and the user doesn't press "#", there will be a 4 or 5 = second=20 delay between the time when the last digit is pressed and SIP = signaling=20 begins.

While I realize = that this=20 delay is generally undesirable, I would prefer that there be no = requirement to=20 automatically recognize "end of dialing" for visited emergency=20 strings.

The flip side of = this is=20 that if the ATA's current dialing plan has an automatically escaped = string=20 that is shorter than the visited emergency number (e.g., an ATA might=20 automatically recognize "00" as a complete string, and the visited = emergency=20 number is "000"), then the ATA logic needs to stop recognizing "00" as = a=20 complete string. I'm fine with this. The user can then dial "00" (+ = timeout)=20 or "00#", and also "000" (+ timeout) or = "000#".

If done this = way, the only=20 clashes would be for exact matches.
Barbara=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
On Jan 28, 2006, = at 12:25=20 PM, Stastny Richard wrote:

1. By default, = the device=20 is set to use the home dialplan
and home=20 emergency numbers, either directly or via
the home=20 provider.
2. If not at = home, the=20 device get its location and also
the visited=20 emergency numbers via some means
3. The=20 visited emergency numbers take precendence
over the home = dialling=20 plan, if a clash occurs.
(Note: your=20 home provider may provide you with an
escape code to = override=20 this, but then you definitely know
what you are=20 doing - e.g. to reach 911xxx local numbers in UK
if you happen=20 to be in the US.) =
Note: this may = cause some=20 emergency calls done wrong,
but this is=20 preferrable to missroute some real emergency calls=20

*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and = may=20 contain confidential, proprietary, and/or privileged material. Any = review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 117

------_=_NextPart_001_01C6269A.ED086D9D-- --===============0547419081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0547419081==-- From ecrit-bounces@ietf.org Tue Jan 31 14:31:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Df-0005v2-Ny; Tue, 31 Jan 2006 14:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F418q-0004X2-6H for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 14:26:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20575 for ; Tue, 31 Jan 2006 14:24:29 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41F3-0000nG-NW for ecrit@ietf.org; Tue, 31 Jan 2006 14:32:42 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 Jan 2006 14:21:09 -0500 X-IronPort-AV: i="4.01,240,1136178000"; d="scan'208,217"; a="81406292:sNHT69686144" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0VJKv6P026081; Tue, 31 Jan 2006 14:21:06 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 14:21:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 14:21:01 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30108D47E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHBJkAAAF5i8AAA5a3g From: "Michael Hammer \(mhammer\)" To: , "Stark, Barbara" , X-OriginalArrivalTime: 31 Jan 2006 19:21:02.0236 (UTC) FILETIME=[793B65C0:01C6269B] X-Spam-Score: 0.8 (/) X-Scan-Signature: e535e8fdae689580ce57283401d548ee Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0752759821==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0752759821== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6269B.78F77EA8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6269B.78F77EA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The implication of what you are saying is that any number that begins with a digit string that happens to match any emergency number must be removed from any dial plan since the terminal will route it as an emergency before any additional digits can be dialed. =20 I wonder how someone whose phone number starts with 911 (as was pointed out earlier in examples) is just going to "get over it" as you say. You are saying they need to get a new phone number. Yet, I thought an earlier post also said that these dial plans were a national matter. In other words, it you don't like their dial plan, you will need to "get over it." =20 I must not be understanding what you are suggesting. Could you explain it to the level of detail that Barbara did? =20 Mike =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, January 31, 2006 2:04 PM To: Michael Hammer (mhammer); 'Stark, Barbara'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =09 =09 You are trying to come at this by claiming that the engineering works a particular way, so users should adapt. I understand that the problem is that you are putting a visited emergency number into a home dial plan. That is, in general, hard. =20 But I think the operative phrase is English: "get over it". The REQUIREMENT is, I think, that the visited emergency number works, always, without anything funny. That's an end user experience requirement. We have to figure out how to make the devices meet that requirement. =20 So, if you had an overlap, it is the emergency number that "wins" (that is, is recognized as the end of dialing), with some escape mechanism needed for whatever it overlapped in the original dial plan. =20 Brian =20 =09 ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, January 31, 2006 1:45 PM To: br@brianrosen.net; Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 Brian, =20 I thought Barbara stated the problem well and a solution for disambiguating the overlap in dial plans. Note that plans is plural. This is a question of conflicts in dial plans. =20 The core of this is that *** the endpoint doesn't know *** it is an "emergency number" until the process for separating out the overlaps is complete. The delay or # or immediate is *how it knows*. =20 Your reasoning is circular here. There is a Latin name for this, but hey, I didn't study Latin. =20 Mike =20 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, January 31, 2006 12:55 PM To: 'Stark, Barbara'; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. =20 You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. =20 Brian =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary =20 This seems generally reasonable to me, also.=20 However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing".=20 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact.=20 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches.=20 Barbara=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote:=20 1. By default, the device is set to use the home dialplan=20 and home emergency numbers, either directly or via=20 the home provider.=20 2. If not at home, the device get its location and also=20 the visited emergency numbers via some means=20 3. The visited emergency numbers take precendence=20 over the home dialling plan, if a clash occurs.=20 (Note: your home provider may provide you with an=20 escape code to override this, but then you definitely know=20 what you are doing - e.g. to reach 911xxx local numbers in UK=20 if you happen to be in the US.)=20 Note: this may cause some emergency calls done wrong,=20 but this is preferrable to missroute some real emergency calls=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------_=_NextPart_001_01C6269B.78F77EA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = Issue 30: Summary
The implication of what you are saying is that any = number that=20 begins with a digit string that happens to match any emergency number = must be=20 removed from any dial plan since the terminal will route it as an = emergency=20 before any additional digits can be dialed.
 
I wonder how someone whose phone number starts with 911 = (as was=20 pointed out earlier in examples) is just going to "get over it" as you=20 say.  You are saying they need to get a new phone number.  = Yet, I=20 thought an earlier post also said that these dial plans were a national=20 matter.  In other words, it you don't like their dial plan, you = will need=20 to "get over it."
 
I must not be understanding what you are = suggesting.  Could=20 you explain it to the level of detail that Barbara = did?
 
Mike
 

From: Brian Rosen = [mailto:br@brianrosen.net]=20
Sent: Tuesday, January 31, 2006 2:04 PM
To: = Michael=20 Hammer (mhammer); 'Stark, Barbara'; ecrit@ietf.org
Subject: = RE:=20 [Ecrit] Issue 30: Summary

You are = trying to=20 come at this by claiming that the engineering works a particular way, = so users=20 should adapt.  I understand that the problem is that you are = putting a=20 visited emergency number into a home dial plan.  That is, in = general,=20 hard.

 

But I think = the=20 operative phrase is English: “get over it”. The = REQUIREMENT is, I think, that=20 the visited emergency number works, always, without anything = funny. =20 That’s an end user experience requirement.  We have to = figure out how to=20 make the devices meet that requirement.

 

So, if you = had an=20 overlap, it is the emergency number that “wins” (that is, = is recognized as the=20 end of dialing), with some escape mechanism needed for whatever it = overlapped=20 in the original dial plan.

 

Brian

 

From: Michael=20 Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Tuesday, January 31, 2006 = 1:45=20 PM
To: = br@brianrosen.net;=20 Stark, Barbara; ecrit@ietf.org
Subject: RE: [Ecrit] Issue 30:=20 Summary

 

Brian,

 

I thought = Barbara=20 stated the problem well and a solution for disambiguating the overlap = in dial=20 plans.  Note that plans is plural.  This is a question of = conflicts=20 in dial plans.

 

The core = of this is=20 that *** the endpoint doesn't know *** it is an "emergency = number" until=20 the process for separating out the overlaps is complete.  The=20 delay or # or immediate is *how it = knows*.

 

Your = reasoning is=20 circular here.  There is a Latin name for this, but hey, I didn't = study=20 Latin.

 

Mike

 

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Tuesday, January 31, = 2006 12:55=20 PM
To: 'Stark, = Barbara';=20 ecrit@ietf.org
Subject: RE:=20 [Ecrit] Issue 30: Summary

If you = would like,=20 I’ll raise this with the PSAP and NENA folks.  I = don’t think they will=20 agree with you.

The = visited=20 emergency number has to work immediately, which means it has to be=20 recognized by a dial plan, and not depend on timeouts or # key=20 presses.

I think = they would=20 say that the home emergency number could have the delay or=20 #.

 

You are = proposing=20 to change current behavior; as it stands now, if you bring a phone = into a=20 country, it’s the visited emergency number that works.  I = do understand=20 that if you use an enterprise phone from a VPN or something = equivalent,=20 everything breaks (you don’t have the local emergency number, = you don’t have=20 correct location, and the call goes to the home psap).   I = think=20 we really are better off with “both”, even if that = causes some kinds of=20 problems with home dial plans.  It’s much easier to deal = with Extension=20 999 doesn’t work as a 3 digit number when I call from the UK = as it does=20 “please remember to hit # or wait 4 seconds” to get help = when you are in the=20 middle of London.

 

Brian

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, = Barbara
Sent: Tuesday, January 31, = 2006 10:44=20 AM
To:=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] Issue 30: Summary

 

This seems = generally=20 reasonable to me, also.
However,=20 there is an implicit expectation in the description below that I'm = not quite=20 comfortable with, in the "precedence" statement. That is, whether or = not end=20 of dialing string is automatically recognized for visited emergency=20 numbers.

For devices = that use a=20 "Send" button, this isn't a problem. "Send" must always be pressed = to=20 indicate "end of dialing". For these, there would be no clash = between a=20 US "911" and = UK=20 "911xxx" dial string. If the user enters "911xxx" + "Send", then = this must=20 never be interpreted as "911". Similarly, "911" + "Send" is equally=20 unambiguous (in this example).

SIP devices = without a=20 "Send" button generally employ a variety of mechanisms to recognize = "end of=20 dialing".
 1. Some = strings=20 are automatically recognized; for example, when a user dials any = "N11"=20 string and has an ATA configured for US=20 dialing plans, the ATA recognizes this string and automatically = sends the=20 SIP Invite without waiting any further.

 2. The = user can=20 usually press "#" to indicate end of dialing. Many users are unaware = of this=20 fact.
 3. If = the user=20 does not press another digit in 4 or 5 seconds (differs by device), = this is=20 interpreted as end of dialing, and the SIP Invite is=20 sent.

What this = means, is=20 that, if a user enters a string that is not automatically recognized = as=20 being "complete", and the user doesn't press "#", there will be a 4 = or 5=20 second delay between the time when the last digit is pressed and SIP = signaling begins.

While I = realize that=20 this delay is generally undesirable, I would prefer that there be no = requirement to automatically recognize "end of dialing" for visited=20 emergency strings.

The flip side = of this is=20 that if the ATA's current dialing plan has an automatically escaped = string=20 that is shorter than the visited emergency number (e.g., an ATA = might=20 automatically recognize "00" as a complete string, and the visited = emergency=20 number is "000"), then the ATA logic needs to stop recognizing "00" = as a=20 complete string. I'm fine with this. The user can then dial "00" (+ = timeout)=20 or "00#", and also "000" (+ timeout) or = "000#".

If done this = way, the=20 only clashes would be for exact matches.
Barbara=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
On Jan 28, = 2006, at=20 12:25 PM, Stastny Richard wrote:

1. By default, = the=20 device is set to use the home dialplan
and home = emergency=20 numbers, either directly or via
the home=20 provider.
2. If not at = home, the=20 device get its location and also
the visited=20 emergency numbers via some means
3. The=20 visited emergency numbers take precendence
over the home = dialling=20 plan, if a clash occurs.
(Note: your=20 home provider may provide you with an
escape code to = override=20 this, but then you definitely know
what you are = doing -=20 e.g. to reach 911xxx local numbers in UK
if you=20 happen to be in the US.) =
Note: this may = cause=20 some emergency calls done wrong,
but this is=20 preferrable to missroute some real emergency calls=20

*****

The = information=20 transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or = privileged=20 material. Any review, retransmission, dissemination or other use of, = or=20 taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received=20 this in error, please contact the sender and delete the material = from all=20 computers. 117

------_=_NextPart_001_01C6269B.78F77EA8-- --===============0752759821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0752759821==-- From ecrit-bounces@ietf.org Tue Jan 31 14:40:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Mm-0007xi-CT; Tue, 31 Jan 2006 14:40:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Mk-0007wo-OZ for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 14:40:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21988 for ; Tue, 31 Jan 2006 14:39:02 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41Xl-0001k4-Uc for ecrit@ietf.org; Tue, 31 Jan 2006 14:52:03 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F41Mg-0007bg-QU; Tue, 31 Jan 2006 13:40:35 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 14:35:11 -0500 Message-ID: <043001c6269d$753ab320$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD32@bre2k61p-55> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHKMGAAAZxL4A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 1.1 (+) X-Scan-Signature: 422b4fa0641ab05cf7ef45aaac177626 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0294527441==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0294527441== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0431_01C62673.8C64AB20" This is a multi-part message in MIME format. ------=_NextPart_000_0431_01C62673.8C64AB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So, bottom line: GSM's work because it uses the visited dial plan, with the visited emergency number. Roaming VoIP today doesn't work at all for emergency calling, but if it did work, you assume it must have the home dial plan. What I'm saying is that the way roaming VoIP should work is that the home dial plan should be altered to have the visited emergency number, and any overlap should require an escape mechanism from the merged dial plan to access. So, if you are calling someone with a 911 extension while you are roaming in the U.S., you may need to dial a 6911, or you may need to dial #911 or something else. I actually think that is not a problem. I do wonder if some kind of confirmation may be useful if you do have overlap, just so you don't dial the local emergency number by mistake, but I think confirmation would be much less error prone than escape for local emergency number. Apply the babysitter test to Henning's German VSP. There is a phone on his home office desk. It is indistinguishable from any other phone in the house visually. The babysitter has an emergency and picks it up. She hears dial tone. She dials 9-1-1. It should work, and it should work right away. If 911231232 is a legal number in Germany, Henning may have to dial a prefix to get it. I think that is the right tradeoff. Brian _____ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Sent: Tuesday, January 31, 2006 2:17 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you bring a GSM phone into a foreign country, it's the visited emergency number which will work, and the dialing plan will be local to where you're visiting. If you bring a SIP ATA into a foreign country, today, it will have absolutely no knowledge of the visited emergency number. For a US-based SIP service (provided by a Voice Service Provider) it will know the home emergency number (although the actual recognition of the string as an emergency string will happen at the proxy server, and not at the device itself -- today's VSP-provided devices don't have special "emergency recognition" code in their software). However, an emergency call from a foreign country today will be misrouted, since it will be based on the static location information the subscriber provided. Since the US VSP will not provide service without an emegency location for which it is able to provide emergency service, and US VSPs are only able to provide emergency routing for a subset of US locations, the location will be extremely inaccurate. For SIP ATAs, current behavior, as it stands, is that emergency dialing does not work when calling from a foreign country. The visited emergency string isn't recognized at all. Yes, I am proposing that this behavior be changed. But to try to force GSM-like behavior on a VSP service isn't reasonable. The expectations of the customer are completely different. The GSM customer expects their entire dialing plan to change and to become local to the visited location. The VSP customer (today) expects their dialing plan to be completely static, independent of where they visit. The purpose for using a German VSP service in the US is so that you can dial German phone numbers locally, and be reached locally from Germany. This is completely and totally different from the expectations of the GSM customer. The GSM customer's dialing plan is always determined by the owner of the cell tower they're connected to. The VSP customer's dialing plan is always determined by the same proxy server, no matter where in the world they are. This means, by the way, that unless the device itself recognizes the visited emergency number, visited location numbers will never, ever work for these customers. If the visited emergency dial string reaches the proxy without having been changed to the SIP Emergency URI, then the proxy will NOT recognize it as an emergency dial string. The proxy will only recognize home strings, and the emergency URI. Because the VSP may not be able to control whether the user's device can recognize visited emergency numbers, it is likely that VSPs will instruct customers to always use the home emergency number, independent of where they are. Furthermore, the VSP would probably tell the customer that a visited emergency number may or may not work, depending on the capabilities of the device they are using, and depending on the capabilities of the LAN and ISP they are connected through; therefore, absolutely no assurances can be made as to whether or not the visited emergency number will work. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, January 31, 2006 12:55 PM To: Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary This seems generally reasonable to me, also. However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing". 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact. 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches. Barbara ======================================== On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: 1. By default, the device is set to use the home dialplan and home emergency numbers, either directly or via the home provider. 2. If not at home, the device get its location and also the visited emergency numbers via some means 3. The visited emergency numbers take precendence over the home dialling plan, if a clash occurs. (Note: your home provider may provide you with an escape code to override this, but then you definitely know what you are doing - e.g. to reach 911xxx local numbers in UK if you happen to be in the US.) Note: this may cause some emergency calls done wrong, but this is preferrable to missroute some real emergency calls ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------=_NextPart_000_0431_01C62673.8C64AB20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary

So, bottom = line:

GSM’s work because it uses = the visited dial plan, with the visited emergency = number.

Roaming VoIP today doesn’t = work at all for emergency calling, but if it did work, you assume it must have = the home dial plan.

 

What I’m saying is that the = way roaming VoIP should work is that the home dial plan should be altered to = have the visited emergency number, and any overlap should require an escape mechanism from the merged dial plan to access.  So, if you are = calling someone with a 911 extension while you are roaming in the = U.S., you may need to dial a 6911, or you may need to dial #911 or something = else.

 

I actually think that is not a problem.  I do wonder if some kind of confirmation may be useful if = you do have overlap, just so you don’t dial the local emergency number by mistake, but I think confirmation would be much less error prone than = escape for local emergency number.

 

Apply the babysitter test to = Henning’s German VSP.  There is a phone on his home office desk.  It is indistinguishable from any other phone in the house visually.  The babysitter has an emergency and picks it up.  She hears dial = tone.  She dials 9-1-1.  It should work, and it should work right = away.  If 911231232 is a legal number in Germany, Henning may have to dial a prefix to get it.  I think that is the = right tradeoff.

 

Brian

 

 

From: = Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
Sent: Tuesday, January = 31, 2006 2:17 PM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 

If you bring a GSM phone into a = foreign country, it's the visited emergency number which will work, and the = dialing plan will be local to where you're = visiting.

 

If you bring a SIP ATA into a = foreign country, today, it will have absolutely no knowledge of the visited = emergency number. For a US-based SIP service (provided by a Voice Service = Provider) it will know the home emergency number (although the actual recognition of = the string as an emergency string will happen at the proxy server, and not = at the device itself -- today's VSP-provided devices don't have special = "emergency recognition" code in their software). However, an emergency call = from a foreign country today will be misrouted, since it will be based on the = static location information the subscriber provided. Since the US VSP will not = provide service without an emegency location for which it is able to provide = emergency service, and US VSPs are only able to provide emergency routing for a = subset of US locations, the location will be extremely = inaccurate.

 

For SIP ATAs, current behavior, as = it stands, is that emergency dialing does not work when calling from a = foreign country. The visited emergency string isn't recognized at all. Yes, I am proposing that this behavior be changed. But to try to force GSM-like = behavior on a VSP service isn't reasonable. The expectations of the customer are completely different. The GSM customer expects their entire dialing plan = to change and to become local to the visited location. The VSP customer = (today) expects their dialing plan to be completely static, independent of where = they visit. The purpose for using a  German VSP service in the = US is so that you can dial German phone = numbers locally, and be reached locally from Germany. This is = completely and totally different from the expectations of the GSM = customer.

 

The GSM customer's dialing plan is = always determined by the owner of the cell tower they're connected to. The VSP customer's dialing plan is always determined by the same proxy server, = no matter where in the world they are. This means, by the way, that unless = the device itself recognizes the visited emergency number, visited location = numbers will never, ever work for these customers. If the visited emergency dial = string reaches the proxy without having been changed to the SIP Emergency URI, = then the proxy will NOT recognize it as an emergency dial string. The proxy = will only recognize home strings, and the emergency URI. Because the VSP may = not be able to control whether the user's device can recognize visited = emergency numbers, it is likely that VSPs will instruct customers to always use the home = emergency number, independent of where they are. Furthermore, the VSP would = probably tell the customer that a visited emergency number may or may not work, = depending on the capabilities of the device they are using, and depending on the capabilities of the LAN and ISP they are connected through; therefore, absolutely no assurances can be made as to whether or not the visited = emergency number will work.

Barbara 

=

-----Original = Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, January = 31, 2006 12:55 PM
To: Stark, Barbara; = ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

If you would like, I’ll raise = this with the PSAP and NENA folks.  I don’t think they will agree = with you.

The visited emergency number has to = work immediately, which means it has to be recognized by a dial plan, and not = depend on timeouts or # key presses.

I think they would say that the = home emergency number could have the delay or #.

 

You are proposing to change current behavior; as it stands now, if you bring a phone into a country, = it’s the visited emergency number that works.  I do understand that if you = use an enterprise phone from a VPN or something equivalent, everything breaks = (you don’t have the local emergency number, you don’t have correct location, = and the call goes to the home psap).   I think we really are better = off with “both”, even if that causes some kinds of problems with home = dial plans.  It’s much easier to deal with Extension 999 = doesn’t work as a 3 digit number when I call from the UK as it does = “please remember to hit # or wait 4 seconds” to get help when you are in = the middle of London.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara
Sent: Tuesday, January = 31, 2006 10:44 AM
To: ecrit@ietf.org
Subject: Re: [Ecrit] = Issue 30: Summary

 

This seems generally reasonable to me, = also.
However, there is an implicit expectation in the description below that I'm not = quite comfortable with, in the "precedence" statement. That is, = whether or not end of dialing string is automatically recognized for visited = emergency numbers.

For devices that use a "Send" button, this = isn't a problem. "Send" must always be pressed to indicate "end = of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as = "911". Similarly, "911" + "Send" is equally unambiguous (in = this example).

SIP devices without a "Send" button generally = employ a variety of mechanisms to recognize "end of dialing". =
 1. Some strings are automatically recognized; for example, when a user = dials any "N11" string and has an ATA configured for US dialing plans, the ATA = recognizes this string and automatically sends the SIP Invite without waiting any = further.

 2. The user can usually press "#" to = indicate end of dialing. Many users are unaware of this fact.
 3. If the user does not press another digit in 4 or 5 seconds (differs by = device), this is interpreted as end of dialing, and the SIP Invite is = sent.

What this means, is that, if a user enters a string that = is not automatically recognized as being "complete", and the user = doesn't press "#", there will be a 4 or 5 second delay between the = time when the last digit is pressed and SIP signaling = begins.

While I realize that this delay is generally undesirable, = I would prefer that there be no requirement to automatically recognize = "end of dialing" for visited emergency = strings.

The flip side of this is that if the ATA's current = dialing plan has an automatically escaped string that is shorter than the visited = emergency number (e.g., an ATA might automatically recognize "00" as a = complete string, and the visited emergency number is "000"), then the = ATA logic needs to stop recognizing "00" as a complete string. I'm = fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or = "000#".

If done this way, the only clashes would be for exact = matches.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: =

1. By default, the = device is set to use the home dialplan
and home emergency numbers, either directly or via
the home provider.
2. If not at home, the device get its location and also
the visited emergency numbers via some means
3. The visited emergency numbers take precendence
over the home dialling plan, if a clash occurs.
(Note: your home provider may provide you with an
escape code to override this, but then you definitely know
what you are doing - e.g. to reach 911xxx local numbers in = UK
if you happen to be in the US.)
Note: this may cause some emergency calls done wrong,
but this is preferrable to missroute some real emergency calls =

*****

The information transmitted is intended = only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon = this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and = delete the material from all computers. 117

------=_NextPart_000_0431_01C62673.8C64AB20-- --===============0294527441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0294527441==-- From ecrit-bounces@ietf.org Tue Jan 31 15:42:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42Ke-000483-VX; Tue, 31 Jan 2006 15:42:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42Kd-00047g-GA for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 15:42:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26129 for ; Tue, 31 Jan 2006 15:40:52 -0500 (EST) Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F42Vb-0004CD-VM for ecrit@ietf.org; Tue, 31 Jan 2006 15:53:54 -0500 Received: from ([90.152.52.44]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.106902764; Tue, 31 Jan 2006 15:40:13 -0500 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 31 Jan 2006 14:40:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 14:40:14 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BD34@bre2k61p-55> Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHKMGAAAZxL4AABqC1A From: "Stark, Barbara" To: , X-OriginalArrivalTime: 31 Jan 2006 20:40:14.0648 (UTC) FILETIME=[89E3EB80:01C626A6] X-Spam-Score: 1.2 (+) X-Scan-Signature: 313575717ab99ab523072fd0986ea42f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300538848==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1300538848== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C626A6.89BD8FAF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C626A6.89BD8FAF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian said: I do wonder if some kind of confirmation may be useful if you do have overlap, just so you don't dial the local emergency number by mistake, but I think confirmation would be much less error prone than escape for local emergency number. =20 A confirmation, after you dial the overlapping-with-local-dial-plan visited emergency number (possibly accidentally), would take longer than the 4 to 5 seconds of waiting that I proposed. By the way, what language is the confirmation in? Home or visited? =20 Given that most visitors of the temporarily-visiting kind (not the ex-pat kind) are absolutely clueless as to the visited emergency number of wherever they're visiting, it's likely that they won't know to dial a prefix before an overlapping home string. My mother, brother, and I have all been to Switzerland many times (and my mother is an ex-pat), but none of us could tell you what to dial from a landline in case of an emergency. I don't recall any fire trucks or police cars going by with numbers written on them, either. =20 I have enough trouble getting it through the thick skulls of my co-workers that they shouldn't dial 9-1-1 from our building, because the IP PBX is located 10 miles away. We have a special 10-digit emergency number to dial. I've sent repeated emails, written articles in our newsletter, and have stickers available for their phones. And in spite of all the stickers and notices, the first thing someone did when he needed to call in an emergency was dial 9-1-1. Fortunately, it's still inside the same city, so the call was routed correctly. =20 The main problem you're trying to address is the babysitter (what is she doing in the home office, anyway?), and that's really a corner case. 5 extra seconds for that corner case is not unreasonable. Personally, I'd much prefer to have a completely predictable home dialing plan, and know that 9-1-1 always works, than have to try to figure out all visited emergency numbers and whether or not there's a number thay overlaps my home dialing plan. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, January 31, 2006 2:35 PM To: Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary So, bottom line: GSM's work because it uses the visited dial plan, with the visited emergency number. Roaming VoIP today doesn't work at all for emergency calling, but if it did work, you assume it must have the home dial plan. =20 What I'm saying is that the way roaming VoIP should work is that the home dial plan should be altered to have the visited emergency number, and any overlap should require an escape mechanism from the merged dial plan to access. So, if you are calling someone with a 911 extension while you are roaming in the U.S., you may need to dial a 6911, or you may need to dial #911 or something else. =20 I actually think that is not a problem. I do wonder if some kind of confirmation may be useful if you do have overlap, just so you don't dial the local emergency number by mistake, but I think confirmation would be much less error prone than escape for local emergency number. =20 Apply the babysitter test to Henning's German VSP. There is a phone on his home office desk. It is indistinguishable from any other phone in the house visually. The babysitter has an emergency and picks it up. She hears dial tone. She dials 9-1-1. It should work, and it should work right away. If 911231232 is a legal number in Germany, Henning may have to dial a prefix to get it. I think that is the right tradeoff. =20 Brian =20 =20 _____ =20 From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Tuesday, January 31, 2006 2:17 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 If you bring a GSM phone into a foreign country, it's the visited emergency number which will work, and the dialing plan will be local to where you're visiting. =20 If you bring a SIP ATA into a foreign country, today, it will have absolutely no knowledge of the visited emergency number. For a US-based SIP service (provided by a Voice Service Provider) it will know the home emergency number (although the actual recognition of the string as an emergency string will happen at the proxy server, and not at the device itself -- today's VSP-provided devices don't have special "emergency recognition" code in their software). However, an emergency call from a foreign country today will be misrouted, since it will be based on the static location information the subscriber provided. Since the US VSP will not provide service without an emegency location for which it is able to provide emergency service, and US VSPs are only able to provide emergency routing for a subset of US locations, the location will be extremely inaccurate. =20 For SIP ATAs, current behavior, as it stands, is that emergency dialing does not work when calling from a foreign country. The visited emergency string isn't recognized at all. Yes, I am proposing that this behavior be changed. But to try to force GSM-like behavior on a VSP service isn't reasonable. The expectations of the customer are completely different. The GSM customer expects their entire dialing plan to change and to become local to the visited location. The VSP customer (today) expects their dialing plan to be completely static, independent of where they visit. The purpose for using a German VSP service in the US is so that you can dial German phone numbers locally, and be reached locally from Germany. This is completely and totally different from the expectations of the GSM customer. =20 The GSM customer's dialing plan is always determined by the owner of the cell tower they're connected to. The VSP customer's dialing plan is always determined by the same proxy server, no matter where in the world they are. This means, by the way, that unless the device itself recognizes the visited emergency number, visited location numbers will never, ever work for these customers. If the visited emergency dial string reaches the proxy without having been changed to the SIP Emergency URI, then the proxy will NOT recognize it as an emergency dial string. The proxy will only recognize home strings, and the emergency URI. Because the VSP may not be able to control whether the user's device can recognize visited emergency numbers, it is likely that VSPs will instruct customers to always use the home emergency number, independent of where they are. Furthermore, the VSP would probably tell the customer that a visited emergency number may or may not work, depending on the capabilities of the device they are using, and depending on the capabilities of the LAN and ISP they are connected through; therefore, absolutely no assurances can be made as to whether or not the visited emergency number will work. Barbara=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, January 31, 2006 12:55 PM To: Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you would like, I'll raise this with the PSAP and NENA folks. I don't think they will agree with you. The visited emergency number has to work immediately, which means it has to be recognized by a dial plan, and not depend on timeouts or # key presses. I think they would say that the home emergency number could have the delay or #. =20 You are proposing to change current behavior; as it stands now, if you bring a phone into a country, it's the visited emergency number that works. I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don't have the local emergency number, you don't have correct location, and the call goes to the home psap). I think we really are better off with "both", even if that causes some kinds of problems with home dial plans. It's much easier to deal with Extension 999 doesn't work as a 3 digit number when I call from the UK as it does "please remember to hit # or wait 4 seconds" to get help when you are in the middle of London. =20 Brian =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary =20 This seems generally reasonable to me, also.=20 However, there is an implicit expectation in the description below that I'm not quite comfortable with, in the "precedence" statement. That is, whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of mechanisms to recognize "end of dialing".=20 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many users are unaware of this fact.=20 3. If the user does not press another digit in 4 or 5 seconds (differs by device), this is interpreted as end of dialing, and the SIP Invite is sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic needs to stop recognizing "00" as a complete string. I'm fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches.=20 Barbara=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote:=20 1. By default, the device is set to use the home dialplan=20 and home emergency numbers, either directly or via=20 the home provider.=20 2. If not at home, the device get its location and also=20 the visited emergency numbers via some means=20 3. The visited emergency numbers take precendence=20 over the home dialling plan, if a clash occurs.=20 (Note: your home provider may provide you with an=20 escape code to override this, but then you definitely know=20 what you are doing - e.g. to reach 911xxx local numbers in UK=20 if you happen to be in the US.)=20 Note: this may cause some emergency calls done wrong,=20 but this is preferrable to missroute some real emergency calls=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 ------_=_NextPart_001_01C626A6.89BD8FAF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary
Brian=20 said:
I do=20 wonder if some kind of confirmation may be useful if you do have = overlap, just=20 so you don’t dial the local emergency number by mistake, but I = think=20 confirmation would be much less error prone than escape for local = emergency=20 number.
 
A=20 confirmation, after you dial the overlapping-with-local-dial-plan = visited=20 emergency number (possibly accidentally), would take longer than the 4 = to 5=20 seconds of waiting that I proposed. By the way, what language is the=20 confirmation in? Home or visited?
 
Given=20 that most visitors of the temporarily-visiting kind (not the ex-pat = kind) are=20 absolutely clueless as to the visited emergency number of wherever = they're=20 visiting, it's likely that they won't know to dial a prefix before an=20 overlapping home string. My mother, brother, and I have all been to = Switzerland many times (and my mother is an ex-pat), but none of us = could tell=20 you what to dial from a landline in case of an emergency. I don't recall = any=20 fire trucks or police cars going by with numbers written on them,=20 either.
 
I have=20 enough trouble getting it through the thick skulls of my co-workers that = they shouldn't dial 9-1-1 from our building, because the IP PBX is = located=20 10 miles away. We have a special 10-digit emergency number to = dial. I've=20 sent repeated emails, written articles in our newsletter, and have = stickers=20 available for their phones. And in spite of all the stickers and = notices, the=20 first thing someone did when he needed to call in an emergency was dial = 9-1-1.=20 Fortunately, it's still inside the same city, so the call was routed=20 correctly.
 
The=20 main problem you're trying to address is the babysitter (what is she = doing in=20 the home office, anyway?), and that's really a corner case. 5 extra = seconds for=20 that corner case is not unreasonable. Personally, I'd much prefer to = have a=20 completely predictable home dialing plan, and know that 9-1-1 always = works, than=20 have to try to figure out all visited emergency numbers and whether or = not=20 there's a number thay overlaps my home dialing plan.
Barbara
-----Original Message-----
From: Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: Tuesday, January 31, 2006 = 2:35=20 PM
To: Stark, Barbara; ecrit@ietf.org
Subject: RE: = [Ecrit]=20 Issue 30: Summary

So, bottom=20 line:

GSM’s = work because it=20 uses the visited dial plan, with the visited emergency=20 number.

Roaming = VoIP today=20 doesn’t work at all for emergency calling, but if it did work, = you assume it=20 must have the home dial plan.

 

What = I’m saying is=20 that the way roaming VoIP should work is that the home dial plan = should be=20 altered to have the visited emergency number, and any overlap should = require=20 an escape mechanism from the merged dial plan to access.  So, if = you are=20 calling someone with a 911 extension while you are roaming in the=20 U.S., you may need to = dial a 6911,=20 or you may need to dial #911 or something = else.

 

I actually = think that=20 is not a problem.  I do wonder if some kind of confirmation may = be useful=20 if you do have overlap, just so you don’t dial the local = emergency number by=20 mistake, but I think confirmation would be much less error prone than = escape=20 for local emergency number.

 

Apply the = babysitter=20 test to Henning’s German VSP.  There is a phone on his home = office desk.=20  It is indistinguishable from any other phone in the house = visually.=20  The babysitter has an emergency and picks it up.  She hears = dial=20 tone.  She dials 9-1-1.  It should work, and it should work = right=20 away.  If 911231232 is a legal number in Germany,=20 Henning may have to dial a prefix to get it.  I think that is the = right=20 tradeoff.

 

Brian

 

 

From: Stark,=20 Barbara [mailto:Barbara.Stark@BellSouth.com]
Sent: Tuesday, January 31, 2006 = 2:17=20 PM
To: = br@brianrosen.net;=20 ecrit@ietf.org
Subject: RE:=20 [Ecrit] Issue 30: Summary

 

If you = bring a GSM=20 phone into a foreign country, it's the visited emergency number which = will=20 work, and the dialing plan will be local to where you're=20 visiting.

 

If you = bring a SIP=20 ATA into a foreign country, today, it will have absolutely no = knowledge of the=20 visited emergency number. For a US-based SIP service (provided by a = Voice=20 Service Provider) it will know the home emergency number (although the = actual=20 recognition of the string as an emergency string will happen at the = proxy=20 server, and not at the device itself -- today's VSP-provided devices = don't=20 have special "emergency recognition" code in their software). However, = an=20 emergency call from a foreign country today will be misrouted, since = it will=20 be based on the static location information the subscriber provided. = Since the=20 US VSP will not provide service without an emegency location for which = it is=20 able to provide emergency service, and US VSPs are only able to = provide=20 emergency routing for a subset of US locations, the location will be = extremely=20 inaccurate.

 

For SIP = ATAs, current=20 behavior, as it stands, is that emergency dialing does not work when = calling=20 from a foreign country. The visited emergency string isn't recognized = at all.=20 Yes, I am proposing that this behavior be changed. But to try to force = GSM-like behavior on a VSP service isn't reasonable. The expectations = of the=20 customer are completely different. The GSM customer expects their = entire=20 dialing plan to change and to become local to the visited location. = The VSP=20 customer (today) expects their dialing plan to be completely static,=20 independent of where they visit. The purpose for using a  German = VSP=20 service in the US = is so=20 that you can dial German phone numbers locally, and be reached locally = from=20 Germany. This is = completely and=20 totally different from the expectations of the GSM=20 customer.

 

The GSM = customer's=20 dialing plan is always determined by the owner of the cell tower = they're=20 connected to. The VSP customer's dialing plan is always determined by = the same=20 proxy server, no matter where in the world they are. This means, by = the way,=20 that unless the device itself recognizes the visited emergency number, = visited=20 location numbers will never, ever work for these customers. If the = visited=20 emergency dial string reaches the proxy without having been changed to = the SIP=20 Emergency URI, then the proxy will NOT recognize it as an emergency = dial=20 string. The proxy will only recognize home strings, and the emergency = URI.=20 Because the VSP may not be able to control whether the user's device = can=20 recognize visited emergency numbers, it is likely that VSPs will = instruct=20 customers to always use the home emergency number, independent of = where they=20 are. Furthermore, the VSP would probably tell the customer that a = visited=20 emergency number may or may not work, depending on the capabilities of = the=20 device they are using, and depending on the capabilities of the LAN = and ISP=20 they are connected through; therefore, absolutely no assurances can be = made as=20 to whether or not the visited emergency number will=20 work.

Barbara 

-----Original=20 Message-----
From: Brian=20 Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, January 31, = 2006 12:55=20 PM
To: Stark, = Barbara;=20 ecrit@ietf.org
Subject: RE:=20 [Ecrit] Issue 30: Summary

If you = would like,=20 I’ll raise this with the PSAP and NENA folks.  I = don’t think they will=20 agree with you.

The = visited=20 emergency number has to work immediately, which means it has to be=20 recognized by a dial plan, and not depend on timeouts or # key=20 presses.

I think = they would=20 say that the home emergency number could have the delay or=20 #.

 

You are = proposing=20 to change current behavior; as it stands now, if you bring a phone = into a=20 country, it’s the visited emergency number that works.  I = do understand=20 that if you use an enterprise phone from a VPN or something = equivalent,=20 everything breaks (you don’t have the local emergency number, = you don’t have=20 correct location, and the call goes to the home psap).   I = think=20 we really are better off with “both”, even if that = causes some kinds of=20 problems with home dial plans.  It’s much easier to deal = with Extension=20 999 doesn’t work as a 3 digit number when I call from the UK = as it does=20 “please remember to hit # or wait 4 seconds” to get help = when you are in the=20 middle of London.

 

Brian

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, = Barbara
Sent: Tuesday, January 31, = 2006 10:44=20 AM
To:=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] Issue 30: Summary

 

This seems = generally=20 reasonable to me, also.
However,=20 there is an implicit expectation in the description below that I'm = not quite=20 comfortable with, in the "precedence" statement. That is, whether or = not end=20 of dialing string is automatically recognized for visited emergency=20 numbers.

For devices = that use a=20 "Send" button, this isn't a problem. "Send" must always be pressed = to=20 indicate "end of dialing". For these, there would be no clash = between a=20 US "911" and = UK=20 "911xxx" dial string. If the user enters "911xxx" + "Send", then = this must=20 never be interpreted as "911". Similarly, "911" + "Send" is equally=20 unambiguous (in this example).

SIP devices = without a=20 "Send" button generally employ a variety of mechanisms to recognize = "end of=20 dialing".
 1. Some = strings=20 are automatically recognized; for example, when a user dials any = "N11"=20 string and has an ATA configured for US=20 dialing plans, the ATA recognizes this string and automatically = sends the=20 SIP Invite without waiting any further.

 2. The = user can=20 usually press "#" to indicate end of dialing. Many users are unaware = of this=20 fact.
 3. If = the user=20 does not press another digit in 4 or 5 seconds (differs by device), = this is=20 interpreted as end of dialing, and the SIP Invite is=20 sent.

What this = means, is=20 that, if a user enters a string that is not automatically recognized = as=20 being "complete", and the user doesn't press "#", there will be a 4 = or 5=20 second delay between the time when the last digit is pressed and SIP = signaling begins.

While I = realize that=20 this delay is generally undesirable, I would prefer that there be no = requirement to automatically recognize "end of dialing" for visited=20 emergency strings.

The flip side = of this is=20 that if the ATA's current dialing plan has an automatically escaped = string=20 that is shorter than the visited emergency number (e.g., an ATA = might=20 automatically recognize "00" as a complete string, and the visited = emergency=20 number is "000"), then the ATA logic needs to stop recognizing "00" = as a=20 complete string. I'm fine with this. The user can then dial "00" (+ = timeout)=20 or "00#", and also "000" (+ timeout) or = "000#".

If done this = way, the=20 only clashes would be for exact matches.
Barbara=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
On Jan 28, = 2006, at=20 12:25 PM, Stastny Richard wrote:

1. By default, = the=20 device is set to use the home dialplan
and home = emergency=20 numbers, either directly or via
the home=20 provider.
2. If not at = home, the=20 device get its location and also
the visited=20 emergency numbers via some means
3. The=20 visited emergency numbers take precendence
over the home = dialling=20 plan, if a clash occurs.
(Note: your=20 home provider may provide you with an
escape code to = override=20 this, but then you definitely know
what you are = doing -=20 e.g. to reach 911xxx local numbers in UK
if you=20 happen to be in the US.) =
Note: this may = cause=20 some emergency calls done wrong,
but this is=20 preferrable to missroute some real emergency calls=20

*****

The = information=20 transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or = privileged=20 material. Any review, retransmission, dissemination or other use of, = or=20 taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received=20 this in error, please contact the sender and delete the material = from all=20 computers. 117

------_=_NextPart_001_01C626A6.89BD8FAF-- --===============1300538848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1300538848==-- From ecrit-bounces@ietf.org Tue Jan 31 16:19:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42uB-0004d6-HA; Tue, 31 Jan 2006 16:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42u9-0004by-II for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 16:19:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00647 for ; Tue, 31 Jan 2006 16:17:34 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4358-0006AY-TL for ecrit@ietf.org; Tue, 31 Jan 2006 16:30:36 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 15:18:56 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 31 Jan 2006 15:18:56 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 15:18:55 -0600 Message-ID: From: "Thomson, Martin" To: "Stark, Barbara" , Date: Tue, 31 Jan 2006 15:16:56 -0600 Subject: RE: [Ecrit] Issue 30: Summary MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 31 Jan 2006 21:18:55.0145 (UTC) FILETIME=[F103A990:01C626AB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 30: Summary Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgALWj/Q X-Spam-Score: 0.3 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2129636839==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2129636839== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_15_18_56_Tuesday_January_31_2006_9640" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_15_18_56_Tuesday_January_31_2006_9640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyBzb21lIHJlYWwgZGF0YSBtaWdodCBoZWxwIGhlcmUuDQoNCiANCg0KVGhlIGZvbGxv d2luZyBpcyB0aGUgZGlhbCBwbGFuIHN0cmluZyBmcm9tIGFuIEFUQSBzb2xkIGhlcmUgaW4gQXVz dHJhbGlhOg0KDQogDQoNCigqeHh8WzM0NjldMTF8MHwwMHxbMi05XXh4eHh4eHwxeHh4WzItOV14 eHh4eHhTMHx4eHh4eHh4eHh4eHguKQ0KDQogDQoNCkl04oCZcyBpbnRlcmVzdGluZyBob3cgdGhp cyBzaG93cyB0aGF0IHRoZSB2ZW5kb3IgZGlkbuKAmXQgY29uc2lkZXIgdGhlIEF1c3RyYWxpYW4g ZW1lcmdlbmN5IG51bWJlci4gIEkgdGhpbmsgdGhhdCB0aGlzIGlzIHRoZSBzYW1lIGRpYWwgcGxh biBmb3IgdGhlIGRldmljZSBhcyBzb2xkIGluIHRoZSBVUywgd2UgaGFkIG9uZSBvZiB0aG9zZSwg YnV0IEkgdGhpbmsgSSBvdmVycm9kZSB0aGUgZGlhbCBwbGFuIG9uIGl0Lg0KDQogDQoNClRoZSB3 YXkgdGhhdCB0aGlzIGRldmljZSB3b3JrcyBpcyBleGFjdGx5IGFzIEJhcmJhcmEgZGVzY3JpYmVz IGJlbG93OiBpZiB0aGlzIHN0cmluZyBpcyBtYXRjaGVkIHRvIHRoZSBkaWFsZWQgZGlnaXRzLCB0 aGUgY2FsbCBnb2VzIGltbWVkaWF0ZWx5OyBvdGhlcndpc2UsIHRoZSBBVEEgd2FpdHMgKHRoZXJl IGFyZSB0d28gdGltZXJzIHRoYXQgSSB0aGluayBhcHBseSwgc2V0IHRvIDMgYW5kIDEwIHNlY29u ZHMgZWFjaCkgYmVmb3JlIHNlbmRpbmcgdGhlIGludml0ZS4gIEkgZGlkbuKAmXQga25vdyBhYm91 dCB0aGUgaGFzaCBlaXRoZXIsIHNvIEkgd291bGQgaGF2ZSB0byBjaGVjayB0aGF0IG9uZS4NCg0K IA0KDQpPbiBvdmVybGFwLCBJIG5vdGUgdGhhdCB0aGUgMCBhbmQgMDAgbnVtYmVycyBhcmUgYm90 aCByZWNvZ25pemVkLg0KDQogDQoNCklmIHRoZXJlIGlzIGludGVyZXN0LCBJIHdpbGwgZG8gYSBs aXR0bGUgbW9yZSBkaWdnaW5nLg0KDQogDQoNCk1fVA0KDQogDQoNCiANCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGFyaywgQmFyYmFyYQ0K U2VudDogV2VkbmVzZGF5LCAxIEZlYnJ1YXJ5IDIwMDYgMjo0NCBBTQ0KVG86IGVjcml0QGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0Vjcml0XSBJc3N1ZSAzMDogU3VtbWFyeQ0KDQogDQoNClRoaXMg c2VlbXMgZ2VuZXJhbGx5IHJlYXNvbmFibGUgdG8gbWUsIGFsc28uIA0KSG93ZXZlciwgdGhlcmUg aXMgYW4gaW1wbGljaXQgZXhwZWN0YXRpb24gaW4gdGhlIGRlc2NyaXB0aW9uIGJlbG93IHRoYXQg SSdtIG5vdCBxdWl0ZSBjb21mb3J0YWJsZSB3aXRoLCBpbiB0aGUgInByZWNlZGVuY2UiIHN0YXRl bWVudC4gVGhhdCBpcywgd2hldGhlciBvciBub3QgZW5kIG9mIGRpYWxpbmcgc3RyaW5nIGlzIGF1 dG9tYXRpY2FsbHkgcmVjb2duaXplZCBmb3IgdmlzaXRlZCBlbWVyZ2VuY3kgbnVtYmVycy4NCg0K Rm9yIGRldmljZXMgdGhhdCB1c2UgYSAiU2VuZCIgYnV0dG9uLCB0aGlzIGlzbid0IGEgcHJvYmxl bS4gIlNlbmQiIG11c3QgYWx3YXlzIGJlIHByZXNzZWQgdG8gaW5kaWNhdGUgImVuZCBvZiBkaWFs aW5nIi4gRm9yIHRoZXNlLCB0aGVyZSB3b3VsZCBiZSBubyBjbGFzaCBiZXR3ZWVuIGEgVVMgIjkx MSIgYW5kIFVLICI5MTF4eHgiIGRpYWwgc3RyaW5nLiBJZiB0aGUgdXNlciBlbnRlcnMgIjkxMXh4 eCIgKyAiU2VuZCIsIHRoZW4gdGhpcyBtdXN0IG5ldmVyIGJlIGludGVycHJldGVkIGFzICI5MTEi LiBTaW1pbGFybHksICI5MTEiICsgIlNlbmQiIGlzIGVxdWFsbHkgdW5hbWJpZ3VvdXMgKGluIHRo aXMgZXhhbXBsZSkuDQoNClNJUCBkZXZpY2VzIHdpdGhvdXQgYSAiU2VuZCIgYnV0dG9uIGdlbmVy YWxseSBlbXBsb3kgYSB2YXJpZXR5IG9mIG1lY2hhbmlzbXMgdG8gcmVjb2duaXplICJlbmQgb2Yg ZGlhbGluZyIuIA0KIDEuIFNvbWUgc3RyaW5ncyBhcmUgYXV0b21hdGljYWxseSByZWNvZ25pemVk OyBmb3IgZXhhbXBsZSwgd2hlbiBhIHVzZXIgZGlhbHMgYW55ICJOMTEiIHN0cmluZyBhbmQgaGFz IGFuIEFUQSBjb25maWd1cmVkIGZvciBVUyBkaWFsaW5nIHBsYW5zLCB0aGUgQVRBIHJlY29nbml6 ZXMgdGhpcyBzdHJpbmcgYW5kIGF1dG9tYXRpY2FsbHkgc2VuZHMgdGhlIFNJUCBJbnZpdGUgd2l0 aG91dCB3YWl0aW5nIGFueSBmdXJ0aGVyLg0KDQogMi4gVGhlIHVzZXIgY2FuIHVzdWFsbHkgcHJl c3MgIiMiIHRvIGluZGljYXRlIGVuZCBvZiBkaWFsaW5nLiBNYW55IHVzZXJzIGFyZSB1bmF3YXJl IG9mIHRoaXMgZmFjdC4gDQogMy4gSWYgdGhlIHVzZXIgZG9lcyBub3QgcHJlc3MgYW5vdGhlciBk aWdpdCBpbiA0IG9yIDUgc2Vjb25kcyAoZGlmZmVycyBieSBkZXZpY2UpLCB0aGlzIGlzIGludGVy cHJldGVkIGFzIGVuZCBvZiBkaWFsaW5nLCBhbmQgdGhlIFNJUCBJbnZpdGUgaXMgc2VudC4NCg0K V2hhdCB0aGlzIG1lYW5zLCBpcyB0aGF0LCBpZiBhIHVzZXIgZW50ZXJzIGEgc3RyaW5nIHRoYXQg aXMgbm90IGF1dG9tYXRpY2FsbHkgcmVjb2duaXplZCBhcyBiZWluZyAiY29tcGxldGUiLCBhbmQg dGhlIHVzZXIgZG9lc24ndCBwcmVzcyAiIyIsIHRoZXJlIHdpbGwgYmUgYSA0IG9yIDUgc2Vjb25k IGRlbGF5IGJldHdlZW4gdGhlIHRpbWUgd2hlbiB0aGUgbGFzdCBkaWdpdCBpcyBwcmVzc2VkIGFu ZCBTSVAgc2lnbmFsaW5nIGJlZ2lucy4NCg0KV2hpbGUgSSByZWFsaXplIHRoYXQgdGhpcyBkZWxh eSBpcyBnZW5lcmFsbHkgdW5kZXNpcmFibGUsIEkgd291bGQgcHJlZmVyIHRoYXQgdGhlcmUgYmUg bm8gcmVxdWlyZW1lbnQgdG8gYXV0b21hdGljYWxseSByZWNvZ25pemUgImVuZCBvZiBkaWFsaW5n IiBmb3IgdmlzaXRlZCBlbWVyZ2VuY3kgc3RyaW5ncy4NCg0KVGhlIGZsaXAgc2lkZSBvZiB0aGlz IGlzIHRoYXQgaWYgdGhlIEFUQSdzIGN1cnJlbnQgZGlhbGluZyBwbGFuIGhhcyBhbiBhdXRvbWF0 aWNhbGx5IGVzY2FwZWQgc3RyaW5nIHRoYXQgaXMgc2hvcnRlciB0aGFuIHRoZSB2aXNpdGVkIGVt ZXJnZW5jeSBudW1iZXIgKGUuZy4sIGFuIEFUQSBtaWdodCBhdXRvbWF0aWNhbGx5IHJlY29nbml6 ZSAiMDAiIGFzIGEgY29tcGxldGUgc3RyaW5nLCBhbmQgdGhlIHZpc2l0ZWQgZW1lcmdlbmN5IG51 bWJlciBpcyAiMDAwIiksIHRoZW4gdGhlIEFUQSBsb2dpYyBuZWVkcyB0byBzdG9wIHJlY29nbml6 aW5nICIwMCIgYXMgYSBjb21wbGV0ZSBzdHJpbmcuIEknbSBmaW5lIHdpdGggdGhpcy4gVGhlIHVz ZXIgY2FuIHRoZW4gZGlhbCAiMDAiICgrIHRpbWVvdXQpIG9yICIwMCMiLCBhbmQgYWxzbyAiMDAw IiAoKyB0aW1lb3V0KSBvciAiMDAwIyIuDQoNCklmIGRvbmUgdGhpcyB3YXksIHRoZSBvbmx5IGNs YXNoZXMgd291bGQgYmUgZm9yIGV4YWN0IG1hdGNoZXMuIA0KQmFyYmFyYSANCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQpPbiBKYW4gMjgsIDIwMDYsIGF0IDEyOjI1 IFBNLCBTdGFzdG55IFJpY2hhcmQgd3JvdGU6IA0KDQoxLiBCeSBkZWZhdWx0LCB0aGUgZGV2aWNl IGlzIHNldCB0byB1c2UgdGhlIGhvbWUgZGlhbHBsYW4gDQphbmQgaG9tZSBlbWVyZ2VuY3kgbnVt YmVycywgZWl0aGVyIGRpcmVjdGx5IG9yIHZpYSANCnRoZSBob21lIHByb3ZpZGVyLiANCjIuIElm IG5vdCBhdCBob21lLCB0aGUgZGV2aWNlIGdldCBpdHMgbG9jYXRpb24gYW5kIGFsc28gDQp0aGUg dmlzaXRlZCBlbWVyZ2VuY3kgbnVtYmVycyB2aWEgc29tZSBtZWFucyANCjMuIFRoZSB2aXNpdGVk IGVtZXJnZW5jeSBudW1iZXJzIHRha2UgcHJlY2VuZGVuY2UgDQpvdmVyIHRoZSBob21lIGRpYWxs aW5nIHBsYW4sIGlmIGEgY2xhc2ggb2NjdXJzLiANCihOb3RlOiB5b3VyIGhvbWUgcHJvdmlkZXIg bWF5IHByb3ZpZGUgeW91IHdpdGggYW4gDQplc2NhcGUgY29kZSB0byBvdmVycmlkZSB0aGlzLCBi dXQgdGhlbiB5b3UgZGVmaW5pdGVseSBrbm93IA0Kd2hhdCB5b3UgYXJlIGRvaW5nIC0gZS5nLiB0 byByZWFjaCA5MTF4eHggbG9jYWwgbnVtYmVycyBpbiBVSyANCmlmIHlvdSBoYXBwZW4gdG8gYmUg aW4gdGhlIFVTLikgDQpOb3RlOiB0aGlzIG1heSBjYXVzZSBzb21lIGVtZXJnZW5jeSBjYWxscyBk b25lIHdyb25nLCANCmJ1dCB0aGlzIGlzIHByZWZlcnJhYmxlIHRvIG1pc3Nyb3V0ZSBzb21lIHJl YWwgZW1lcmdlbmN5IGNhbGxzIA0KDQoqKioqKg0KDQpUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0 ZWQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hpY2ggaXQg aXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBh bmQvb3IgcHJpdmlsZWdlZCBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRp c3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiBy ZWxpYW5jZSB1cG9uIHRoaXMgaW5mb3JtYXRpb24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp dmVkIHRoaXMgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGUgbWF0ZXJpYWwgZnJvbSBhbGwgY29tcHV0ZXJzLiAxMTcNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnks IG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWls IGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClttZjJd ----=_NextPart_ST_15_18_56_Tuesday_January_31_2006_9640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPg0KPHRpdGxlPlJlOiBbRWNyaXRdIElzc3VlIDMwOiBTdW1tYXJ5PC90aXRsZT4N CjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJjb3VudHJ5LXJlZ2lvbiIvPg0KPG86U21hcnRUYWdU eXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0 YWdzIg0KIG5hbWU9InBsYWNlIi8+DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxz dHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2Nv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnANCgl7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNl Y3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoxODk0ODAzMDUxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTA5NTA4NDI2Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPg0K PC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1w dXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox MC4wcHQnPlBlcmhhcHMgc29tZSByZWFsIGRhdGEgbWlnaHQgaGVscCBoZXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox MC4wcHQnPlRoZSBmb2xsb3dpbmcgaXMgdGhlIGRpYWwgcGxhbiBzdHJpbmcgZnJvbSBhbiBBVEEg c29sZCBoZXJlIGluIDxzdDE6cGxhY2UNCnc6c3Q9Im9uIj48c3QxOmNvdW50cnktcmVnaW9uIHc6 c3Q9Im9uIj5BdXN0cmFsaWE8L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT46PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdCc+KCp4eHxbMzQ2OV0xMXwwfDAwfFsyLTldeHh4eHh4fDF4eHhbMi05XXh4eHh4 eFMwfHh4eHh4eHh4eHh4eC4pPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+SXTigJlzIGludGVyZXN0aW5nIGhv dyB0aGlzIHNob3dzIHRoYXQgdGhlIHZlbmRvciBkaWRu4oCZdCBjb25zaWRlciB0aGUNCkF1c3Ry YWxpYW4gZW1lcmdlbmN5IG51bWJlci7CoCBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgc2FtZSBk aWFsIHBsYW4gZm9yIHRoZQ0KZGV2aWNlIGFzIHNvbGQgaW4gdGhlIDxzdDE6cGxhY2UgdzpzdD0i b24iPjxzdDE6Y291bnRyeS1yZWdpb24gdzpzdD0ib24iPlVTPC9zdDE6Y291bnRyeS1yZWdpb24+ PC9zdDE6cGxhY2U+LA0Kd2UgaGFkIG9uZSBvZiB0aG9zZSwgYnV0IEkgdGhpbmsgSSBvdmVycm9k ZSB0aGUgZGlhbCBwbGFuIG9uIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPlRoZSB3YXkgdGhhdCB0aGlz IGRldmljZSB3b3JrcyBpcyBleGFjdGx5IGFzIEJhcmJhcmEgZGVzY3JpYmVzIGJlbG93Og0KaWYg dGhpcyBzdHJpbmcgaXMgbWF0Y2hlZCB0byB0aGUgZGlhbGVkIGRpZ2l0cywgdGhlIGNhbGwgZ29l cyBpbW1lZGlhdGVseTsNCm90aGVyd2lzZSwgdGhlIEFUQSB3YWl0cyAodGhlcmUgYXJlIHR3byB0 aW1lcnMgdGhhdCBJIHRoaW5rIGFwcGx5LCBzZXQgdG8gMyBhbmQNCjEwIHNlY29uZHMgZWFjaCkg YmVmb3JlIHNlbmRpbmcgdGhlIGludml0ZS7CoCBJIGRpZG7igJl0IGtub3cgYWJvdXQgdGhlIGhh c2gNCmVpdGhlciwgc28gSSB3b3VsZCBoYXZlIHRvIGNoZWNrIHRoYXQgb25lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox MC4wcHQnPk9uIG92ZXJsYXAsIEkgbm90ZSB0aGF0IHRoZSAwIGFuZCAwMCBudW1iZXJzIGFyZSBi b3RoIHJlY29nbml6ZWQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+SWYgdGhlcmUgaXMgaW50ZXJlc3QsIEkg d2lsbCBkbyBhIGxpdHRsZSBtb3JlIGRpZ2dpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+TV9UPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWdu PWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXpl PTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4NCg0KPC9zcGFuPjwvZm9u dD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9t YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250 LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1U YWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4N CmVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSA8 Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9i PlN0YXJrLCBCYXJiYXJhPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNl bnQ6PC9zcGFuPjwvYj4gV2VkbmVzZGF5LCAxIEZlYnJ1YXJ5IDIwMDYNCjI6NDQgQU08YnI+DQo8 Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gZWNyaXRAaWV0 Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3Nw YW4+PC9iPiBSZTogW0Vjcml0XSBJc3N1ZSAzMDoNClN1bW1hcnk8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 DQoiQ291cmllciBOZXciJz5UaGlzIHNlZW1zIGdlbmVyYWxseSByZWFzb25hYmxlIHRvIG1lLCBh bHNvLjwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ SG93ZXZlciwNCnRoZXJlIGlzIGFuIGltcGxpY2l0IGV4cGVjdGF0aW9uIGluIHRoZSBkZXNjcmlw dGlvbiBiZWxvdyB0aGF0IEknbSBub3QgcXVpdGUNCmNvbWZvcnRhYmxlIHdpdGgsIGluIHRoZSAm cXVvdDtwcmVjZWRlbmNlJnF1b3Q7IHN0YXRlbWVudC4gVGhhdCBpcywgd2hldGhlciBvcg0Kbm90 IGVuZCBvZiBkaWFsaW5nIHN0cmluZyBpcyBhdXRvbWF0aWNhbGx5IHJlY29nbml6ZWQgZm9yIHZp c2l0ZWQgZW1lcmdlbmN5DQpudW1iZXJzLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoN CjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiQ291cmllciBOZXciJz5Gb3IgZGV2aWNlcyB0aGF0IHVz ZSBhICZxdW90O1NlbmQmcXVvdDsgYnV0dG9uLCB0aGlzIGlzbid0IGENCnByb2JsZW0uICZxdW90 O1NlbmQmcXVvdDsgbXVzdCBhbHdheXMgYmUgcHJlc3NlZCB0byBpbmRpY2F0ZSAmcXVvdDtlbmQg b2YNCmRpYWxpbmcmcXVvdDsuIEZvciB0aGVzZSwgdGhlcmUgd291bGQgYmUgbm8gY2xhc2ggYmV0 d2VlbiBhIDxzdDE6Y291bnRyeS1yZWdpb24NCnc6c3Q9Im9uIj5VUzwvc3QxOmNvdW50cnktcmVn aW9uPiAmcXVvdDs5MTEmcXVvdDsgYW5kIDxzdDE6Y291bnRyeS1yZWdpb24NCnc6c3Q9Im9uIj48 c3QxOnBsYWNlIHc6c3Q9Im9uIj5VSzwvc3QxOnBsYWNlPjwvc3QxOmNvdW50cnktcmVnaW9uPg0K JnF1b3Q7OTExeHh4JnF1b3Q7IGRpYWwgc3RyaW5nLiBJZiB0aGUgdXNlciBlbnRlcnMgJnF1b3Q7 OTExeHh4JnF1b3Q7ICsNCiZxdW90O1NlbmQmcXVvdDssIHRoZW4gdGhpcyBtdXN0IG5ldmVyIGJl IGludGVycHJldGVkIGFzICZxdW90OzkxMSZxdW90Oy4NClNpbWlsYXJseSwgJnF1b3Q7OTExJnF1 b3Q7ICsgJnF1b3Q7U2VuZCZxdW90OyBpcyBlcXVhbGx5IHVuYW1iaWd1b3VzIChpbiB0aGlzDQpl eGFtcGxlKS48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5Og0KIkNvdXJpZXIgTmV3Iic+U0lQIGRldmljZXMgd2l0aG91dCBhICZxdW90O1NlbmQmcXVv dDsgYnV0dG9uIGdlbmVyYWxseSBlbXBsb3kgYQ0KdmFyaWV0eSBvZiBtZWNoYW5pc21zIHRvIHJl Y29nbml6ZSAmcXVvdDtlbmQgb2YgZGlhbGluZyZxdW90Oy4gPC9zcGFuPjwvZm9udD48YnI+DQo8 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzEuDQpTb21lIHN0cmluZ3MgYXJl IGF1dG9tYXRpY2FsbHkgcmVjb2duaXplZDsgZm9yIGV4YW1wbGUsIHdoZW4gYSB1c2VyIGRpYWxz IGFueQ0KJnF1b3Q7TjExJnF1b3Q7IHN0cmluZyBhbmQgaGFzIGFuIEFUQSBjb25maWd1cmVkIGZv ciA8c3QxOmNvdW50cnktcmVnaW9uIHc6c3Q9Im9uIj48c3QxOnBsYWNlDQogdzpzdD0ib24iPlVT PC9zdDE6cGxhY2U+PC9zdDE6Y291bnRyeS1yZWdpb24+IGRpYWxpbmcgcGxhbnMsIHRoZSBBVEEN CnJlY29nbml6ZXMgdGhpcyBzdHJpbmcgYW5kIGF1dG9tYXRpY2FsbHkgc2VuZHMgdGhlIFNJUCBJ bnZpdGUgd2l0aG91dCB3YWl0aW5nDQphbnkgZnVydGhlci48L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Iic+Jm5ic3A7Mi4g VGhlIHVzZXIgY2FuIHVzdWFsbHkgcHJlc3MgJnF1b3Q7IyZxdW90OyB0byBpbmRpY2F0ZQ0KZW5k IG9mIGRpYWxpbmcuIE1hbnkgdXNlcnMgYXJlIHVuYXdhcmUgb2YgdGhpcyBmYWN0Ljwvc3Bhbj48 L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7My4NCklm IHRoZSB1c2VyIGRvZXMgbm90IHByZXNzIGFub3RoZXIgZGlnaXQgaW4gNCBvciA1IHNlY29uZHMg KGRpZmZlcnMgYnkgZGV2aWNlKSwNCnRoaXMgaXMgaW50ZXJwcmV0ZWQgYXMgZW5kIG9mIGRpYWxp bmcsIGFuZCB0aGUgU0lQIEludml0ZSBpcyBzZW50Ljwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiQ291cmllciBOZXciJz5XaGF0IHRoaXMgbWVh bnMsIGlzIHRoYXQsIGlmIGEgdXNlciBlbnRlcnMgYSBzdHJpbmcgdGhhdCBpcyBub3QNCmF1dG9t YXRpY2FsbHkgcmVjb2duaXplZCBhcyBiZWluZyAmcXVvdDtjb21wbGV0ZSZxdW90OywgYW5kIHRo ZSB1c2VyIGRvZXNuJ3QNCnByZXNzICZxdW90OyMmcXVvdDssIHRoZXJlIHdpbGwgYmUgYSA0IG9y IDUgc2Vjb25kIGRlbGF5IGJldHdlZW4gdGhlIHRpbWUgd2hlbg0KdGhlIGxhc3QgZGlnaXQgaXMg cHJlc3NlZCBhbmQgU0lQIHNpZ25hbGluZyBiZWdpbnMuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJDb3VyaWVyIE5ldyInPldoaWxlIEkgcmVh bGl6ZSB0aGF0IHRoaXMgZGVsYXkgaXMgZ2VuZXJhbGx5IHVuZGVzaXJhYmxlLCBJDQp3b3VsZCBw cmVmZXIgdGhhdCB0aGVyZSBiZSBubyByZXF1aXJlbWVudCB0byBhdXRvbWF0aWNhbGx5IHJlY29n bml6ZSAmcXVvdDtlbmQNCm9mIGRpYWxpbmcmcXVvdDsgZm9yIHZpc2l0ZWQgZW1lcmdlbmN5IHN0 cmluZ3MuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToNCiJDb3VyaWVyIE5ldyInPlRoZSBmbGlwIHNpZGUgb2YgdGhpcyBpcyB0aGF0IGlmIHRoZSBB VEEncyBjdXJyZW50IGRpYWxpbmcgcGxhbg0KaGFzIGFuIGF1dG9tYXRpY2FsbHkgZXNjYXBlZCBz dHJpbmcgdGhhdCBpcyBzaG9ydGVyIHRoYW4gdGhlIHZpc2l0ZWQgZW1lcmdlbmN5DQpudW1iZXIg KGUuZy4sIGFuIEFUQSBtaWdodCBhdXRvbWF0aWNhbGx5IHJlY29nbml6ZSAmcXVvdDswMCZxdW90 OyBhcyBhIGNvbXBsZXRlDQpzdHJpbmcsIGFuZCB0aGUgdmlzaXRlZCBlbWVyZ2VuY3kgbnVtYmVy IGlzICZxdW90OzAwMCZxdW90OyksIHRoZW4gdGhlIEFUQQ0KbG9naWMgbmVlZHMgdG8gc3RvcCBy ZWNvZ25pemluZyAmcXVvdDswMCZxdW90OyBhcyBhIGNvbXBsZXRlIHN0cmluZy4gSSdtIGZpbmUN CndpdGggdGhpcy4gVGhlIHVzZXIgY2FuIHRoZW4gZGlhbCAmcXVvdDswMCZxdW90OyAoKyB0aW1l b3V0KSBvcg0KJnF1b3Q7MDAjJnF1b3Q7LCBhbmQgYWxzbyAmcXVvdDswMDAmcXVvdDsgKCsgdGlt ZW91dCkgb3IgJnF1b3Q7MDAwIyZxdW90Oy48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIkNvdXJpZXIgTmV3Iic+SWYgZG9uZSB0aGlzIHdheSwg dGhlIG9ubHkgY2xhc2hlcyB3b3VsZCBiZSBmb3IgZXhhY3QgbWF0Y2hlcy48L3NwYW4+PC9mb250 Pg0KPGJyPg0KPGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5CYXJiYXJhPC9zcGFuPjwv Zm9udD4NCjxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48L2ZvbnQ+DQo8YnI+DQo8Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPk9uDQpKYW4gMjgsIDIwMDYsIGF0IDEyOjI1IFBNLCBT dGFzdG55IFJpY2hhcmQgd3JvdGU6PC9zcGFuPjwvZm9udD4gPG86cD48L286cD48L3A+DQoNCjxw IHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjEuIEJ5IGRlZmF1bHQsIHRoZSBkZXZpY2UgaXMNCnNldCB0byB1c2UgdGhlIGhvbWUgZGlh bHBsYW48L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PmFuZA0KaG9tZSBlbWVyZ2VuY3kgbnVtYmVycywgZWl0aGVyIGRpcmVjdGx5IG9yIHZpYTwvc3Bh bj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+dGhlDQpob21l IHByb3ZpZGVyLjwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Mi4NCklmIG5vdCBhdCBob21lLCB0aGUgZGV2aWNlIGdldCBpdHMgbG9jYXRpb24gYW5k IGFsc288L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PnRoZQ0KdmlzaXRlZCBlbWVyZ2VuY3kgbnVtYmVycyB2aWEgc29tZSBtZWFuczwvc3Bhbj48L2Zv bnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+My4NClRoZSB2aXNpdGVk IGVtZXJnZW5jeSBudW1iZXJzIHRha2UgcHJlY2VuZGVuY2U8L3NwYW4+PC9mb250PiA8YnI+DQo8 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPm92ZXINCnRoZSBob21lIGRpYWxsaW5nIHBs YW4sIGlmIGEgY2xhc2ggb2NjdXJzLjwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+KE5vdGU6DQp5b3VyIGhvbWUgcHJvdmlkZXIgbWF5IHByb3ZpZGUg eW91IHdpdGggYW48L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPmVzY2FwZQ0KY29kZSB0byBvdmVycmlkZSB0aGlzLCBidXQgdGhlbiB5b3UgZGVmaW5p dGVseSBrbm93PC9zcGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz53aGF0DQp5b3UgYXJlIGRvaW5nIC0gZS5nLiB0byByZWFjaCA5MTF4eHggbG9jYWwgbnVt YmVycyBpbiA8c3QxOmNvdW50cnktcmVnaW9uDQp3OnN0PSJvbiI+VUs8L3N0MTpjb3VudHJ5LXJl Z2lvbj48L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PmlmDQp5b3UgaGFwcGVuIHRvIGJlIGluIHRoZSA8c3QxOmNvdW50cnktcmVnaW9uIHc6c3Q9Im9u Ij48c3QxOnBsYWNlIHc6c3Q9Im9uIj5VUzwvc3QxOnBsYWNlPjwvc3QxOmNvdW50cnktcmVnaW9u Pi4pPC9zcGFuPjwvZm9udD4NCjxicj4NCjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Tm90ZToNCnRoaXMgbWF5IGNhdXNlIHNvbWUgZW1lcmdlbmN5IGNhbGxzIGRvbmUgd3JvbmcsPC9z cGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5idXQNCnRo aXMgaXMgcHJlZmVycmFibGUgdG8gbWlzc3JvdXRlIHNvbWUgcmVhbCBlbWVyZ2VuY3kgY2FsbHM8 L3NwYW4+PC9mb250PiA8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8YnI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPlRoaXMgbWVzc2FnZSBp cyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heTxicj5jb250YWluIHBy aXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4g IDxicj5JZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyPGJyPmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2Y8YnI+dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLjxicj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+W21mMl08L2JvZHk+DQoNCjwhLS1bb2Jq ZWN0X2lkPSNiZWxsc291dGguY29tI10tLT48Rk9OVCBjb2xvcj0jMDAwMGZmPg0KPFA+PEZPTlQg ZmFjZT1UYWhvbWEgY29sb3I9IzAwMDAwMCBzaXplPTI+KioqKio8L0ZPTlQ+PC9QPg0KPFA+PEZP TlQgZmFjZT1UYWhvbWEgY29sb3I9IzAwMDAwMCBzaXplPTI+VGhlIGluZm9ybWF0aW9uIHRyYW5z bWl0dGVkIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsLCBwcm9wcmlldGFy eSwgYW5kL29yIHByaXZpbGVnZWQgbWF0ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9u LCBkaXNzZW1pbmF0aW9uIG9yIG90aGVyIHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24g aW4gcmVsaWFuY2UgdXBvbiB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMg b3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBy ZWNlaXZlZCB0aGlzIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhlIG1hdGVyaWFsIGZyb20gYWxsIGNvbXB1dGVycy4gMTE3PC9GT05UPjwvUD48L0ZPTlQ+ DQo8L2h0bWw+DQo= ----=_NextPart_ST_15_18_56_Tuesday_January_31_2006_9640-- --===============2129636839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2129636839==-- From ecrit-bounces@ietf.org Tue Jan 31 16:22:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42xn-0006Gn-FS; Tue, 31 Jan 2006 16:22:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42xl-0006Bg-1C for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 16:22:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01466 for ; Tue, 31 Jan 2006 16:21:10 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F438c-0006UD-Fg for ecrit@ietf.org; Tue, 31 Jan 2006 16:34:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F42xW-0007Kt-AV; Tue, 31 Jan 2006 15:22:43 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Issue 30: Summary Date: Tue, 31 Jan 2006 16:21:56 -0500 Message-ID: <048201c626ac$5ee76050$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD34@bre2k61p-55> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYmfSOlgpUAdiSMRRC/MEOER29aYgAEV9SgAAHKMGAAAZxL4AABqC1AAAIKX5A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.7 (/) X-Scan-Signature: 3e7165a4e769b5e12b09901aeef88260 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369751577==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0369751577== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0483_01C62682.76115850" This is a multi-part message in MIME format. ------=_NextPart_000_0483_01C62682.76115850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We may have to agree to disagree, and we may need some more input. =20 It takes a whole lot less than 4 seconds to confirm. The language would probably have to be visited. Eventually, the phone will have a real UI = and we can do a lot better. =20 =20 Your experience with visiting other countries is much different from = mind. I learn the local emergency number wherever I travel because I might = need it. The emergency numbers in Switzerland are: 117 Polizei-Notruf =20 Police emergency call Police, appel d'urgence Polizia, chiamata di soccorso 117 118 Feuerwehr-Notruf Fire department emergency call Feu, centrale d'alarme Pompieri 118 144 Sanit=E4t-Notruf Ambulance emergency call Ambulances, appel d'urgence Pronto soccorso autoambulanze 144 =20 Your example of your IP-PBX is classic, and of course we want to make = 9-1-1 work for all of the employees and visitors who it serves. You may call the babysitter a corner case, I don=92t. It=92s the way = the world works now (VoIP is too new, and things don=92t work, we=92re trying to = fix that). =20 You may very well dial 9-1-1 in an emergency when you are in = Switzerland. That won=92t work the way you expect it to, but we can probably route = you to 117. That=92s the corner case. We should make it =93work=94, but = it=92s not really a requirement. The requirement is that 9-1-1 works from all phones in = North America, and that 117 works for police for all phones in Switzerland. =20 =20 Brian =20 _____ =20 From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Tuesday, January 31, 2006 3:40 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 Brian said: I do wonder if some kind of confirmation may be useful if you do have overlap, just so you don=92t dial the local emergency number by mistake, = but I think confirmation would be much less error prone than escape for local emergency number. =20 A confirmation, after you dial the overlapping-with-local-dial-plan = visited emergency number (possibly accidentally), would take longer than the 4 = to 5 seconds of waiting that I proposed. By the way, what language is the confirmation in? Home or visited? =20 Given that most visitors of the temporarily-visiting kind (not the = ex-pat kind) are absolutely clueless as to the visited emergency number of = wherever they're visiting, it's likely that they won't know to dial a prefix = before an overlapping home string. My mother, brother, and I have all been to Switzerland many times (and my mother is an ex-pat), but none of us = could tell you what to dial from a landline in case of an emergency. I don't recall any fire trucks or police cars going by with numbers written on = them, either. =20 I have enough trouble getting it through the thick skulls of my = co-workers that they shouldn't dial 9-1-1 from our building, because the IP PBX is located 10 miles away. We have a special 10-digit emergency number to = dial. I've sent repeated emails, written articles in our newsletter, and have stickers available for their phones. And in spite of all the stickers = and notices, the first thing someone did when he needed to call in an = emergency was dial 9-1-1. Fortunately, it's still inside the same city, so the = call was routed correctly. =20 The main problem you're trying to address is the babysitter (what is she doing in the home office, anyway?), and that's really a corner case. 5 = extra seconds for that corner case is not unreasonable. Personally, I'd much prefer to have a completely predictable home dialing plan, and know that 9-1-1 always works, than have to try to figure out all visited emergency numbers and whether or not there's a number thay overlaps my home = dialing plan. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, January 31, 2006 2:35 PM To: Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary So, bottom line: GSM=92s work because it uses the visited dial plan, with the visited = emergency number. Roaming VoIP today doesn=92t work at all for emergency calling, but if = it did work, you assume it must have the home dial plan. =20 What I=92m saying is that the way roaming VoIP should work is that the = home dial plan should be altered to have the visited emergency number, and = any overlap should require an escape mechanism from the merged dial plan to access. So, if you are calling someone with a 911 extension while you = are roaming in the U.S., you may need to dial a 6911, or you may need to = dial #911 or something else. =20 I actually think that is not a problem. I do wonder if some kind of confirmation may be useful if you do have overlap, just so you don=92t = dial the local emergency number by mistake, but I think confirmation would be much less error prone than escape for local emergency number. =20 Apply the babysitter test to Henning=92s German VSP. There is a phone = on his home office desk. It is indistinguishable from any other phone in the = house visually. The babysitter has an emergency and picks it up. She hears = dial tone. She dials 9-1-1. It should work, and it should work right away. = If 911231232 is a legal number in Germany, Henning may have to dial a = prefix to get it. I think that is the right tradeoff. =20 Brian =20 =20 _____ =20 From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Tuesday, January 31, 2006 2:17 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary =20 If you bring a GSM phone into a foreign country, it's the visited = emergency number which will work, and the dialing plan will be local to where = you're visiting. =20 If you bring a SIP ATA into a foreign country, today, it will have absolutely no knowledge of the visited emergency number. For a US-based = SIP service (provided by a Voice Service Provider) it will know the home emergency number (although the actual recognition of the string as an emergency string will happen at the proxy server, and not at the device itself -- today's VSP-provided devices don't have special "emergency recognition" code in their software). However, an emergency call from a foreign country today will be misrouted, since it will be based on the static location information the subscriber provided. Since the US VSP = will not provide service without an emegency location for which it is able to provide emergency service, and US VSPs are only able to provide = emergency routing for a subset of US locations, the location will be extremely inaccurate. =20 For SIP ATAs, current behavior, as it stands, is that emergency dialing = does not work when calling from a foreign country. The visited emergency = string isn't recognized at all. Yes, I am proposing that this behavior be = changed. But to try to force GSM-like behavior on a VSP service isn't reasonable. = The expectations of the customer are completely different. The GSM customer expects their entire dialing plan to change and to become local to the visited location. The VSP customer (today) expects their dialing plan to = be completely static, independent of where they visit. The purpose for = using a German VSP service in the US is so that you can dial German phone = numbers locally, and be reached locally from Germany. This is completely and = totally different from the expectations of the GSM customer. =20 The GSM customer's dialing plan is always determined by the owner of the cell tower they're connected to. The VSP customer's dialing plan is = always determined by the same proxy server, no matter where in the world they = are. This means, by the way, that unless the device itself recognizes the = visited emergency number, visited location numbers will never, ever work for = these customers. If the visited emergency dial string reaches the proxy = without having been changed to the SIP Emergency URI, then the proxy will NOT recognize it as an emergency dial string. The proxy will only recognize = home strings, and the emergency URI. Because the VSP may not be able to = control whether the user's device can recognize visited emergency numbers, it is likely that VSPs will instruct customers to always use the home = emergency number, independent of where they are. Furthermore, the VSP would = probably tell the customer that a visited emergency number may or may not work, depending on the capabilities of the device they are using, and = depending on the capabilities of the LAN and ISP they are connected through; = therefore, absolutely no assurances can be made as to whether or not the visited emergency number will work. Barbara=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, January 31, 2006 12:55 PM To: Stark, Barbara; ecrit@ietf.org Subject: RE: [Ecrit] Issue 30: Summary If you would like, I=92ll raise this with the PSAP and NENA folks. I = don=92t think they will agree with you. The visited emergency number has to work immediately, which means it has = to be recognized by a dial plan, and not depend on timeouts or # key = presses. I think they would say that the home emergency number could have the = delay or #. =20 You are proposing to change current behavior; as it stands now, if you = bring a phone into a country, it=92s the visited emergency number that works. = I do understand that if you use an enterprise phone from a VPN or something equivalent, everything breaks (you don=92t have the local emergency = number, you don=92t have correct location, and the call goes to the home psap). = I think we really are better off with =93both=94, even if that causes some = kinds of problems with home dial plans. It=92s much easier to deal with = Extension 999 doesn=92t work as a 3 digit number when I call from the UK as it = does =93please remember to hit # or wait 4 seconds=94 to get help when you = are in the middle of London. =20 Brian =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Stark, Barbara Sent: Tuesday, January 31, 2006 10:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary =20 This seems generally reasonable to me, also.=20 However, there is an implicit expectation in the description below that = I'm not quite comfortable with, in the "precedence" statement. That is, = whether or not end of dialing string is automatically recognized for visited emergency numbers. For devices that use a "Send" button, this isn't a problem. "Send" must always be pressed to indicate "end of dialing". For these, there would = be no clash between a US "911" and UK "911xxx" dial string. If the user enters "911xxx" + "Send", then this must never be interpreted as "911". = Similarly, "911" + "Send" is equally unambiguous (in this example). SIP devices without a "Send" button generally employ a variety of = mechanisms to recognize "end of dialing".=20 1. Some strings are automatically recognized; for example, when a user dials any "N11" string and has an ATA configured for US dialing plans, = the ATA recognizes this string and automatically sends the SIP Invite = without waiting any further. 2. The user can usually press "#" to indicate end of dialing. Many = users are unaware of this fact.=20 3. If the user does not press another digit in 4 or 5 seconds (differs = by device), this is interpreted as end of dialing, and the SIP Invite is = sent. What this means, is that, if a user enters a string that is not automatically recognized as being "complete", and the user doesn't press "#", there will be a 4 or 5 second delay between the time when the last digit is pressed and SIP signaling begins. While I realize that this delay is generally undesirable, I would prefer that there be no requirement to automatically recognize "end of dialing" = for visited emergency strings. The flip side of this is that if the ATA's current dialing plan has an automatically escaped string that is shorter than the visited emergency number (e.g., an ATA might automatically recognize "00" as a complete string, and the visited emergency number is "000"), then the ATA logic = needs to stop recognizing "00" as a complete string. I'm fine with this. The = user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or "000#". If done this way, the only clashes would be for exact matches.=20 Barbara=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote:=20 1. By default, the device is set to use the home dialplan=20 and home emergency numbers, either directly or via=20 the home provider.=20 2. If not at home, the device get its location and also=20 the visited emergency numbers via some means=20 3. The visited emergency numbers take precendence=20 over the home dialling plan, if a clash occurs.=20 (Note: your home provider may provide you with an=20 escape code to override this, but then you definitely know=20 what you are doing - e.g. to reach 911xxx local numbers in UK=20 if you happen to be in the US.)=20 Note: this may cause some emergency calls done wrong,=20 but this is preferrable to missroute some real emergency calls=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by persons = or entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the material from = all computers. 117 ------=_NextPart_000_0483_01C62682.76115850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Issue 30: Summary

We may have to agree to disagree, = and we may need some more input.

 

It takes a whole lot less than 4 = seconds to confirm. =A0The language would probably have to be visited. = =A0Eventually, the phone will have a real UI and we can do a lot better.=A0 =

 

Your experience with visiting other countries is much different from mind. =A0I learn the local emergency = number wherever I travel because I might need it. =A0=A0The emergency numbers = in Switzerland are:

117

Polizei-Notruf

Police = emergency call

Police, = appel d'urgence

Polizia, = chiamata di soccorso

117

118

Feuerwehr-Notruf

Fire department emergency = call

Feu, centrale = d'alarme

Pompieri

118

144

Sanit=E4t-Notruf

Ambulance emergency = call

Ambulances, appel = d'urgence

Pronto soccorso = autoambulanze

144

 

Your example of your IP-PBX is = classic, and of course we want to make 9-1-1 work for all of the employees and = visitors who it serves.

You may call the babysitter a = corner case, I don’t. =A0It’s the way the world works now (VoIP is too = new, and things don’t work, we’re trying to fix = that).

 

You may very well dial 9-1-1 in an emergency when you are in Switzerland. =A0That won’t work the way you expect it to, but we can probably = route you to 117. =A0That’s the corner case.=A0 We should make it = “work”, but it’s not really a requirement. =A0The requirement is that = 9-1-1 works from all phones in North America, and that 117 works for police for all = phones in Switzerland. =A0

 

Brian

 

From: = Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
Sent: Tuesday, January = 31, 2006 3:40 PM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 

Brian = said:

I do wonder if some kind of = confirmation may be useful if you do have overlap, just so you don’t dial the = local emergency number by mistake, but I think confirmation would be much less = error prone than escape for local emergency = number.

 

A confirmation, after you dial the overlapping-with-local-dial-plan visited emergency number (possibly accidentally), would take longer than the 4 to 5 seconds of waiting that = I proposed. By the way, what language is the confirmation in? Home or = visited?

 

Given that most visitors of the temporarily-visiting kind (not the ex-pat kind) are absolutely clueless = as to the visited emergency number of wherever they're visiting, it's = likely that they won't know to dial a prefix before an overlapping home string. My mother, brother, and I have all been to = Switzerland many times (and my mother is an ex-pat), but none of us could tell you = what to dial from a landline in case of an emergency. I don't recall any fire trucks or police cars going by with numbers written on them, = either.

 

I have enough trouble getting it = through the thick skulls of my co-workers that they shouldn't dial 9-1-1 = from our building, because the IP PBX is located 10 miles away. We have a special 10-digit emergency number to dial. I've sent repeated emails, = written articles in our newsletter, and have stickers available for their = phones. And in spite of all the stickers and notices, the first thing someone did = when he needed to call in an emergency was dial 9-1-1. Fortunately, it's still = inside the same city, so the call was routed = correctly.

 

The main problem you're trying to = address is the babysitter (what is she doing in the home office, anyway?), and = that's really a corner case. 5 extra seconds for that corner case is not unreasonable. Personally, I'd much prefer to have a completely predictable home = dialing plan, and know that 9-1-1 always works, than have to try to figure out all = visited emergency numbers and whether or not there's a number thay overlaps my = home dialing plan.

Barbara

=
=

-----Original = Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, January = 31, 2006 2:35 PM
To: Stark, Barbara; = ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

So, bottom = line:

GSM’s work because it uses = the visited dial plan, with the visited emergency = number.

Roaming VoIP today doesn’t = work at all for emergency calling, but if it did work, you assume it must have = the home dial plan.

 

What I’m saying is that the = way roaming VoIP should work is that the home dial plan should be altered to = have the visited emergency number, and any overlap should require an escape mechanism from the merged dial plan to access.  So, if you are = calling someone with a 911 extension while you are roaming in the U.S., you may need to dial = a 6911, or you may need to dial #911 or something = else.

 

I actually think that is not a problem.  I do wonder if some kind of confirmation may be useful if = you do have overlap, just so you don’t dial the local emergency number by mistake, but I think confirmation would be much less error prone than = escape for local emergency number.

 

Apply the babysitter test to Henning’s German VSP.  There is a phone on his home office = desk.  It is indistinguishable from any other phone in the house = visually.  The babysitter has an emergency and picks it up.  She hears = dial tone.  She dials 9-1-1.  It should work, and it should work = right away.  If 911231232 is a legal number in Germany, Henning may have = to dial a prefix to get it.  I think that is the right = tradeoff.

 

Brian

 

 

From: = Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
Sent: Tuesday, January = 31, 2006 2:17 PM
To: br@brianrosen.net; ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

 

If you bring a GSM phone into a = foreign country, it's the visited emergency number which will work, and the = dialing plan will be local to where you're = visiting.

 

If you bring a SIP ATA into a = foreign country, today, it will have absolutely no knowledge of the visited = emergency number. For a US-based SIP service (provided by a Voice Service = Provider) it will know the home emergency number (although the actual recognition of = the string as an emergency string will happen at the proxy server, and not = at the device itself -- today's VSP-provided devices don't have special = "emergency recognition" code in their software). However, an emergency call = from a foreign country today will be misrouted, since it will be based on the = static location information the subscriber provided. Since the US VSP will not = provide service without an emegency location for which it is able to provide = emergency service, and US VSPs are only able to provide emergency routing for a = subset of US locations, the location will be extremely = inaccurate.

 

For SIP ATAs, current behavior, as = it stands, is that emergency dialing does not work when calling from a = foreign country. The visited emergency string isn't recognized at all. Yes, I am proposing that this behavior be changed. But to try to force GSM-like = behavior on a VSP service isn't reasonable. The expectations of the customer are completely different. The GSM customer expects their entire dialing plan = to change and to become local to the visited location. The VSP customer = (today) expects their dialing plan to be completely static, independent of where = they visit. The purpose for using a  German VSP service in the = US is so that you can dial German phone = numbers locally, and be reached locally from Germany. This is = completely and totally different from the expectations of the GSM = customer.

 

The GSM customer's dialing plan is = always determined by the owner of the cell tower they're connected to. The VSP customer's dialing plan is always determined by the same proxy server, = no matter where in the world they are. This means, by the way, that unless = the device itself recognizes the visited emergency number, visited location = numbers will never, ever work for these customers. If the visited emergency dial = string reaches the proxy without having been changed to the SIP Emergency URI, = then the proxy will NOT recognize it as an emergency dial string. The proxy = will only recognize home strings, and the emergency URI. Because the VSP may = not be able to control whether the user's device can recognize visited = emergency numbers, it is likely that VSPs will instruct customers to always use = the home emergency number, independent of where they are. Furthermore, the VSP = would probably tell the customer that a visited emergency number may or may = not work, depending on the capabilities of the device they are using, and = depending on the capabilities of the LAN and ISP they are connected through; = therefore, absolutely no assurances can be made as to whether or not the visited = emergency number will work.

Barbara 

=

-----Original = Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, January = 31, 2006 12:55 PM
To: Stark, Barbara; = ecrit@ietf.org
Subject: RE: [Ecrit] = Issue 30: Summary

If you would like, I’ll raise = this with the PSAP and NENA folks.  I don’t think they will agree = with you.

The visited emergency number has to = work immediately, which means it has to be recognized by a dial plan, and not = depend on timeouts or # key presses.

I think they would say that the = home emergency number could have the delay or #.

 

You are proposing to change current behavior; as it stands now, if you bring a phone into a country, = it’s the visited emergency number that works.  I do understand that if you = use an enterprise phone from a VPN or something equivalent, everything breaks = (you don’t have the local emergency number, you don’t have = correct location, and the call goes to the home psap).   I think we = really are better off with “both”, even if that causes some kinds = of problems with home dial plans.  It’s much easier to deal with Extension 999 doesn’t work as a 3 digit number when I call from = the UK as it does “please remember to hit # or wait 4 seconds” to get = help when you are in the middle of London.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara
Sent: Tuesday, January = 31, 2006 10:44 AM
To: ecrit@ietf.org
Subject: Re: [Ecrit] = Issue 30: Summary

 

This seems generally reasonable to me, = also.
However, there is an implicit expectation in the description below that I'm not = quite comfortable with, in the "precedence" statement. That is, = whether or not end of dialing string is automatically recognized for visited = emergency numbers.

For devices that use a "Send" button, this = isn't a problem. "Send" must always be pressed to indicate "end = of dialing". For these, there would be no clash between a = US "911" and UK "911xxx" dial = string. If the user enters "911xxx" + "Send", then this must = never be interpreted as "911". Similarly, "911" + "Send" is equally unambiguous (in this = example).

SIP devices without a "Send" button generally = employ a variety of mechanisms to recognize "end of dialing". =
 1. Some strings are automatically recognized; for example, when a user = dials any "N11" string and has an ATA configured for US dialing plans, the ATA recognizes this string and automatically sends the SIP Invite without = waiting any further.

 2. The user can usually press "#" to = indicate end of dialing. Many users are unaware of this fact.
 3. If the user does not press another digit in 4 or 5 seconds (differs by = device), this is interpreted as end of dialing, and the SIP Invite is = sent.

What this means, is that, if a user enters a string that = is not automatically recognized as being "complete", and the user = doesn't press "#", there will be a 4 or 5 second delay between the = time when the last digit is pressed and SIP signaling = begins.

While I realize that this delay is generally undesirable, = I would prefer that there be no requirement to automatically recognize = "end of dialing" for visited emergency = strings.

The flip side of this is that if the ATA's current = dialing plan has an automatically escaped string that is shorter than the visited = emergency number (e.g., an ATA might automatically recognize "00" as a = complete string, and the visited emergency number is "000"), then the = ATA logic needs to stop recognizing "00" as a complete string. I'm = fine with this. The user can then dial "00" (+ timeout) or "00#", and also "000" (+ timeout) or = "000#".

If done this way, the only clashes would be for exact = matches.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: =

1. By default, the = device is set to use the home dialplan
and home emergency numbers, either directly or via
the home provider.
2. If not at home, the device get its location and also
the visited emergency numbers via some means
3. The visited emergency numbers take precendence
over the home dialling plan, if a clash occurs.
(Note: your home provider may provide you with an
escape code to override this, but then you definitely know
what you are doing - e.g. to reach 911xxx local numbers in = UK
if you happen to be in the US.)
Note: this may cause some emergency calls done wrong,
but this is preferrable to missroute some real emergency calls =

*****

The information transmitted is intended = only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon = this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and = delete the material from all computers. 117

------=_NextPart_000_0483_01C62682.76115850-- --===============0369751577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0369751577==-- From ecrit-bounces@ietf.org Tue Jan 31 23:56:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4A2k-0006oS-Ki; Tue, 31 Jan 2006 23:56:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4A2g-0006mP-BF for ecrit@megatron.ietf.org; Tue, 31 Jan 2006 23:56:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07033 for ; Tue, 31 Jan 2006 23:54:44 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ADb-0005ST-41 for ecrit@ietf.org; Wed, 01 Feb 2006 00:07:49 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k114uA6j008740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Jan 2006 23:56:13 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k114u9Ga005195; Tue, 31 Jan 2006 23:56:10 -0500 Message-ID: <43E015D7.3010506@cs.columbia.edu> Date: Tue, 31 Jan 2006 20:58:47 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Issue 30: Summary References: <9888E1AA13C3A1459D122996A58C0E1131BD30@bre2k61p-55> In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BD30@bre2k61p-55> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org While this is an interesting debate, I think we need to recognize that we're worrying about a very small fraction of users, with a likely decrease to zero over time, namely: - overlap dialing (i.e., ATA-style devices rather than mobile) - roaming or using a foreign VSP - likely to be residential rather than office (PBX) use; I just don't see that many businesses deploying a PBX with a foreign VSP (and those businesses are likely to hand-tune their dial plan in any event) I think the most common use of foreign dial plans will be *inbound* calls, e.g., from relatives and friends in the old home country. Since this is indeed a rare case, we need to make sure it works correctly, precisely because visitors, babysitters and the like will have no clue, like Brian noted. However, it is probably less important that these rare emergency calls are delayed by a few seconds. The time-out delay noted seems well within the standard answer delay budget of most PSAPs. On the other hand, given that the owner of the phone is likely to be aware of the special status of the foreign dial plan, I don't see much of a practical problem if he has to dial #9112345 for the rare cases of collision with a local number. Yes, there might be a mistake made and an accidental 911 call placed, but the number of such arrangements will be so small, that it is unlikely to matter. Given that there is no perfect solution, I don't think we need to make a decision on this now; operational experience can dictate whether 911T (timeout) or 911. (immediate) is the right dial plan (or maybe even 911C, where C stands for confirmation). We just need to design discovery protocols that allow for both options. By the time this stuff gets widely deployed, this may be about as relevant as rotary dials. Stark, Barbara wrote: > This seems generally reasonable to me, also. > However, there is an implicit expectation in the description below that > I'm not quite comfortable with, in the "precedence" statement. That is, > whether or not end of dialing string is automatically recognized for > visited emergency numbers. > > For devices that use a "Send" button, this isn't a problem. "Send" must > always be pressed to indicate "end of dialing". For these, there would > be no clash between a US "911" and UK "911xxx" dial string. If the user > enters "911xxx" + "Send", then this must never be interpreted as "911". > Similarly, "911" + "Send" is equally unambiguous (in this example). > > SIP devices without a "Send" button generally employ a variety of > mechanisms to recognize "end of dialing". > 1. Some strings are automatically recognized; for example, when a user > dials any "N11" string and has an ATA configured for US dialing plans, > the ATA recognizes this string and automatically sends the SIP Invite > without waiting any further. > > 2. The user can usually press "#" to indicate end of dialing. Many > users are unaware of this fact. > 3. If the user does not press another digit in 4 or 5 seconds (differs > by device), this is interpreted as end of dialing, and the SIP Invite is > sent. > > What this means, is that, if a user enters a string that is not > automatically recognized as being "complete", and the user doesn't press > "#", there will be a 4 or 5 second delay between the time when the last > digit is pressed and SIP signaling begins. > > While I realize that this delay is generally undesirable, I would prefer > that there be no requirement to automatically recognize "end of dialing" > for visited emergency strings. > > The flip side of this is that if the ATA's current dialing plan has an > automatically escaped string that is shorter than the visited emergency > number (e.g., an ATA might automatically recognize "00" as a complete > string, and the visited emergency number is "000"), then the ATA logic > needs to stop recognizing "00" as a complete string. I'm fine with this. > The user can then dial "00" (+ timeout) or "00#", and also "000" (+ > timeout) or "000#". > > If done this way, the only clashes would be for exact matches. > Barbara > ======================================== > On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: > > 1. By default, the device is set to use the home dialplan > and home emergency numbers, either directly or via > the home provider. > 2. If not at home, the device get its location and also > the visited emergency numbers via some means > 3. The visited emergency numbers take precendence > over the home dialling plan, if a clash occurs. > (Note: your home provider may provide you with an > escape code to override this, but then you definitely know > what you are doing - e.g. to reach 911xxx local numbers in UK > if you happen to be in the US.) > Note: this may cause some emergency calls done wrong, > but this is preferrable to missroute some real emergency calls > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. 117 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit