From ecrit-bounces@ietf.org Thu Jan 03 22:43:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAdSp-0001Jd-6m; Thu, 03 Jan 2008 22:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAdSn-0001JT-Q4 for ecrit@ietf.org; Thu, 03 Jan 2008 22:43:17 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAdSn-0006Cs-G0 for ecrit@ietf.org; Thu, 03 Jan 2008 22:43:17 -0500 Received: from kbe (pool-71-250-50-170.nwrknj.east.verizon.net [71.250.50.170]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m043hF4Z000099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 3 Jan 2008 22:43:16 -0500 (EST) Message-Id: From: Henning Schulzrinne To: ECRIT Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 3 Jan 2008 22:43:15 -0500 X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Ecrit] An alternative to the service URN 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: , Errors-To: ecrit-bounces@ietf.org http://youtube.com/watch?v=BBuo41qYOgw _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 04 08:26:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAmZ5-00019i-UL; Fri, 04 Jan 2008 08:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAmZ4-00019c-Le for ecrit@ietf.org; Fri, 04 Jan 2008 08:26:22 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAmZ4-000282-9B for ecrit@ietf.org; Fri, 04 Jan 2008 08:26:22 -0500 Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m04DQJf28109; Fri, 4 Jan 2008 13:26:19 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] An alternative to the service URN Date: Fri, 4 Jan 2008 13:26:18 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] An alternative to the service URN Thread-Index: AchOg/+sFV8LBT16TA6TzJrz6iR+6gAUCRqw From: "Milan Patel" To: "Henning Schulzrinne" , "ECRIT" X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org Hello Henning, Happy New year to you and all. There is another clip of "the IT crowd" where there is a fire in the office and they email the fire department. http://youtube.com/watch?v=3D6nGjxO_Bfac You'll be happy to hear, they fire service actually arrive at the end of the episode. Best regards, Milan -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 04 January 2008 03:43 To: ECRIT Subject: [Ecrit] An alternative to the service URN http://youtube.com/watch?v=3DBBuo41qYOgw _______________________________________________ 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 07 10:52:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuHC-0002tT-Uc; Mon, 07 Jan 2008 10:52:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuHC-0002tB-Jg for ecrit@ietf.org; Mon, 07 Jan 2008 10:52:34 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBuHC-0002H0-2e for ecrit@ietf.org; Mon, 07 Jan 2008 10:52:34 -0500 Received: (qmail invoked by alias); 07 Jan 2008 15:52:33 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp029) with SMTP; 07 Jan 2008 16:52:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19FmWV4VL5F5aRBpX2H3BpeM8YZqdts479x3cQosm Hrvl4M/xE+8AZ7 Message-ID: <47824ABE.4010802@gmx.net> Date: Mon, 07 Jan 2008 17:52:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT , GEOPRIV Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ecrit] Academic Publications 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: , Errors-To: ecrit-bounces@ietf.org Folks, you might want to consider submitting a paper about your work on location-based services/emergency services to the following workshop: 2nd IEEE Workshop on Mission-Critical Networking (MCN’2008) http://www.criticalnet.org/ Important Dates - Abstract Submission: February 7, 2008 - Paper Submission: February 15, 2008 Ciao Hannes PS: I should also mention that Henning is one of the "General Chairs" and I am one of the "Program Chairs". _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 07 20:14:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC32g-0007a3-85; Mon, 07 Jan 2008 20:14:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC32e-0007Zt-MT; Mon, 07 Jan 2008 20:14:08 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC32e-0003rO-8y; Mon, 07 Jan 2008 20:14:08 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id CACD41075B2; Mon, 7 Jan 2008 17:14:07 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080108011407.CACD41075B2@bosco.isi.edu> Date: Mon, 7 Jan 2008 17:14:07 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 5012 on Requirements for Emergency Context Resolution with Internet Technologies 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: , Errors-To: ecrit-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5012 Title: Requirements for Emergency Context Resolution with Internet Technologies Author: H. Schulzrinne, R. Marshall, Ed. Status: Informational Date: January 2008 Mailbox: hgs+ecrit@cs.columbia.edu, rmarshall@telecomsys.com Pages: 23 Characters: 54599 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-requirements-13.txt URL: http://www.rfc-editor.org/rfc/rfc5012.txt This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end. This memo provides information for the Internet community. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 07 20:14:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC32x-0007ca-Rr; Mon, 07 Jan 2008 20:14:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC32w-0007bu-0b; Mon, 07 Jan 2008 20:14:26 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC32r-0004IA-JW; Mon, 07 Jan 2008 20:14:25 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id 0CF1A1075B4; Mon, 7 Jan 2008 17:14:21 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080108011421.0CF1A1075B4@bosco.isi.edu> Date: Mon, 7 Jan 2008 17:14:21 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 5031 on A Uniform Resource Name (URN) for Emergency and Other Well-Known Services 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: , Errors-To: ecrit-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5031 Title: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services Author: H. Schulzrinne Status: Standards Track Date: January 2008 Mailbox: hgs+ecrit@cs.columbia.edu Pages: 14 Characters: 32960 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-service-urn-07.txt URL: http://www.rfc-editor.org/rfc/rfc5031.txt The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS TRACK] This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 07 20:14:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC334-0007mK-RV; Mon, 07 Jan 2008 20:14:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC333-0007ls-6C; Mon, 07 Jan 2008 20:14:33 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC332-0004IQ-Pi; Mon, 07 Jan 2008 20:14:33 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id 8038B1075B6; Mon, 7 Jan 2008 17:14:32 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080108011432.8038B1075B6@bosco.isi.edu> Date: Mon, 7 Jan 2008 17:14:32 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 5069 on Security Threats and Requirements for Emergency Call Marking and Mapping 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: , Errors-To: ecrit-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5069 Title: Security Threats and Requirements for Emergency Call Marking and Mapping Author: T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam Status: Informational Date: January 2008 Mailbox: tom.taylor@rogers.com, Hannes.Tschofenig@nsn.com, hgs+ecrit@cs.columbia.edu, murugaraj.shanmugam@detecon.com Pages: 12 Characters: 26230 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-security-threats-05.txt URL: http://www.rfc-editor.org/rfc/rfc5069.txt This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 07 23:52:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6Rw-0008HT-3Y; Mon, 07 Jan 2008 23:52:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6Ru-0008HO-Tu for ecrit@ietf.org; Mon, 07 Jan 2008 23:52:26 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC6Ru-0008U7-B4 for ecrit@ietf.org; Mon, 07 Jan 2008 23:52:26 -0500 X-SEF-Processed: 5_0_0_910__2008_01_07_23_03_57 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 07 Jan 2008 23:03:56 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 22:52:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jan 2008 22:52:19 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST schema omission Thread-Index: AchRsj/MZmWlwef/Sie1JoEtrKhzKA== From: "Thomson, Martin" To: "ECRIT" X-OriginalArrivalTime: 08 Jan 2008 04:52:21.0804 (UTC) FILETIME=[4115DEC0:01C851B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Ecrit] LoST schema omission 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="===============1466632921==" Errors-To: ecrit-bounces@ietf.org --===============1466632921== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBqdXN0IGxvYWRlZCB0aGUgTG9TVCBzY2hlbWEgdG8gY2hlY2sgb3V0IGEgZmV3IGV4YW1wbGUg bWVzc2FnZXMuICBCYXNlZCBvbiB0aGUgY29tcGFjdCBzY2hlbWEsIG1vc3Qgb2YgdGhlIGV4YW1w bGUgcmVzcG9uc2VzIGZhaWwgdG8gdmFsaWRhdGUuDQoNClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhl ICJsb2NhdGlvblVzZWQiIGVsZW1lbnQgKGFuZCBhbGwgdGhhdCBpcyByZWxhdGVkIHRvIGl0cyB1 c2UpIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBzY2hlbWEuDQoNCkFzc3VtaW5nIHNvbWUgc29ydCBv ZiBjb25zaXN0ZW5jeSB3aXRoIHRoZSBleGFtcGxlOg0KDQogIDxsb3N0OmxvY2F0aW9uVXNlZCBp ZD0iNjAyMDY4OGYxY2UxODk2ZCIvPg0KDQouLi5hbmQgYXNzdW1pbmcgdGhhdCB5b3UgY2FuIHBy b3ZpZGUgYSBmdWxsIGxvY2F0aW9uIGluIHRoaXMgY29udGV4dCAoYmFzZWQgb24gdGhlIGNsaWVu dCBvbWl0dGluZyB0aGUgImlkIiBhdHRyaWJ1dGUpOg0KDQogIDxsb3N0OmxvY2F0aW9uVXNlZCBw cm9maWxlPSJjaXZpYyI+DQogICAgPGNhOmNpdmljQWRkcmVzcz48Y2E6Y291bnRyeT5BVTwvY2E6 Y291bnRyeT48L2NhOmNpdmljQWRkcmVzcz4NCiAgPC9sb3N0OmxvY2F0aW9uVXNlZD4NCg0KVGhl IGRlZmluaXRpb25zIGZvciBlYWNoIG1lc3NhZ2UgdGhhdCBpbmNsdWRlcyBsb2NhdGlvbiBpbiB0 aGUgcmVxdWVzdCBuZWVkIHRvIGJlIGFtZW5kZWQ6DQoNCmRpdiB7DQogIGZpbmRTZXJ2aWNlUmVz cG9uc2UgPQ0KICAgIGVsZW1lbnQgZmluZFNlcnZpY2VSZXNwb25zZSB7DQorICAgICAgbWFwcGlu ZyssIGxvY2F0aW9uVmFsaWRhdGlvbj8sIGNvbW1vblJlc3BvbnNlUGF0dGVybiwgbG9jYXRpb25V c2VkPw0KLSAgICAgIG1hcHBpbmcrLCBsb2NhdGlvblZhbGlkYXRpb24/LCBjb21tb25SZXNwb25z ZVBhdHRlcm4NCiAgICB9DQogIGxpc3RTZXJ2aWNlc1Jlc3BvbnNlID0NCiAgICBlbGVtZW50IGxp c3RTZXJ2aWNlc1Jlc3BvbnNlIHsgc2VydmljZUxpc3QsIGNvbW1vblJlc3BvbnNlUGF0dGVybiB9 DQogIGxpc3RTZXJ2aWNlc0J5TG9jYXRpb25SZXNwb25zZSA9DQogICAgZWxlbWVudCBsaXN0U2Vy dmljZXNCeUxvY2F0aW9uUmVzcG9uc2Ugew0KKyAgICAgIHNlcnZpY2VMaXN0LCBjb21tb25SZXNw b25zZVBhdHRlcm4sIGxvY2F0aW9uVXNlZD8NCi0gICAgICBzZXJ2aWNlTGlzdCwgY29tbW9uUmVz cG9uc2VQYXR0ZXJuDQogICAgfQ0KICBnZXRTZXJ2aWNlQm91bmRhcnlSZXNwb25zZSA9DQogICAg ZWxlbWVudCBnZXRTZXJ2aWNlQm91bmRhcnlSZXNwb25zZSB7DQogICAgICBzZXJ2aWNlQm91bmRh cnksIGNvbW1vblJlc3BvbnNlUGF0dGVybg0KICAgIH0NCn0NCg0KVGhlbiBhZGQgdGhlIGZvbGxv d2luZzoNCg0KICAjIyBUaGUgbG9jYXRpb24gaW5mb3JtYXRpb24gdXNlZCB0byBnZW5lcmF0ZSB0 aGUgcmVzcG9uc2UgDQogIGRpdiB7DQogICAgbG9jYXRpb25Vc2VkID0gZWxlbWVudCBsb2NhdGlv blVzZWQgew0KICAgICAgYXR0cmlidXRlIGlkIHsgeHNkOk5DTmFtZSB9IHwgbG9jYXRpb25JbmZv cm1hdGlvbg0KICAgIH0NCiAgfQ0KDQpOb3RlIHRoYXQgdGhpcyBhbGxvd3MgZm9yIGVpdGhlciB0 aGUgaWQsIG9yIGFuIGVjaG8gb2YgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpBbHNvLCB0 byB1c2UgdGhlIGlkIHByb3Blcmx5LCB5b3UgbmVlZCB0byByZXBsYWNlIGJvdGggaW5zdGFuY2Vz IG9mICJlbGVtZW50IGxvY2F0aW9uIHsgbG9jYXRpb25JbmZvcm1hdGlvbiB9IiB3aXRoICJsb2Nh dGlvbiIgYW5kIGRlZmluZSBhICJsb2NhdGlvbiIgKGNhcmRpbmFsaXR5IG9mICIrIiBhbmQgIioi IHN0aWxsIGFwcGx5IHdpdGhpbiB0aGUgZGlmZmVyZW50IGNvbnRleHRzKToNCg0KZGl2IHsNCiAg ZmluZFNlcnZpY2UgPQ0KICAgIGVsZW1lbnQgZmluZFNlcnZpY2Ugew0KKyAgICAgIHJlcXVlc3RM b2NhdGlvbiwNCi0gICAgICBlbGVtZW50IGxvY2F0aW9uIHsgbG9jYXRpb25JbmZvcm1hdGlvbiB9 KywNCiAgICAgIGNvbW1vblJlcXVlc3RQYXR0ZXJuLA0KICAgICAgYXR0cmlidXRlIHZhbGlkYXRl TG9jYXRpb24gew0KICAgICAgICB4c2Q6Ym9vbGVhbiA+PiBhOmRlZmF1bHRWYWx1ZSBbICJmYWxz ZSIgXQ0KICAgICAgfT8sDQogICAgICBhdHRyaWJ1dGUgc2VydmljZUJvdW5kYXJ5IHsNCiAgICAg ICAgKCJyZWZlcmVuY2UiIHwgInZhbHVlIikgPj4gYTpkZWZhdWx0VmFsdWUgWyAicmVmZXJlbmNl IiBdDQogICAgICB9PywNCiAgICAgIGF0dHJpYnV0ZSByZWN1cnNpdmUgeyB4c2Q6Ym9vbGVhbiA+ PiBhOmRlZmF1bHRWYWx1ZSBbICJmYWxzZSIgXSB9Pw0KICAgIH0NCiAgbGlzdFNlcnZpY2VzID0g ZWxlbWVudCBsaXN0U2VydmljZXMgeyBjb21tb25SZXF1ZXN0UGF0dGVybiB9DQogIGxpc3RTZXJ2 aWNlc0J5TG9jYXRpb24gPQ0KICAgIGVsZW1lbnQgbGlzdFNlcnZpY2VzQnlMb2NhdGlvbiB7DQor ICAgICAgcmVxdWVzdExvY2F0aW9uLA0KLSAgICAgIGVsZW1lbnQgbG9jYXRpb24geyBsb2NhdGlv bkluZm9ybWF0aW9uIH0qLA0KICAgICAgY29tbW9uUmVxdWVzdFBhdHRlcm4sDQogICAgICBhdHRy aWJ1dGUgcmVjdXJzaXZlIHsgeHNkOmJvb2xlYW4gPj4gYTpkZWZhdWx0VmFsdWUgWyAidHJ1ZSIg XSB9Pw0KICAgIH0NCiAgZ2V0U2VydmljZUJvdW5kYXJ5ID0NCiAgICBlbGVtZW50IGdldFNlcnZp Y2VCb3VuZGFyeSB7IHNlcnZpY2VCb3VuZGFyeUtleSwgZXh0ZW5zaW9uUG9pbnQgfQ0KfQ0KDQpU aGVuIGFkZCB0aGUgZGVmaW5pdGlvbiBhcyBzbzoNCg0KICAjIyBMb2NhdGlvbiwgdXNlZCBieSBm aW5kU2VydmljZSBhbmQgbGlzdFNlcnZpY2VzQnlMb2NhdGlvbg0KICBkaXYgew0KICAgIHJlcXVl c3RMb2NhdGlvbiA9IGVsZW1lbnQgbG9jYXRpb24gew0KICAgICAgYXR0cmlidXRlIGlkIHsgeHNk Ok5DTmFtZSB9PywgbG9jYXRpb25JbmZvcm1hdGlvbg0KICAgIH0rDQogIH0NCg0KKE5vdGU6IEl0 IHNlZW1zIHRoYXQgeW91IGludGVuZGVkIHRvIGhhdmUgdGhlIGNhcmRpbmFsaXR5IG9mIHRoZSBs b2NhdGlvbiBlbGVtZW50IGluICJsaXN0U2VydmljZXNCeUxvY2F0aW9uIiBhcyAxLi5uLCByYXRo ZXIgdGhhbiAwLi5uLiAgVGhlIHRleHQgaW4gU2VjdGlvbiAxMSBzdGF0ZXMgIm9uZSBvciBtb3Jl IDxsb2NhdGlvbj4gZWxlbWVudHMiLiAgSSd2ZSBhc3N1bWVkIHRoYXQgaGVyZSwgaWYgbm90LCB0 aGVuIGFkZCBhIHRyYWlsaW5nICI/IiB0byB0aGUgbGluZSBpbiAibGlzdFNlcnZpY2VzQnlMb2Nh dGlvbiIuKQ0KDQpJIGhhdmVuJ3QgdXNlZCB4c2Q6SUQuICBJdCBtaWdodCBiZSBtb3JlIGFwcHJv cHJpYXRlIHRvIHVzZSB0aGUgSUQgdHlwZSBkZWZpbmVkIGluICJodHRwOi8vcmVsYXhuZy5vcmcv bnMvY29tcGF0aWJpbGl0eS9kYXRhdHlwZXMvMC45IiwgYnV0IHRoYXQgc2VlbXMgYSBsaXR0bGUg dW5kZXItZGVmaW5lZCBiYXNlZCBvbiB3aGF0IEknbSByZWFkaW5nIHJpZ2h0IG5vdy4NCg0KSSBh bHNvIHJlY29tbWVuZCBjaGFuZ2luZyB0aGUgdHlwZSBvZiB0aGUgc2VydmljZSBudW1iZXIgdG8g YmUgYmFzZWQgb24geHNkOnRva2VuIHRvIGFsbG93IGZvciBub24tbWVhbmluZ2Z1bCB3aGl0ZXNw YWNlLiAgQmFzZWQgb24gdGhlIGdpdmVuIHBhdHRlcm4sIHdoaXRlc3BhY2UgaXMgaWxsZWdhbCAo PHNlcnZpY2VOdW1iZXI+IDkxMTwvc2VydmljZU51bWJlcj4gPT0gYmFkLCBmb3IgbW9yZSB0aGFu IG9uZSByZWFzb24pLiAgVGhhdCBpcyB1bmludHVpdGl2ZSwgc28gYSBzbWFsbCBjaGFuZ2UgaXMg YXBwcm9wcmlhdGU6DQoNCiAgICAgIGVsZW1lbnQgc2VydmljZU51bWJlciB7DQogICAgICAgIHhz ZDpzdHJpbmcgeyBwYXR0ZXJuID0gIlswLTkqI10rIiB9DQogICAgICB9PywNCi0+DQogICAgICBl bGVtZW50IHNlcnZpY2VOdW1iZXIgew0KICAgICAgICB4c2Q6dG9rZW4geyBwYXR0ZXJuID0gIlsw LTkqI10rIiB9DQogICAgICB9PywNCg0KVGhlIHNhbWUgZ29lcyBmb3IgIm1lc3NhZ2UiIGFuZCBt YXliZSAiYXBwVW5pcXVlU3RyaW5nIi4gIHhzZDpzdHJpbmcgc2hvdWxkIGJlIHVzZWQgcmFyZWx5 LCB1bmxlc3MgeW91IHBhcnRpY3VsYXJseSBsaWtlIHdoaXRlc3BhY2UgbmlnaHRtYXJlcyAoc2Vl IFsxXSkuDQoNCkNoZWVycywNCk1hcnRpbiANCg0KWzFdIGh0dHA6Ly9ib29rcy54bWxzY2hlbWF0 YS5vcmcvcmVsYXhuZy9yZWxheC1DSFAtNy1TRUNULTYuaHRtbA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0 ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KW21mMl0NCg== --===============1466632921== 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 --===============1466632921==-- From ecrit-bounces@ietf.org Tue Jan 08 03:35:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9vt-0008S2-A8; Tue, 08 Jan 2008 03:35:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9vr-0008Ri-Lf for ecrit@ietf.org; Tue, 08 Jan 2008 03:35:35 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JC9vr-00047Z-6L for ecrit@ietf.org; Tue, 08 Jan 2008 03:35:35 -0500 Received: (qmail invoked by alias); 08 Jan 2008 08:35:33 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp042) with SMTP; 08 Jan 2008 09:35:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19SZzdQeKNSW5x8n+dQSk3DkWp7j/+sninWDwABoa W1/LmPJOwWX/IN Message-ID: <478335D4.60907@gmx.net> Date: Tue, 08 Jan 2008 10:35:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] Finally! RFC 5012, 5031, 5069 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: , Errors-To: ecrit-bounces@ietf.org It is nice to come to office and to see the announcement of http://www.rfc-editor.org/rfc/rfc5012.txt http://www.rfc-editor.org/rfc/rfc5031.txt http://www.rfc-editor.org/rfc/rfc5069.txt Thanks to the group for the hard work. Our other documents are close to completion as well. Let's try to get them done as soon as possible. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 08 11:25:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHGi-0002ri-OW; Tue, 08 Jan 2008 11:25:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHGh-0002qQ-H9 for ecrit@ietf.org; Tue, 08 Jan 2008 11:25:35 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCHGf-0003JK-BM for ecrit@ietf.org; Tue, 08 Jan 2008 11:25:35 -0500 Received: (qmail invoked by alias); 08 Jan 2008 16:25:32 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp032) with SMTP; 08 Jan 2008 17:25:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Q3bt+CymQ9UdOMsse7+XUg4U2EJLNeXTFs0USKS Bq4UhafEuMlKgx Message-ID: <4783A3FB.6050900@gmx.net> Date: Tue, 08 Jan 2008 18:25:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Alain.VAN-GAEVER@ec.europa.eu Subject: [Ecrit] Reform of the EU regulatory framework for electronic communications 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: , Errors-To: ecrit-bounces@ietf.org Recently, I posted a link to the Universal Service Directive. Alain wrote a slide set to explain what it actually means. You can find the slide set here: http://tinyurl.com/2apoqc * *Thank you, Alain. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 14 08:26:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPKi-00073G-0b; Mon, 14 Jan 2008 08:26:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPKg-0006yQ-BU for ecrit@ietf.org; Mon, 14 Jan 2008 08:26:30 -0500 Received: from fg-out-1718.google.com ([72.14.220.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEPKe-00034K-3v for ecrit@ietf.org; Mon, 14 Jan 2008 08:26:30 -0500 Received: by fg-out-1718.google.com with SMTP id 16so2252010fgg.41 for ; Mon, 14 Jan 2008 05:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=wkFb+xMMz2K8SiGaO8TXdoaVScRQ3dbEp9NZeET0Gec=; b=clYB1VD0JI3MmO0H9sQJyOIGrvuViVFrmrpOgiJ7QDAGYNHLcGrfm32Flp9xvbKQoQiHK9ldYwksbZSrg/yTOudNvUvU4lqqF4NjyM91eIxCQsCAWgZyYFaQc7rwBmki75MCftspPRxKwlmv7LXuiUO1+WQ72/Izr1CGEh7/in0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qq4kTBXjfuT2/uh6RI9V9ZH9Pf74eOmMo0y8kbNVL1McuovAKSBivUbOY9gCYlnSD584PieAOu0wQOQZMzmmMDz/ktT4GqiYnmWJHUcCQOBK8iWDXqNp1QQTQ5/zC2Zd+XDH0KxRCFlKY4pbnQgxoiscz3WbGQT/5T5aVOLvjIw= Received: by 10.82.180.17 with SMTP id c17mr10922985buf.14.1200317186785; Mon, 14 Jan 2008 05:26:26 -0800 (PST) Received: by 10.82.182.18 with HTTP; Mon, 14 Jan 2008 05:26:26 -0800 (PST) Message-ID: Date: Mon, 14 Jan 2008 14:26:26 +0100 From: "Karl Heinz Wolf" To: ECRIT MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] Service Boundary and listServicesByLocation 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: , Errors-To: ecrit-bounces@ietf.org I have a question about how a mobile client notices a change of available emergency services when moving. Maybe I've just got something wrong. LoST returns a service boundary for a service when a client does a findService. So the client knows the area, this particular mapping is valid. When a client requests listServicesByLocation, no boundary information is provided telling where this list of services applicable. So, when is a client expected to do a listServicesByLocation query again? For example, the client moves to an area where a mountain rescue service is available, but the listServicesByLocation was done at a location where no mountain rescue is available. Did I read over a rule on when to do a listServicesByLocation? cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 15 09:25:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEmjA-0002fV-Im; Tue, 15 Jan 2008 09:25:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEmj9-0002fP-3w for ecrit@ietf.org; Tue, 15 Jan 2008 09:25:19 -0500 Received: from mu-out-0910.google.com ([209.85.134.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEmj8-0005Mh-In for ecrit@ietf.org; Tue, 15 Jan 2008 09:25:19 -0500 Received: by mu-out-0910.google.com with SMTP id w8so1208784mue.4 for ; Tue, 15 Jan 2008 06:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=z9ha85q0A213ka8nd/gFos8nNGsv+trX4riyQKBHHuU=; b=gppmyO845jAuErbYgfaID+bWIX5tkRJfTkbfPr7pU1dVJmrq/0eWTvTtOb1ZfaQ2CXsH24XuXfbG09m7RrurfGKUsOQy8mX/+2hq7Y981KyzWaEDmr4ifgQDI1MdRAxckSrd49dyXfYgu/9SVfCY7bhWcu+xogeFfy01Z8km7uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=e7WLpX+ctaxGk6w0vmuxWW/5ZIzIQjmVjXScE8CKRycQXStIQ8fQSeZJW1oBrdzER+9oFwR6WnK9BTiQdC3oZwUZncegDngDw+sadYI1M9Cnpm/Jq7EuOQHH5PcgCsy6v46qBuzumDjlp4Ihhwo9hmTTnHEHcGbDPWJbFRy4mpI= Received: by 10.82.108.9 with SMTP id g9mr13199515buc.34.1200407116047; Tue, 15 Jan 2008 06:25:16 -0800 (PST) Received: by 10.82.182.18 with HTTP; Tue, 15 Jan 2008 06:25:15 -0800 (PST) Message-ID: Date: Tue, 15 Jan 2008 15:25:15 +0100 From: "Karl Heinz Wolf" To: ECRIT MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] Services with same Service Number 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: , Errors-To: ecrit-bounces@ietf.org I tried the LoST Server implementation available at: http://honamsun.cs.columbia.edu/lost_homepage/ I did a listServicesByLocation and then requested a mapping for all the services with the sample US location. What confuses me is the fact, that there are different services all with the same service number 911 (but different SIP URIs). A user is expected to dial the service number in case of emergency, in this case 911. Which service should the client choose then? sos.police, sos.poison? By the way: I looked at listServices and listServicesByLocation (Section 10 and 11 in the lost draft). The listServicesByLocation explicitly says that the LoST server returns only child services. In the section above, listServices, this is not noted (but the examples just show child services). Is this intended? cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 15 15:39:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsZA-0007rJ-7g; Tue, 15 Jan 2008 15:39:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsZ9-0007rD-D7 for ecrit@ietf.org; Tue, 15 Jan 2008 15:39:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEsZ8-0005hj-VU for ecrit@ietf.org; Tue, 15 Jan 2008 15:39:23 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2008 12:39:22 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0FKdMDL021990; Tue, 15 Jan 2008 12:39:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0FKd5iZ028145; Tue, 15 Jan 2008 20:39:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 12:39:09 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.92.183]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 12:39:09 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jan 2008 14:39:08 -0600 To: "Karl Heinz Wolf" , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Services with same Service Number In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jan 2008 20:39:09.0244 (UTC) FILETIME=[ADD98FC0:01C857B6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1867; t=1200429562; x=1201293562; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Services=20with=20same=20Serv ice=20Number |Sender:=20; bh=rtznmhAJ66mVrtK4aiLufmuKcLCoJ7HywflKgZvfI/I=; b=hXPa+eCR2Sk2S5kdZdprJE/YPUeSSBNoDCviylvlRMZYRhNVMo03zBIOJu o+oTHxIc4fxo9vBFxw1J4Bb6WbtVuSyxn/nA88sJ7mUcPwmg7FA8PnOCSTrh qA5ibVwZTB; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ecrit-bounces@ietf.org Karl If I understand your question correctly, dialing 911 in the US doesn't separate police from fire from several other services -- all these types of calls (save for some like the suicide hotline and poison) are answered by the same call center within a geopraphic area, and the call taker decides where to direct the call (i.e., to the police, or to the fire department or to an ambulance or mountain rescue or emergency forest service). This is pretty universal within the US. There are no (that I know of) 3 digit dial-strings for poison centers or suicide hotlines. Each of these is at least 7 digits long, and sometimes 10 digits long (if an area requires an area code before each 7 digit number). Again, I may have misunderstood what you are asking Hope this helps James At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote: >I tried the LoST Server implementation available at: > >http://honamsun.cs.columbia.edu/lost_homepage/ > >I did a listServicesByLocation and then requested a mapping for all >the services with the sample US location. What confuses me is the >fact, that there are different services all with the same service >number 911 (but different SIP URIs). >A user is expected to dial the service number in case of emergency, in >this case 911. Which service should the client choose then? >sos.police, sos.poison? > >By the way: I looked at listServices and listServicesByLocation >(Section 10 and 11 in the lost draft). The listServicesByLocation >explicitly says that the LoST server returns only child services. In >the section above, listServices, this is not noted (but the examples >just show child services). Is this intended? > >cheers >karl heinz > >_______________________________________________ >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 15 16:53:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtj5-00079j-U8; Tue, 15 Jan 2008 16:53:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtj5-00079c-44 for ecrit@ietf.org; Tue, 15 Jan 2008 16:53:43 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEtj4-0007Zj-F0 for ecrit@ietf.org; Tue, 15 Jan 2008 16:53:43 -0500 Received: from Rockford9@aol.com by imo-d22.mx.aol.com (mail_out_v38_r9.3.) id c.c26.27f5a825 (29673); Tue, 15 Jan 2008 16:53:17 -0500 (EST) From: Rockford9@aol.com Message-ID: Date: Tue, 15 Jan 2008 16:53:17 EST Subject: Re: [Ecrit] Services with same Service Number To: jmpolk@cisco.com, khwolf1@gmail.com, ecrit@ietf.org MIME-Version: 1.0 X-Mailer: Unknown sub 34 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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="===============1922175934==" Errors-To: ecrit-bounces@ietf.org --===============1922175934== Content-Type: multipart/alternative; boundary="-----------------------------1200433997" -------------------------------1200433997 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Clarifying regarding the two examples (suicide hotline and poison centers), in US, they are 800-type 10-digit numbers which are routed to appropriate state/regional/local center (when possible). Rick Jones In a message dated 1/15/2008 2:39:48 P.M. Central Standard Time, jmpolk@cisco.com writes: Karl If I understand your question correctly, dialing 911 in the US doesn't separate police from fire from several other services -- all these types of calls (save for some like the suicide hotline and poison) are answered by the same call center within a geopraphic area, and the call taker decides where to direct the call (i.e., to the police, or to the fire department or to an ambulance or mountain rescue or emergency forest service). This is pretty universal within the US. There are no (that I know of) 3 digit dial-strings for poison centers or suicide hotlines. Each of these is at least 7 digits long, and sometimes 10 digits long (if an area requires an area code before each 7 digit number). Again, I may have misunderstood what you are asking Hope this helps James At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote: >I tried the LoST Server implementation available at: > >http://honamsun.cs.columbia.edu/lost_homepage/ > >I did a listServicesByLocation and then requested a mapping for all >the services with the sample US location. What confuses me is the >fact, that there are different services all with the same service >number 911 (but different SIP URIs). >A user is expected to dial the service number in case of emergency, in >this case 911. Which service should the client choose then? >sos.police, sos.poison? > >By the way: I looked at listServices and listServicesByLocation >(Section 10 and 11 in the lost draft). The listServicesByLocation >explicitly says that the LoST server returns only child services. In >the section above, listServices, this is not noted (but the examples >just show child services). Is this intended? > >cheers >karl heinz > >_______________________________________________ >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 **************Start the year off right. Easy ways to stay in shape. http://body.aol.com/fitness/winter-exercise?NCID=aolcmp00300000002489 -------------------------------1200433997 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Clarifying regarding the two examples (suicide hotline and poison cente= rs),=20 in US, they are 800-type 10-digit numbers which are routed to appropriate=20 state/regional/local center (when possible).
 
Rick Jones
 
In a message dated 1/15/2008 2:39:48 P.M. Central Standard Time,=20 jmpolk@cisco.com writes:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>Karl

If I understand your question correctly, dialing 911=20= in the=20 US
doesn't separate police from fire from several other services -- al= l=20
these types of calls (save for some like the suicide hotline and=20
poison) are answered by the same call center within a geopraphic
a= rea,=20 and the call taker decides where to direct the call (i.e., to
the poli= ce,=20 or to the fire department or to an ambulance or mountain
rescue or=20 emergency forest service).  This is pretty universal within
the U= S.=20 There are no (that I know of) 3 digit dial-strings for poison
centers=20= or=20 suicide hotlines. Each of these is at least 7 digits long,
and sometim= es=20 10 digits long (if an area requires an area code before
each 7 digit=20 number).

Again, I may have misunderstood what you are=20 asking

Hope this helps

James

At 08:25 AM 1/15/2008, K= arl=20 Heinz Wolf wrote:
>I tried the LoST Server implementation available=20 at:
>
>http://honamsun.cs.columbia.edu/lost_homepage/
><= BR>>I=20 did a listServicesByLocation and then requested a mapping for all
>t= he=20 services with the sample US location. What confuses me is the
>fact,= =20 that there are different services all with the same service
>number=20= 911=20 (but different SIP URIs).
>A user is expected to dial the service nu= mber=20 in case of emergency, in
>this case 911. Which service should the cl= ient=20 choose then?
>sos.police, sos.poison?
>
>By the way: I=20 looked at listServices and listServicesByLocation
>(Section 10 and 1= 1 in=20 the lost draft). The listServicesByLocation
>explicitly says that th= e=20 LoST server returns only child services. In
>the section above,=20 listServices, this is not noted (but the examples
>just show child=20 services). Is this intended?
>
>cheers
>karl=20 heinz
>
>_______________________________________________
&g= t;Ecrit=20 mailing=20 list
>Ecrit@ietf.org
>https://www1.ietf.org/mailman/listinfo/e= crit


_______________________________________________
Ecrit=20 mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
=



Start= the year off right. Easy ways to stay in s= hape in the new year.
-------------------------------1200433997-- --===============1922175934== 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 --===============1922175934==-- From ecrit-bounces@ietf.org Tue Jan 15 17:44:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEuWF-0006yn-RB; Tue, 15 Jan 2008 17:44:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEuWE-0006yi-Ta for ecrit@ietf.org; Tue, 15 Jan 2008 17:44:31 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEuW9-00009O-OU for ecrit@ietf.org; Tue, 15 Jan 2008 17:44:30 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JEuW1-0006f5-GM; Tue, 15 Jan 2008 16:44:18 -0600 From: "Brian Rosen" To: , , , References: Subject: RE: [Ecrit] Services with same Service Number Date: Tue, 15 Jan 2008 17:44:19 -0500 Message-ID: <024e01c857c8$2d6182a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchXwRc5e4BWlwLKSNCrV8LTtWkzTwABsBwA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 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="===============1428061473==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1428061473== Content-Type: multipart/alternative; boundary="----=_NextPart_000_024F_01C8579E.448B7AA0" This is a multi-part message in MIME format. ------=_NextPart_000_024F_01C8579E.448B7AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, but there is no reason we could not map the 800 number into a service URN and then route based on location to the correct suicide hotline or poison control center. The exact same strategy could be used to call Pizza Hut using LoST to route the call to the correct pizza parlor. Lost should be able to return the 800 number as the dial string for the service. It's not clear to me that the endpoint would do the mapping for such a service. Brian _____ From: Rockford9@aol.com [mailto:Rockford9@aol.com] Sent: Tuesday, January 15, 2008 4:53 PM To: jmpolk@cisco.com; khwolf1@gmail.com; ecrit@ietf.org Subject: Re: [Ecrit] Services with same Service Number Clarifying regarding the two examples (suicide hotline and poison centers), in US, they are 800-type 10-digit numbers which are routed to appropriate state/regional/local center (when possible). Rick Jones In a message dated 1/15/2008 2:39:48 P.M. Central Standard Time, jmpolk@cisco.com writes: Karl If I understand your question correctly, dialing 911 in the US doesn't separate police from fire from several other services -- all these types of calls (save for some like the suicide hotline and poison) are answered by the same call center within a geopraphic area, and the call taker decides where to direct the call (i.e., to the police, or to the fire department or to an ambulance or mountain rescue or emergency forest service). This is pretty universal within the US. There are no (that I know of) 3 digit dial-strings for poison centers or suicide hotlines. Each of these is at least 7 digits long, and sometimes 10 digits long (if an area requires an area code before each 7 digit number). Again, I may have misunderstood what you are asking Hope this helps James At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote: >I tried the LoST Server implementation available at: > >http://honamsun.cs.columbia.edu/lost_homepage/ > >I did a listServicesByLocation and then requested a mapping for all >the services with the sample US location. What confuses me is the >fact, that there are different services all with the same service >number 911 (but different SIP URIs). >A user is expected to dial the service number in case of emergency, in >this case 911. Which service should the client choose then? >sos.police, sos.poison? > >By the way: I looked at listServices and listServicesByLocation >(Section 10 and 11 in the lost draft). The listServicesByLocation >explicitly says that the LoST server returns only child services. In >the section above, listServices, this is not noted (but the examples >just show child services). Is this intended? > >cheers >karl heinz > >_______________________________________________ >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 _____ Start the year off right. Easy ways to stay in shape in the new year. ------=_NextPart_000_024F_01C8579E.448B7AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, but there is no reason we = could not map the 800 number into a service URN and then route based on location = to the correct suicide hotline or poison control center.  The exact same = strategy could be used to call Pizza Hut using LoST to route the call to the = correct pizza parlor.

Lost should be able to return the = 800 number as the dial string for the service.  It’s not clear to = me that the endpoint would do the mapping for such a = service.

 

Brian

 

From: Rockford9@aol.com [mailto:Rockford9@aol.com]
Sent: Tuesday, January = 15, 2008 4:53 PM
To: jmpolk@cisco.com; khwolf1@gmail.com; ecrit@ietf.org
Subject: Re: [Ecrit] = Services with same Service Number

 

Clarifying regarding the two = examples (suicide hotline and poison centers), in US, they are 800-type 10-digit = numbers which are routed to appropriate state/regional/local center (when = possible).

 

=

Rick = Jones

 

=

In a message dated 1/15/2008 = 2:39:48 P.M. Central Standard Time, jmpolk@cisco.com = writes:

Karl

If I understand your question correctly, dialing 911 in the US
doesn't separate police from fire from several other services -- all =
these types of calls (save for some like the suicide hotline and
poison) are answered by the same call center within a geopraphic
area, and the call taker decides where to direct the call (i.e., to
the police, or to the fire department or to an ambulance or mountain =
rescue or emergency forest service).  This is pretty universal = within
the US. There are no (that I know of) 3 digit dial-strings for poison
centers or suicide hotlines. Each of these is at least 7 digits long, =
and sometimes 10 digits long (if an area requires an area code before =
each 7 digit number).

Again, I may have misunderstood what you are asking

Hope this helps

James

At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote:
>I tried the LoST Server implementation available at:
>
>http://honamsun.cs.columbia.edu/lost_homepage/
>
>I did a listServicesByLocation and then requested a mapping for = all
>the services with the sample US location. What confuses = me is the
>fact, that there are different services all with the same = service
>number 911 (but different SIP URIs).
>A user is expected to dial the service number in case of emergency, = in
>this case 911. Which service should the client choose then?
>sos.police, sos.poison?
>
>By the way: I looked at listServices and listServicesByLocation
>(Section 10 and 11 in the lost draft). The = listServicesByLocation
>explicitly says that the LoST server returns only child services. = In
>the section above, listServices, this is not noted (but the = examples
>just show child services). Is this intended?
>
>cheers
>karl heinz
>
>_______________________________________________
>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

=



Start the year off right. Easy ways to stay in shape in the new year.

------=_NextPart_000_024F_01C8579E.448B7AA0-- --===============1428061473== 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 --===============1428061473==-- From ecrit-bounces@ietf.org Wed Jan 16 02:31:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF2kV-0007Ao-Ri; Wed, 16 Jan 2008 02:31:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF2kU-0007Ag-Bj for ecrit@ietf.org; Wed, 16 Jan 2008 02:31:46 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF2kT-00077b-Mm for ecrit@ietf.org; Wed, 16 Jan 2008 02:31:46 -0500 Received: by fg-out-1718.google.com with SMTP id 16so179175fgg.41 for ; Tue, 15 Jan 2008 23:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jS081JRb062jdQSPwbRXcVVEEdpo2P+SV2ECcrW5Bpw=; b=spCBqGiaMfC7wxdNOFXe1dh9GJQLRbnPdYp/e3regBfnyQxclzjfHdBwj4HALg/rbxycVCoSs594S13b5ac3cqyUI39xwiTNDURNHMLnNLCuePNV9tSE0BUrS32B2kG4+3uXmv1wbL1OvpL34sdLE+Pz2ojFbCDqJj4WnM0ZqDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IFMuSf6pEvDl7GGp3W+qM63I6Ee7FTkLNpIv2YNziSU2eaohA3G3J/r1QYUMi6PbDUZ773vqZgv+rkaEEYh6x+276Jxwf5TgX2Rc0gtZYqso5KiMVPA+/eqg2XNzfdSXhl7O5mAcXGw0EF6A9MkHIDM4y82EZ9KtOeSfiPkOufI= Received: by 10.82.148.7 with SMTP id v7mr863684bud.10.1200468704271; Tue, 15 Jan 2008 23:31:44 -0800 (PST) Received: by 10.82.182.18 with HTTP; Tue, 15 Jan 2008 23:31:44 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 08:31:44 +0100 From: "Karl Heinz Wolf" To: "James M. Polk" Subject: Re: [Ecrit] Services with same Service Number In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org James, thank you for your answer. I expected the US 911 service to work as you explained it to me. So I expected that a US LoST server would just return a service:sos URN and not separate child service URNs with different SIP URIs and same service number as in the example LoST server http://honamsun.cs.columbia.edu/lost_homepage/ If you use the client on this web page it returns: for police: North Carolian Police Dept. urn:service:sos.police sip:police_nc@irt.cs.columbia.edu 911 for fire: North Carolian Fire Dept. urn:service:sos.fire sip:fire_nc@irt.cs.columbia.edu 911 and so on, all with service Number 911. So that is what confuses me. When I dial 911 now, where should the call go now? One more question: should a country, that has separate services also provision a urn:service:sos in the LoST server or just child services? cheers karl heinz On Jan 15, 2008 9:39 PM, James M. Polk wrote: > Karl > > If I understand your question correctly, dialing 911 in the US > doesn't separate police from fire from several other services -- all > these types of calls (save for some like the suicide hotline and > poison) are answered by the same call center within a geopraphic > area, and the call taker decides where to direct the call (i.e., to > the police, or to the fire department or to an ambulance or mountain > rescue or emergency forest service). This is pretty universal within > the US. There are no (that I know of) 3 digit dial-strings for poison > centers or suicide hotlines. Each of these is at least 7 digits long, > and sometimes 10 digits long (if an area requires an area code before > each 7 digit number). > > Again, I may have misunderstood what you are asking > > Hope this helps > > James > > > At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote: > >I tried the LoST Server implementation available at: > > > >http://honamsun.cs.columbia.edu/lost_homepage/ > > > >I did a listServicesByLocation and then requested a mapping for all > >the services with the sample US location. What confuses me is the > >fact, that there are different services all with the same service > >number 911 (but different SIP URIs). > >A user is expected to dial the service number in case of emergency, in > >this case 911. Which service should the client choose then? > >sos.police, sos.poison? > > > >By the way: I looked at listServices and listServicesByLocation > >(Section 10 and 11 in the lost draft). The listServicesByLocation > >explicitly says that the LoST server returns only child services. In > >the section above, listServices, this is not noted (but the examples > >just show child services). Is this intended? > > > >cheers > >karl heinz > > > >_______________________________________________ > >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 16 03:41:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3q3-00086x-Cj; Wed, 16 Jan 2008 03:41:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3q2-00086q-RI for ecrit@ietf.org; Wed, 16 Jan 2008 03:41:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF3q0-00089d-RF for ecrit@ietf.org; Wed, 16 Jan 2008 03:41:34 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2008 00:41:32 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0G8fWNO003446; Wed, 16 Jan 2008 00:41:32 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0G8fSiZ025007; Wed, 16 Jan 2008 08:41:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 00:41:29 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.92.183]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 00:41:28 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jan 2008 02:41:27 -0600 To: "Karl Heinz Wolf" From: "James M. Polk" Subject: Re: [Ecrit] Services with same Service Number In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jan 2008 08:41:29.0061 (UTC) FILETIME=[9664D150:01C8581B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4939; t=1200472892; x=1201336892; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Services=20with=20same=20Serv ice=20Number |Sender:=20; bh=EJyTlGz8gDY8SA4455J6H0Q9+bz9iiOTI4fQzYg17aQ=; b=Gd82Fg6kcGlrrkIkXP2KCY3UgmRB2iSAZbysqSgvzc90xb2Z7cb0Qgqdz3 o1UtnkYbtsbx1UcWmAYdynb/jegh9b7/lTinZ+8aSkgVgmAhY0DKsFTv4yrA nKKBBzdDX5; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org Karl [stating this as an individual, which should be redundant here] To the question: where should a 911 call get routed to? The answer in the US at least, is the PSAP, with the (trained) call taker deciding which service or services need to be engaged. For example, where there are child services (as you call them), if you get in an auto accident, which service do you call, the police or fire or ambulance/medical? A PSAP can get more than one to the scene of the accident with a single call. Other locations employing child services may necessitate one call per service. After all, as much as all of us believe we should have the right to call who we want to call, sometimes we're not the best educated on who the call should go to; whereas a trained PSAP call-taker can make perhaps a better decision about how many different services ought to take part in providing help. To the question about each country employing a single service or multiple services, that's up to each country. But I think a lot of this answer depends on the social behaviors of that country's citizens. Making a change in what people are expected to do to a critical service can have some dire consequences until that behavior is learned throughout a country. Conversely, limiting multiple choices down to one may frustrate citizens thinking they are being deprived of the right to call who they want to call directly. This question does not have an engineering answer/solution - it is a social answer/solution to what that country's public will accept in a reasonable amount of time. James At 01:31 AM 1/16/2008, Karl Heinz Wolf wrote: >James, > >thank you for your answer. I expected the US 911 service to work as >you explained it to me. So I expected that a US LoST server would just >return a service:sos URN and not separate child service URNs with >different SIP URIs and same service number as in the example LoST >server http://honamsun.cs.columbia.edu/lost_homepage/ >If you use the client on this web page it returns: > >for police: > >North Carolian Police Dept. >urn:service:sos.police >sip:police_nc@irt.cs.columbia.edu >911 > >for fire: > >North Carolian Fire Dept. >urn:service:sos.fire >sip:fire_nc@irt.cs.columbia.edu >911 > >and so on, all with service Number 911. >So that is what confuses me. When I dial 911 now, where should the >call go now? > >One more question: should a country, that has separate services also >provision a urn:service:sos in the LoST server or just child services? > >cheers >karl heinz > > >On Jan 15, 2008 9:39 PM, James M. Polk wrote: > > Karl > > > > If I understand your question correctly, dialing 911 in the US > > doesn't separate police from fire from several other services -- all > > these types of calls (save for some like the suicide hotline and > > poison) are answered by the same call center within a geopraphic > > area, and the call taker decides where to direct the call (i.e., to > > the police, or to the fire department or to an ambulance or mountain > > rescue or emergency forest service). This is pretty universal within > > the US. There are no (that I know of) 3 digit dial-strings for poison > > centers or suicide hotlines. Each of these is at least 7 digits long, > > and sometimes 10 digits long (if an area requires an area code before > > each 7 digit number). > > > > Again, I may have misunderstood what you are asking > > > > Hope this helps > > > > James > > > > > > At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote: > > >I tried the LoST Server implementation available at: > > > > > >http://honamsun.cs.columbia.edu/lost_homepage/ > > > > > >I did a listServicesByLocation and then requested a mapping for all > > >the services with the sample US location. What confuses me is the > > >fact, that there are different services all with the same service > > >number 911 (but different SIP URIs). > > >A user is expected to dial the service number in case of emergency, in > > >this case 911. Which service should the client choose then? > > >sos.police, sos.poison? > > > > > >By the way: I looked at listServices and listServicesByLocation > > >(Section 10 and 11 in the lost draft). The listServicesByLocation > > >explicitly says that the LoST server returns only child services. In > > >the section above, listServices, this is not noted (but the examples > > >just show child services). Is this intended? > > > > > >cheers > > >karl heinz > > > > > >_______________________________________________ > > >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 16 05:07:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5Ao-0005or-VI; Wed, 16 Jan 2008 05:07:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5Ao-0005om-Cc for ecrit@ietf.org; Wed, 16 Jan 2008 05:07:06 -0500 Received: from fg-out-1718.google.com ([72.14.220.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF5Am-0001X5-CH for ecrit@ietf.org; Wed, 16 Jan 2008 05:07:06 -0500 Received: by fg-out-1718.google.com with SMTP id 16so226199fgg.41 for ; Wed, 16 Jan 2008 02:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tkfZk5WEhWPO5e6ChVMsC3+OmCgcDioe0twUs1Ygt6w=; b=HaKkiV1k0/j4MTXrvPitXCMGt8JrRHOMfIFF5rsJpZEUnewBziES4qr73Rg6eQzxHdStRYjhkPy5GoX4g6/OQ2a7fby1ZHeL9F9sbh7b2niMrgjIHnnvjridzCn2Rs/b3TmCNZyysgKoTBdGM3zZk973qA9fhHYo4tNnwDBetn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OGb1V7yWtNWZtpOI8Koo3f5uB7qTZamX8WqLDxR9Uwpgh91Sy8DKmLIKDZabM83qWNJH6PSQdiU+xOK5siTGIAOzZtq33XgjWVJKHNf0StPD8fOBZZFXokSZujBADq4tgwcZJ1YaNYGG6/AprflGGFIU2PTwofizSDCloXnQFvA= Received: by 10.82.121.15 with SMTP id t15mr1073208buc.26.1200478022809; Wed, 16 Jan 2008 02:07:02 -0800 (PST) Received: by 10.82.182.18 with HTTP; Wed, 16 Jan 2008 02:07:02 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 11:07:02 +0100 From: "Karl Heinz Wolf" To: "James M. Polk" Subject: Re: [Ecrit] Services with same Service Number In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org Hi James, thank you again for your quick reply. I'm sorry, but you misunderstood my question. Taking your car accident example: you start you SIP client, it does location determination and service discovery and gets: for police: North Carolian Police Dept. urn:service:sos.police sip:police_nc@irt.cs.columbia.edu 911 for fire: North Carolian Fire Dept. urn:service:sos.fire sip:fire_nc@irt.cs.columbia.edu 911 now the user dials 911 as usual. Now what should the client do? Call the police SIP URI or the Fire SIP URI? Concerning the question: must a service:sos entry always exist in every LoST database even though the country just uses child-services police, fire, ambulance, ...? I do not want to change the number of existing services in countries, but is it allowed that a LoST server returns an error for service:sos because just service:sos.police .fire and .ambulance is provisioned or should service:sos result in a mapping (to what service then?). Thanks for help and I hope I explained my (implementation related) question understandable! cheers karl heinz On Jan 16, 2008 9:41 AM, James M. Polk wrote: > Karl > > [stating this as an individual, which should be redundant here] > > To the question: where should a 911 call get routed to? The answer in > the US at least, is the PSAP, with the (trained) call taker deciding > which service or services need to be engaged. For example, where > there are child services (as you call them), if you get in an auto > accident, which service do you call, the police or fire or > ambulance/medical? A PSAP can get more than one to the scene of the > accident with a single call. Other locations employing child > services may necessitate one call per service. After all, as much as > all of us believe we should have the right to call who we want to > call, sometimes we're not the best educated on who the call should go > to; whereas a trained PSAP call-taker can make perhaps a better > decision about how many different services ought to take part in > providing help. > > To the question about each country employing a single service or > multiple services, that's up to each country. But I think a lot of > this answer depends on the social behaviors of that country's > citizens. Making a change in what people are expected to do to a > critical service can have some dire consequences until that behavior > is learned throughout a country. Conversely, limiting multiple > choices down to one may frustrate citizens thinking they are being > deprived of the right to call who they want to call directly. This > question does not have an engineering answer/solution - it is a > social answer/solution to what that country's public will accept in a > reasonable amount of time. > > James > > > At 01:31 AM 1/16/2008, Karl Heinz Wolf wrote: > >James, > > > >thank you for your answer. I expected the US 911 service to work as > >you explained it to me. So I expected that a US LoST server would just > >return a service:sos URN and not separate child service URNs with > >different SIP URIs and same service number as in the example LoST > >server http://honamsun.cs.columbia.edu/lost_homepage/ > >If you use the client on this web page it returns: > > > >for police: > > > >North Carolian Police Dept. > >urn:service:sos.police > >sip:police_nc@irt.cs.columbia.edu > >911 > > > >for fire: > > > >North Carolian Fire Dept. > >urn:service:sos.fire > >sip:fire_nc@irt.cs.columbia.edu > >911 > > > >and so on, all with service Number 911. > >So that is what confuses me. When I dial 911 now, where should the > >call go now? > > > >One more question: should a country, that has separate services also > >provision a urn:service:sos in the LoST server or just child services? > > > >cheers > >karl heinz > > > > > >On Jan 15, 2008 9:39 PM, James M. Polk wrote: > > > Karl > > > > > > If I understand your question correctly, dialing 911 in the US > > > doesn't separate police from fire from several other services -- all > > > these types of calls (save for some like the suicide hotline and > > > poison) are answered by the same call center within a geopraphic > > > area, and the call taker decides where to direct the call (i.e., to > > > the police, or to the fire department or to an ambulance or mountain > > > rescue or emergency forest service). This is pretty universal within > > > the US. There are no (that I know of) 3 digit dial-strings for poison > > > centers or suicide hotlines. Each of these is at least 7 digits long, > > > and sometimes 10 digits long (if an area requires an area code before > > > each 7 digit number). > > > > > > Again, I may have misunderstood what you are asking > > > > > > Hope this helps > > > > > > James > > > > > > > > > At 08:25 AM 1/15/2008, Karl Heinz Wolf wrote: > > > >I tried the LoST Server implementation available at: > > > > > > > >http://honamsun.cs.columbia.edu/lost_homepage/ > > > > > > > >I did a listServicesByLocation and then requested a mapping for all > > > >the services with the sample US location. What confuses me is the > > > >fact, that there are different services all with the same service > > > >number 911 (but different SIP URIs). > > > >A user is expected to dial the service number in case of emergency, in > > > >this case 911. Which service should the client choose then? > > > >sos.police, sos.poison? > > > > > > > >By the way: I looked at listServices and listServicesByLocation > > > >(Section 10 and 11 in the lost draft). The listServicesByLocation > > > >explicitly says that the LoST server returns only child services. In > > > >the section above, listServices, this is not noted (but the examples > > > >just show child services). Is this intended? > > > > > > > >cheers > > > >karl heinz > > > > > > > >_______________________________________________ > > > >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 16 05:46:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5mX-0001JY-IV; Wed, 16 Jan 2008 05:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5mW-0001JK-LU for ecrit@ietf.org; Wed, 16 Jan 2008 05:46:04 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF5mU-0002HU-Fm for ecrit@ietf.org; Wed, 16 Jan 2008 05:46:04 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUQ009MCGKPYT@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 16 Jan 2008 02:46:01 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUQ00A86GKK1S@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 16 Jan 2008 02:46:01 -0800 (PST) Date: Wed, 16 Jan 2008 04:45:24 -0600 From: Spencer Dawkins Subject: Re: [Ecrit] Services with same Service Number To: ECRIT Message-id: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: ecrit-bounces@ietf.org FWIW, I have the same question that Karl has. I understand that in some places, people expect to be able to call a more specific service directly, but they need to dial a different number to reach that service, don't they? You guys are the experts, but if a country has > North Carolian PSAP > urn:service:sos > sip:psap@irt.cs.columbia.edu > 911 > North Carolian Police Dept. > urn:service:sos.police > sip:police_nc@irt.cs.columbia.edu > 911 > North Carolian Fire Dept. > urn:service:sos.fire > sip:fire_nc@irt.cs.columbia.edu > 911 I'm not seeing how "911" should go anywhere except urn:service:sos, and if a country has both urn:service:sos.police and urn:service:sos.fire with serviceNumber 911, and does not have urn:service:sos with serviceNumber 911, I'm not seeing how the client can choose between the two services with the same serviceNumber. Is this obvious to everyone except me? Thanks Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 08:05:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7xS-0001AI-G7; Wed, 16 Jan 2008 08:05:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7xR-0001AD-0m for ecrit@ietf.org; Wed, 16 Jan 2008 08:05:29 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF7xQ-00054H-GD for ecrit@ietf.org; Wed, 16 Jan 2008 08:05:29 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JF7xt-0000pD-TR; Wed, 16 Jan 2008 07:05:58 -0600 From: "Brian Rosen" To: "'Spencer Dawkins'" , "'ECRIT'" References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 08:05:25 -0500 Message-ID: <030d01c85840$772d2e20$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: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYLRNDL+5L9UH3Sp6KABjetqLIMAAEjqBw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Errors-To: ecrit-bounces@ietf.org I think a country which only had a single emergency number would not normally list individual services. It would only list the single sos service. However, if it did, it would list all services with the single number as the service number as well as the sos service. That shouldn't cause any confusion at the endpoint. Generally, because of 1-1-2, every country has SOME service that responds to 1-1-2 even if they don't really have a single emergency number system. That would be the service whose URI was in sos. I don't see the problem. Every country SHOULD have an sos service. A country that has a single number emergency system normally SHOULD NOT list other services, but if it does, it uses the single emergency number and the single PSAP URI for all of the services. A country that does not have a single emergency number still should list an sos service with some URI and service number, and MUST list their services with their service numbers and URIs. Brian > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Wednesday, January 16, 2008 5:45 AM > To: ECRIT > Subject: Re: [Ecrit] Services with same Service Number > > FWIW, I have the same question that Karl has. I understand that in some > places, people expect to be able to call a more specific service directly, > but they need to dial a different number to reach that service, don't > they? > > You guys are the experts, but if a country has > > > North Carolian PSAP > > urn:service:sos > > sip:psap@irt.cs.columbia.edu > > 911 > > > North Carolian Police Dept. > > urn:service:sos.police > > sip:police_nc@irt.cs.columbia.edu > > 911 > > > North Carolian Fire Dept. > > urn:service:sos.fire > > sip:fire_nc@irt.cs.columbia.edu > > 911 > > I'm not seeing how "911" should go anywhere except > urn:service:sos, and if a country has both > > urn:service:sos.police and > urn:service:sos.fire > > with serviceNumber 911, and does not have > > urn:service:sos > > with serviceNumber 911, I'm not seeing how the client can choose between > the > two services with the same serviceNumber. > > Is this obvious to everyone except me? > > Thanks > > Spencer > > > > _______________________________________________ > 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 16 09:59:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9jU-0006Py-V6; Wed, 16 Jan 2008 09:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9jU-0006Pt-3q for ecrit@ietf.org; Wed, 16 Jan 2008 09:59:12 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF9jS-0008On-8k for ecrit@ietf.org; Wed, 16 Jan 2008 09:59:12 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUQ008UDSAL5U@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 16 Jan 2008 06:59:09 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUQ004DQSAJ9N@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 16 Jan 2008 06:59:09 -0800 (PST) Date: Wed, 16 Jan 2008 08:58:34 -0600 From: Spencer Dawkins Subject: Re: [Ecrit] Services with same Service Number To: 'ECRIT' Message-id: <186601c85850$44a57060$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com> <030d01c85840$772d2e20$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: ecrit-bounces@ietf.org Hi, Brian, Thanks for the feedback. >I think a country which only had a single emergency number would not > normally list individual services. It would only list the single sos > service. > > However, if it did, it would list all services with the single number as > the > service number as well as the sos service. That shouldn't cause any > confusion at the endpoint. > > Generally, because of 1-1-2, every country has SOME service that responds > to > 1-1-2 even if they don't really have a single emergency number system. > That > would be the service whose URI was in sos. OK so far... > I don't see the problem. Every country SHOULD have an sos service. A > country that has a single number emergency system normally SHOULD NOT list > other services, but if it does, it uses the single emergency number and > the > single PSAP URI for all of the services. A country that does not have a > single emergency number still should list an sos service with some URI and > service number, and MUST list their services with their service numbers > and > URIs. I'm with you up to this point. In the problem I thought Karl was raising, he used these examples: >> > North Carolian Police Dept. >> > urn:service:sos.police >> > sip:police_nc@irt.cs.columbia.edu >> > 911 >> >> > North Carolian Fire Dept. >> > urn:service:sos.fire >> > sip:fire_nc@irt.cs.columbia.edu >> > 911 which use the same serviceNumber and DIFFERENT uris for multiple services. What happens then? I have some thoughts but someone else probably has clearer thoughts. Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 10:34:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAHb-0001Gu-4L; Wed, 16 Jan 2008 10:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAHZ-0001Gl-V2 for ecrit@ietf.org; Wed, 16 Jan 2008 10:34:25 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFAHZ-0000iL-Ch for ecrit@ietf.org; Wed, 16 Jan 2008 10:34:25 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFAI1-0008Br-U4; Wed, 16 Jan 2008 09:34:54 -0600 From: "Brian Rosen" To: "'Spencer Dawkins'" , "'ECRIT'" References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 10:34:21 -0500 Message-ID: <033f01c85855$46111c10$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: <186601c85850$44a57060$6601a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYUHQwRgdu3er1RmCOJJeIj4Ql6gAAa7Mg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: , Errors-To: ecrit-bounces@ietf.org Right, I see the problem; since we have no priority or precedence of services, if the user enters "9-1-1", what URI should be used? The answer is of course urn:service:sos, but we don't have anything that says that anywhere. We have two options: 1. Disallow the circumstance; two services can't have the same service number 2. Specify priority somehow Let's think through the cases: 1. The U.S. case works with 1), and if we specified sos has priority, then it would work with 2) 2. The German case. 1-1-2 is fire/ems, 1-1-0 is police. So, police would have a different service number and URI, fire/ems would have the same uri and the same service number. Priority wouldn't really matter; whether you used 1-1-2 for fire or 1-1-2 for sos, it works. 3. The French case. Police is 1-7, medical has "more severe - 1-5, less severe 1-8", and Fire is 1-8. 1-1-2 is answered by 1-5 or 1-8 in different parts of the country. This works without priority, because all of the services have different service numbers and uris and sos has it's own service number and a uri that overlaps with 1-5 or 1-8 depending on location. Go look at: http://en.wikipedia.org/wiki/Emergency_telephone_number and see if you can spot a problem with making sos have more priority than any subservice when the sos dial code is re-used for a specific service. Brian > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Wednesday, January 16, 2008 9:59 AM > To: 'ECRIT' > Subject: Re: [Ecrit] Services with same Service Number > > Hi, Brian, > > Thanks for the feedback. > > > >I think a country which only had a single emergency number would not > > normally list individual services. It would only list the single sos > > service. > > > > However, if it did, it would list all services with the single number as > > the > > service number as well as the sos service. That shouldn't cause any > > confusion at the endpoint. > > > > Generally, because of 1-1-2, every country has SOME service that > responds > > to > > 1-1-2 even if they don't really have a single emergency number system. > > That > > would be the service whose URI was in sos. > > OK so far... > > > I don't see the problem. Every country SHOULD have an sos service. A > > country that has a single number emergency system normally SHOULD NOT > list > > other services, but if it does, it uses the single emergency number and > > the > > single PSAP URI for all of the services. A country that does not have a > > single emergency number still should list an sos service with some URI > and > > service number, and MUST list their services with their service numbers > > and > > URIs. > > I'm with you up to this point. In the problem I thought Karl was raising, > he > used these examples: > > >> > North Carolian Police Dept. > >> > urn:service:sos.police > >> > sip:police_nc@irt.cs.columbia.edu > >> > 911 > >> > >> > North Carolian Fire Dept. > >> > urn:service:sos.fire > >> > sip:fire_nc@irt.cs.columbia.edu > >> > 911 > > which use the same serviceNumber and DIFFERENT uris for multiple services. > > What happens then? I have some thoughts but someone else probably has > clearer thoughts. > > Spencer > > > > _______________________________________________ > 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 16 12:03:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBfa-0001IH-JQ; Wed, 16 Jan 2008 12:03:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFBfZ-0001IC-Em for ecrit@ietf.org; Wed, 16 Jan 2008 12:03:17 -0500 Received: from wolverine01.qualcomm.com ([199.106.114.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFBfY-0002Nv-I5 for ecrit@ietf.org; Wed, 16 Jan 2008 12:03:17 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:Date:To:From:Subject: Content-Type; b=tyLd8/ojZ5PwYo/8rbZQDRheAm2topdRUZDXrWYUqLONiGSirrhO3E4l oDlEd/ENOuv74bBu7/2t+eJo9/70poN/Sv12cyZsINWKfTDeH5cSPKpQm 4365dECZ5CckUQjSlvF4vz0YsEZvsw2oBsOhzV/ZfCqE0sDciYrsgXAXa U=; X-IronPort-AV: E=McAfee;i="5100,188,5208"; a="560938" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2008 09:03:15 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0GH3EZP012728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jan 2008 09:03:15 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0GH3Cc3000607; Wed, 16 Jan 2008 09:03:13 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <033f01c85855$46111c10$640fa8c0@cis.neustar.com> References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com> <033f01c85855$46111c10$640fa8c0@cis.neustar.com> Date: Wed, 16 Jan 2008 09:03:11 -0800 To: "Brian Rosen" , "'Spencer Dawkins'" , "'ECRIT'" From: Ted Hardie Subject: RE: [Ecrit] Services with same Service Number Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Errors-To: ecrit-bounces@ietf.org At 10:34 AM -0500 1/16/08, Brian Rosen wrote: >Right, I see the problem; since we have no priority or precedence of >services, if the user enters "9-1-1", what URI should be used? > >The answer is of course urn:service:sos, but we don't have anything that >says that anywhere. > >We have two options: >1. Disallow the circumstance; two services can't have the same service >number >2. Specify priority somehow I think we're heading off into some tall, tall weeds here. Let's back up a step. The base case is this: a client presents a LoST server with a specific service URN and a location. It sends back a set of URIs, commonly including a SIP URI, which will be used to reach the service responders. It also gets back a service number. That's used *in cases where the client cannot invoke the protocols associated with the URIs directly*. In the case where the client got a SIP URI, and has a SIP stack, it uses SIP. If it didn't need voice and got an SMS URI, it might use SMS. If it does not have a SIP stack, it may use the service number. But in that case, there *is no guarantee it is being routed to the same PSAP as it would have reached with a known locality*; it gets routed to whatever its circuit-switched routing takes it. It likely can't even send along the location with that invocation. This is a fallback or "additional info" that a user might find handy the next they are near this location and calling from some less-capable device like a payphone (not that there are many of those any more). It should never take precedence over a locality-informed URI. I hope that is clear enough to everyone. I think "listServices", which is where we started this discussion, may be somewhat confusing because you see all at once that the match between URIs and service numbers may not one-to-one (and, based on jurisidictional choices, it can be interesting in lots of ways), but the influence of location on specific results is opaque. But that query shouldn't take the place of the actual LoST query and results processing. Start from *that* context, and work outward to listServices, and I believe it gets a lot clearer fast. regards, Ted >Let's think through the cases: >1. The U.S. case works with 1), and if we specified sos has priority, then >it would work with 2) >2. The German case. 1-1-2 is fire/ems, 1-1-0 is police. So, police would >have a different service number and URI, fire/ems would have the same uri >and the same service number. Priority wouldn't really matter; whether you >used 1-1-2 for fire or 1-1-2 for sos, it works. >3. The French case. Police is 1-7, medical has "more severe - 1-5, less >severe 1-8", and Fire is 1-8. 1-1-2 is answered by 1-5 or 1-8 in different >parts of the country. This works without priority, because all of the >services have different service numbers and uris and sos has it's own >service number and a uri that overlaps with 1-5 or 1-8 depending on >location. > > >Go look at: >http://en.wikipedia.org/wiki/Emergency_telephone_number > >and see if you can spot a problem with making sos have more priority than >any subservice when the sos dial code is re-used for a specific service. > >Brian > >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >> Sent: Wednesday, January 16, 2008 9:59 AM >> To: 'ECRIT' >> Subject: Re: [Ecrit] Services with same Service Number >> >> Hi, Brian, >> >> Thanks for the feedback. >> >> >> >I think a country which only had a single emergency number would not >> > normally list individual services. It would only list the single sos >> > service. >> > >> > However, if it did, it would list all services with the single number as >> > the >> > service number as well as the sos service. That shouldn't cause any >> > confusion at the endpoint. >> > >> > Generally, because of 1-1-2, every country has SOME service that >> responds >> > to >> > 1-1-2 even if they don't really have a single emergency number system. > > > That >> > would be the service whose URI was in sos. >> >> OK so far... >> >> > I don't see the problem. Every country SHOULD have an sos service. A >> > country that has a single number emergency system normally SHOULD NOT >> list >> > other services, but if it does, it uses the single emergency number and >> > the >> > single PSAP URI for all of the services. A country that does not have a >> > single emergency number still should list an sos service with some URI >> and >> > service number, and MUST list their services with their service numbers >> > and >> > URIs. >> >> I'm with you up to this point. In the problem I thought Karl was raising, >> he >> used these examples: >> >> >> > North Carolian Police Dept. >> >> > urn:service:sos.police >> >> > sip:police_nc@irt.cs.columbia.edu >> >> > 911 >> >> >> >> > North Carolian Fire Dept. >> >> > urn:service:sos.fire >> >> > sip:fire_nc@irt.cs.columbia.edu >> >> > 911 >> >> which use the same serviceNumber and DIFFERENT uris for multiple services. >> >> What happens then? I have some thoughts but someone else probably has >> clearer thoughts. >> >> Spencer >> >> >> >> _______________________________________________ >> 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 Wed Jan 16 12:58:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCX5-0003Wa-SP; Wed, 16 Jan 2008 12:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCX4-0003M1-Rt for ecrit@ietf.org; Wed, 16 Jan 2008 12:58:34 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFCX3-0005hI-Rd for ecrit@ietf.org; Wed, 16 Jan 2008 12:58:34 -0500 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.192928056; Wed, 16 Jan 2008 12:58:14 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 16 Jan 2008 12:58:14 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 16 Jan 2008 12:58:14 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Services with same Service Number Date: Wed, 16 Jan 2008 12:58:13 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number thread-index: AchYYfYnvDQwPXwWRSiCVXUkA7Ir1AABdZ5Q References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Ted Hardie" , "Brian Rosen" , "Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 16 Jan 2008 17:58:14.0522 (UTC) FILETIME=[5D99A5A0:01C85869] X-Spam-Score: 0.2 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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: , Errors-To: ecrit-bounces@ietf.org Hmmm. No, I don't think it's about the ability of the client to invoke services. It's about the methods the user uses to invoke services. Users dial digits. The main purpose of the service number was for dialed digit string recognition, for backward compatibility with existing ways that people currently signal "Connect me with emergency services". That is, they pick up the phone (SIP or not) and dial 9-1-1, 1-1-2, 0-0-0, or whatever string that they think should connect them with the help they need.=20 The device sees that the user dialed "9-1-1", and sees that this string is one of the stings returned by LoST (or otherwise configured). The device now needs exactly one service urn and route uri to associate with that string, to create a properly formed SIP INVITE (per phonebcp), if it uses SIP. If it has more than one, then it needs precise rules for selecting one. I think this is what Brian said. And I agree with Brian. Barbara -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com]=20 Sent: Wednesday, January 16, 2008 12:03 PM To: Brian Rosen; 'Spencer Dawkins'; 'ECRIT' Subject: RE: [Ecrit] Services with same Service Number At 10:34 AM -0500 1/16/08, Brian Rosen wrote: >Right, I see the problem; since we have no priority or precedence of >services, if the user enters "9-1-1", what URI should be used? > >The answer is of course urn:service:sos, but we don't have anything that >says that anywhere. > >We have two options: >1. Disallow the circumstance; two services can't have the same service >number >2. Specify priority somehow I think we're heading off into some tall, tall weeds here. Let's back up a step. The base case is this: a client presents a LoST server with a specific service URN and a location. It sends back a set of URIs, commonly including a SIP URI, which will be used to reach the service responders. It also gets back a service number. That's used *in cases where the client cannot invoke the protocols associated with the URIs directly*. In the case where the client got a SIP URI, and has a SIP stack, it uses SIP. If it didn't need voice and got an SMS URI, it might use SMS. =20 If it does not have a SIP stack, it may use the service number. But in that case, there *is no guarantee it is being routed to the same PSAP as it would have reached with a known locality*; it gets routed to whatever its circuit-switched routing takes it. It likely can't even send along the location with that invocation. This is a fallback or "additional info" that a user might find handy the next they are near this location and calling from some less-capable device like a payphone (not that there are many of those any more). It should never take precedence over a locality-informed URI. I hope that is clear enough to everyone.=20 I think "listServices", which is where we started this discussion, may be somewhat confusing because you see all at once that the match between URIs and service numbers may not one-to-one (and, based on jurisidictional choices, it can be interesting in lots of ways), but the influence of location on specific results is opaque. But that query shouldn't take the place of the actual LoST query and results processing. Start from *that* context, and work outward to listServices, and I believe it gets a lot clearer fast. regards, Ted >Let's think through the cases: >1. The U.S. case works with 1), and if we specified sos has priority, then >it would work with 2) >2. The German case. 1-1-2 is fire/ems, 1-1-0 is police. So, police would >have a different service number and URI, fire/ems would have the same uri >and the same service number. Priority wouldn't really matter; whether you >used 1-1-2 for fire or 1-1-2 for sos, it works. >3. The French case. Police is 1-7, medical has "more severe - 1-5, less >severe 1-8", and Fire is 1-8. 1-1-2 is answered by 1-5 or 1-8 in different >parts of the country. This works without priority, because all of the >services have different service numbers and uris and sos has it's own >service number and a uri that overlaps with 1-5 or 1-8 depending on >location. > > >Go look at: >http://en.wikipedia.org/wiki/Emergency_telephone_number > >and see if you can spot a problem with making sos have more priority than >any subservice when the sos dial code is re-used for a specific service. > >Brian > >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >> Sent: Wednesday, January 16, 2008 9:59 AM >> To: 'ECRIT' >> Subject: Re: [Ecrit] Services with same Service Number >> >> Hi, Brian, >> >> Thanks for the feedback. >> >> >> >I think a country which only had a single emergency number would not >> > normally list individual services. It would only list the single sos >> > service. >> > >> > However, if it did, it would list all services with the single number as >> > the >> > service number as well as the sos service. That shouldn't cause any >> > confusion at the endpoint. >> > >> > Generally, because of 1-1-2, every country has SOME service that >> responds >> > to >> > 1-1-2 even if they don't really have a single emergency number system. > > > That >> > would be the service whose URI was in sos. >> >> OK so far... >> >> > I don't see the problem. Every country SHOULD have an sos service. A >> > country that has a single number emergency system normally SHOULD NOT >> list >> > other services, but if it does, it uses the single emergency number and >> > the >> > single PSAP URI for all of the services. A country that does not have a >> > single emergency number still should list an sos service with some URI >> and >> > service number, and MUST list their services with their service numbers >> > and >> > URIs. >> >> I'm with you up to this point. In the problem I thought Karl was raising, >> he >> used these examples: >> >> >> > North Carolian Police Dept. >> >> > urn:service:sos.police >> >> > sip:police_nc@irt.cs.columbia.edu >> >> > 911 >> >> >> >> > North Carolian Fire Dept. >> >> > urn:service:sos.fire >> >> > sip:fire_nc@irt.cs.columbia.edu >> >> > 911 >> >> which use the same serviceNumber and DIFFERENT uris for multiple services. >> >> What happens then? I have some thoughts but someone else probably has >> clearer thoughts. >> >> Spencer >> >> >> >> _______________________________________________ >> 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 ***** 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. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 13:05:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCdQ-0004b9-KA; Wed, 16 Jan 2008 13:05:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCdO-0004b4-T3 for ecrit@ietf.org; Wed, 16 Jan 2008 13:05:06 -0500 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 1JFCdN-0005on-Fb for ecrit@ietf.org; Wed, 16 Jan 2008 13:05:06 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2008 10:05:05 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0GI54bB013322; Wed, 16 Jan 2008 10:05:04 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0GI54iX010910; Wed, 16 Jan 2008 18:05:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 10:05:04 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.89.83]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 10:05:03 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jan 2008 12:05:02 -0600 To: "Brian Rosen" , "'Spencer Dawkins'" , "'ECRIT'" From: "James M. Polk" Subject: RE: [Ecrit] Services with same Service Number In-Reply-To: <033f01c85855$46111c10$640fa8c0@cis.neustar.com> References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com> <030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com> <033f01c85855$46111c10$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jan 2008 18:05:04.0107 (UTC) FILETIME=[51BB5BB0:01C8586A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6023; t=1200506704; x=1201370704; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Services=20with=20same=20Serv ice=20Number |Sender:=20; bh=638N32KBg7bd94nOZ81oskdMdDp+unLDHxcSepD8dMM=; b=AuxJXzKg/JpDNS2ehHEHz7b5r0DMHwm52MD08R6yKNUyzpwtxdG4dI4H+5 bbkSwhhQhnlPfYdWssiCXhkMgS/xew5tF4rnQMwlAlk3Pk98xkMa84uKR2bc WjDeYkn01t; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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: , Errors-To: ecrit-bounces@ietf.org Karl I understand your question better. I think Brian's explanation is best for the question you ask. But I will add this (mostly as a restatement of Brian's comments): Ultimately, if a SIP UA gets a single service number back (from LoST) from a single service URN, it can only contact that single service destination. If, in your example, LoST returns more than one service with the *same* service number, this would lead to confusion unless your SIP UA has some form of configuration and/or priority of which to use first (if the user dials 911, from your example, the first URI used is police). Determining the URI priority of which to use (i.e., configuring the UA) has not been addressed yet, and might not be within the IETF, as I personally believe this is a local jurisdiction issue - which will have different outcomes based on the number of roaming/nomadic UAs wondering into each area that has different priorities/expected configurations (but this is really getting into Ted's tall weeds! So I'll stop this line of thought). That said, your example has different URIs for each service - which can each be initiated with different INVITEs for different/multiple dialogs concurrently (if the UA can do this - which could end up as a 3-way call to both the fire and police departments, with the UA as the media mixer). In your example, I don't think North Carolina would give back separate URIs (one each for fire and police), but would give back a single URI to an ESRP (at the border of the ESInet) or the PSAP (which would direct the call to whomever they believe should be contacted to best serve the UA's situation). In a country that has multiple URIs (returnable by LoST), each with different service numbers, a UA would likely call one URI at a time (with different child URNs or different service numbers), and everything works as predicted here. I hope I didn't confuse Brian's explanation with what I've added. James At 09:34 AM 1/16/2008, Brian Rosen wrote: >Right, I see the problem; since we have no priority or precedence of >services, if the user enters "9-1-1", what URI should be used? > >The answer is of course urn:service:sos, but we don't have anything that >says that anywhere. > >We have two options: >1. Disallow the circumstance; two services can't have the same service >number >2. Specify priority somehow > >Let's think through the cases: >1. The U.S. case works with 1), and if we specified sos has priority, then >it would work with 2) >2. The German case. 1-1-2 is fire/ems, 1-1-0 is police. So, police would >have a different service number and URI, fire/ems would have the same uri >and the same service number. Priority wouldn't really matter; whether you >used 1-1-2 for fire or 1-1-2 for sos, it works. >3. The French case. Police is 1-7, medical has "more severe - 1-5, less >severe 1-8", and Fire is 1-8. 1-1-2 is answered by 1-5 or 1-8 in different >parts of the country. This works without priority, because all of the >services have different service numbers and uris and sos has it's own >service number and a uri that overlaps with 1-5 or 1-8 depending on >location. > > >Go look at: >http://en.wikipedia.org/wiki/Emergency_telephone_number > >and see if you can spot a problem with making sos have more priority than >any subservice when the sos dial code is re-used for a specific service. > >Brian > > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > Sent: Wednesday, January 16, 2008 9:59 AM > > To: 'ECRIT' > > Subject: Re: [Ecrit] Services with same Service Number > > > > Hi, Brian, > > > > Thanks for the feedback. > > > > > > >I think a country which only had a single emergency number would not > > > normally list individual services. It would only list the single sos > > > service. > > > > > > However, if it did, it would list all services with the single number as > > > the > > > service number as well as the sos service. That shouldn't cause any > > > confusion at the endpoint. > > > > > > Generally, because of 1-1-2, every country has SOME service that > > responds > > > to > > > 1-1-2 even if they don't really have a single emergency number system. > > > That > > > would be the service whose URI was in sos. > > > > OK so far... > > > > > I don't see the problem. Every country SHOULD have an sos service. A > > > country that has a single number emergency system normally SHOULD NOT > > list > > > other services, but if it does, it uses the single emergency number and > > > the > > > single PSAP URI for all of the services. A country that does not have a > > > single emergency number still should list an sos service with some URI > > and > > > service number, and MUST list their services with their service numbers > > > and > > > URIs. > > > > I'm with you up to this point. In the problem I thought Karl was raising, > > he > > used these examples: > > > > >> > North Carolian Police Dept. > > >> > urn:service:sos.police > > >> > sip:police_nc@irt.cs.columbia.edu > > >> > 911 > > >> > > >> > North Carolian Fire Dept. > > >> > urn:service:sos.fire > > >> > sip:fire_nc@irt.cs.columbia.edu > > >> > 911 > > > > which use the same serviceNumber and DIFFERENT uris for multiple services. > > > > What happens then? I have some thoughts but someone else probably has > > clearer thoughts. > > > > Spencer > > > > > > > > _______________________________________________ > > 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 Wed Jan 16 13:25:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCx2-0004rr-Be; Wed, 16 Jan 2008 13:25:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCx1-0004rP-FV for ecrit@ietf.org; Wed, 16 Jan 2008 13:25:23 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFCx0-0004UR-G8 for ecrit@ietf.org; Wed, 16 Jan 2008 13:25:23 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFCwy-0008RE-8G; Wed, 16 Jan 2008 12:25:21 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Ted Hardie'" , "'Spencer Dawkins'" , "'ECRIT'" References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 13:25:17 -0500 Message-ID: <03c001c8586d$2742ade0$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: <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYYfYnvDQwPXwWRSiCVXUkA7Ir1AABdZ5QAAFUl+A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 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: , Errors-To: ecrit-bounces@ietf.org What she said. Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Wednesday, January 16, 2008 12:58 PM > To: Ted Hardie; Brian Rosen; Spencer Dawkins; ECRIT > Subject: RE: [Ecrit] Services with same Service Number > > Hmmm. No, I don't think it's about the ability of the client to invoke > services. It's about the methods the user uses to invoke services. Users > dial digits. The main purpose of the service number was for dialed digit > string recognition, for backward compatibility with existing ways that > people currently signal "Connect me with emergency services". That is, > they pick up the phone (SIP or not) and dial 9-1-1, 1-1-2, 0-0-0, or > whatever string that they think should connect them with the help they > need. > > The device sees that the user dialed "9-1-1", and sees that this string > is one of the stings returned by LoST (or otherwise configured). The > device now needs exactly one service urn and route uri to associate with > that string, to create a properly formed SIP INVITE (per phonebcp), if > it uses SIP. If it has more than one, then it needs precise rules for > selecting one. I think this is what Brian said. And I agree with Brian. > Barbara > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, January 16, 2008 12:03 PM > To: Brian Rosen; 'Spencer Dawkins'; 'ECRIT' > Subject: RE: [Ecrit] Services with same Service Number > > At 10:34 AM -0500 1/16/08, Brian Rosen wrote: > >Right, I see the problem; since we have no priority or precedence of > >services, if the user enters "9-1-1", what URI should be used? > > > >The answer is of course urn:service:sos, but we don't have anything > that > >says that anywhere. > > > >We have two options: > >1. Disallow the circumstance; two services can't have the same service > >number > >2. Specify priority somehow > > I think we're heading off into some tall, tall weeds here. Let's back > up > a step. The base case is this: a client presents a LoST server with a > specific > service URN and a location. It sends back a set of URIs, commonly > including > a SIP URI, which will be used to reach the service responders. It also > gets back a service number. That's used *in cases where the client > cannot > invoke the protocols associated with the URIs directly*. In the case > where the client got a SIP URI, and has a SIP stack, it uses SIP. If it > didn't need voice and got an SMS URI, it might use SMS. > > If it does not have a SIP stack, it may use the service number. But in > that > case, there *is no guarantee it is being routed to the same PSAP as it > would > have reached with a known locality*; it gets routed to whatever its > circuit-switched > routing takes it. It likely can't even send along the location with > that > invocation. This is a fallback or "additional info" that a user might > find handy > the next they are near this location and calling from some less-capable > device like a payphone (not that there are many of those any more). It > should never take precedence over a locality-informed URI. > > I hope that is clear enough to everyone. > > I think "listServices", which is where we started this discussion, may > be somewhat > confusing because you see all at once that the match between URIs and > service > numbers may not one-to-one (and, based on jurisidictional choices, it > can be interesting > in lots of ways), but the influence of location on specific results is > opaque. > But that query shouldn't take the place of the actual LoST query and > results processing. Start from *that* context, and work outward to > listServices, and > I believe it gets a lot clearer fast. > > regards, > Ted > > > > > > > >Let's think through the cases: > >1. The U.S. case works with 1), and if we specified sos has priority, > then > >it would work with 2) > >2. The German case. 1-1-2 is fire/ems, 1-1-0 is police. So, police > would > >have a different service number and URI, fire/ems would have the same > uri > >and the same service number. Priority wouldn't really matter; whether > you > >used 1-1-2 for fire or 1-1-2 for sos, it works. > >3. The French case. Police is 1-7, medical has "more severe - 1-5, > less > >severe 1-8", and Fire is 1-8. 1-1-2 is answered by 1-5 or 1-8 in > different > >parts of the country. This works without priority, because all of the > >services have different service numbers and uris and sos has it's own > >service number and a uri that overlaps with 1-5 or 1-8 depending on > >location. > > > > > >Go look at: > >http://en.wikipedia.org/wiki/Emergency_telephone_number > > > >and see if you can spot a problem with making sos have more priority > than > >any subservice when the sos dial code is re-used for a specific > service. > > > >Brian > > > >> -----Original Message----- > >> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > >> Sent: Wednesday, January 16, 2008 9:59 AM > >> To: 'ECRIT' > >> Subject: Re: [Ecrit] Services with same Service Number > >> > >> Hi, Brian, > >> > >> Thanks for the feedback. > >> > >> > >> >I think a country which only had a single emergency number would not > >> > normally list individual services. It would only list the single > sos > >> > service. > >> > > >> > However, if it did, it would list all services with the single > number as > >> > the > >> > service number as well as the sos service. That shouldn't cause > any > >> > confusion at the endpoint. > >> > > >> > Generally, because of 1-1-2, every country has SOME service that > >> responds > >> > to > >> > 1-1-2 even if they don't really have a single emergency number > system. > > > > That > >> > would be the service whose URI was in sos. > >> > >> OK so far... > >> > >> > I don't see the problem. Every country SHOULD have an sos service. > A > >> > country that has a single number emergency system normally SHOULD > NOT > >> list > >> > other services, but if it does, it uses the single emergency number > and > >> > the > >> > single PSAP URI for all of the services. A country that does not > have a > >> > single emergency number still should list an sos service with some > URI > >> and > >> > service number, and MUST list their services with their service > numbers > >> > and > >> > URIs. > >> > >> I'm with you up to this point. In the problem I thought Karl was > raising, > >> he > >> used these examples: > >> > >> >> > North Carolian Police > Dept. > >> >> > urn:service:sos.police > >> >> > sip:police_nc@irt.cs.columbia.edu > >> >> > 911 > >> >> > >> >> > North Carolian Fire > Dept. > >> >> > urn:service:sos.fire > >> >> > sip:fire_nc@irt.cs.columbia.edu > >> >> > 911 > >> > >> which use the same serviceNumber and DIFFERENT uris for multiple > services. > >> > >> What happens then? I have some thoughts but someone else probably has > >> clearer thoughts. > >> > >> Spencer > >> > >> > >> > >> _______________________________________________ > >> 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 > > ***** > > 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. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 13:26:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCy3-0005PR-3K; Wed, 16 Jan 2008 13:26:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCy1-0005Oz-Ux for ecrit@ietf.org; Wed, 16 Jan 2008 13:26:25 -0500 Received: from wolverine02.qualcomm.com ([199.106.114.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFCxz-00068V-HQ for ecrit@ietf.org; Wed, 16 Jan 2008 13:26:25 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:Date:To:From:Subject: Content-Type; b=w+UGVuR/guJwx9OobHJBG11NKLErEA0nhx64o095R7oU9W+rxPKedRLW JbqJcBb5QJTQl8V/Vynsgrh9ecVykuChwuS+z0Y7e294hSo+TcQKN8Zzy 7yNJHvNU1YYK4eP4oVtzzmFC2gXAhITJsl2E38z3ZeeILDm7vaSxD9xvy k=; X-IronPort-AV: E=McAfee;i="5100,188,5209"; a="560598" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2008 10:26:22 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0GIQM34025418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jan 2008 10:26:22 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0GIQL5L019657; Wed, 16 Jan 2008 10:26:21 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$64 0fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> Date: Wed, 16 Jan 2008 10:26:19 -0800 To: "Stark, Barbara" , "Brian Rosen" , "Spencer Dawkins" , "ECRIT" From: Ted Hardie Subject: RE: [Ecrit] Services with same Service Number Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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: , Errors-To: ecrit-bounces@ietf.org At 12:58 PM -0500 1/16/08, Stark, Barbara wrote: >Hmmm. No, I don't think it's about the ability of the client to invoke >services. It's about the methods the user uses to invoke services. Users >dial digits. The main purpose of the service number was for dialed digit >string recognition, for backward compatibility with existing ways that >people currently signal "Connect me with emergency services". That is, >they pick up the phone (SIP or not) and dial 9-1-1, 1-1-2, 0-0-0, or >whatever string that they think should connect them with the help they >need. >The device sees that the user dialed "9-1-1", and sees that this string >is one of the stings returned by LoST (or otherwise configured). I think you have the mapping wrong. The 911 string dialed by the user is the UI invocation; it's the 3-button equivalent of the big red button that says "call for help" in jurisdictions that have a single response view of the world. If LoST had not been previously run, I would expect it to cause LoST to take the location of the device and a service urn of sos (unadorned, since 911 is general). It should then get back a set of URIs and a service number. Presuming that the device can use one of those URIs, it would then invoke the protocol processing associated with the URI scheme (SIP, in the examples we've been discussing). If it cannot, then it might use the service Number to create a circuit switched call. That circuit switched call might be to 112. As "additional data" in a phone with sufficient power, it might also return to the user the information "dialing local emergency response at 112", so the user knows it can invoke local emergency response. When the user next dials 112, them implementation would do exactly the same thing as it did with 911, only the service number and invocation string would happen to match. Again, this is the base case. If the phone pre-loads LoST information and gets mappings beyond those for which the user knows invocation UI methods, it might in some cases create them. That might be a drop down list, a voice prompt (now press one for fire, two for police, three for medical emergencies, or stay on the line) or something else. It might also add the service numbers to a list of patterns in looks for as invocations of emergency services (since an invocation results in the same device behavior whether the invocation string matches the resulting service number or not, this is okay). But if it pre-loads this information by *replacing* the invocation string 911 with 112 because of local data on the service number, it has not done anyone any favors. regards, Ted > The >device now needs exactly one service urn and route uri to associate with >that string, to create a properly formed SIP INVITE (per phonebcp), if >it uses SIP. If it has more than one, then it needs precise rules for >selecting one. I think this is what Brian said. And I agree with Brian. >Barbara > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Wednesday, January 16, 2008 12:03 PM >To: Brian Rosen; 'Spencer Dawkins'; 'ECRIT' >Subject: RE: [Ecrit] Services with same Service Number > >At 10:34 AM -0500 1/16/08, Brian Rosen wrote: >>Right, I see the problem; since we have no priority or precedence of >>services, if the user enters "9-1-1", what URI should be used? >> >>The answer is of course urn:service:sos, but we don't have anything >that >>says that anywhere. >> >>We have two options: >>1. Disallow the circumstance; two services can't have the same service >>number >>2. Specify priority somehow > >I think we're heading off into some tall, tall weeds here. Let's back >up >a step. The base case is this: a client presents a LoST server with a >specific >service URN and a location. It sends back a set of URIs, commonly >including >a SIP URI, which will be used to reach the service responders. It also >gets back a service number. That's used *in cases where the client >cannot >invoke the protocols associated with the URIs directly*. In the case >where the client got a SIP URI, and has a SIP stack, it uses SIP. If it >didn't need voice and got an SMS URI, it might use SMS. > >If it does not have a SIP stack, it may use the service number. But in >that >case, there *is no guarantee it is being routed to the same PSAP as it >would >have reached with a known locality*; it gets routed to whatever its >circuit-switched >routing takes it. It likely can't even send along the location with >that >invocation. This is a fallback or "additional info" that a user might >find handy >the next they are near this location and calling from some less-capable >device like a payphone (not that there are many of those any more). It >should never take precedence over a locality-informed URI. > >I hope that is clear enough to everyone. > >I think "listServices", which is where we started this discussion, may >be somewhat >confusing because you see all at once that the match between URIs and >service >numbers may not one-to-one (and, based on jurisidictional choices, it >can be interesting >in lots of ways), but the influence of location on specific results is >opaque. >But that query shouldn't take the place of the actual LoST query and >results processing. Start from *that* context, and work outward to >listServices, and >I believe it gets a lot clearer fast. > > regards, > Ted > > > > > > >>Let's think through the cases: >>1. The U.S. case works with 1), and if we specified sos has priority, >then >>it would work with 2) >>2. The German case. 1-1-2 is fire/ems, 1-1-0 is police. So, police >would >>have a different service number and URI, fire/ems would have the same >uri >>and the same service number. Priority wouldn't really matter; whether >you >>used 1-1-2 for fire or 1-1-2 for sos, it works. >>3. The French case. Police is 1-7, medical has "more severe - 1-5, >less >>severe 1-8", and Fire is 1-8. 1-1-2 is answered by 1-5 or 1-8 in >different >>parts of the country. This works without priority, because all of the >>services have different service numbers and uris and sos has it's own >>service number and a uri that overlaps with 1-5 or 1-8 depending on >>location. >> >> >>Go look at: >>http://en.wikipedia.org/wiki/Emergency_telephone_number >> >>and see if you can spot a problem with making sos have more priority >than >>any subservice when the sos dial code is re-used for a specific >service. >> >>Brian >> >>> -----Original Message----- >>> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>> Sent: Wednesday, January 16, 2008 9:59 AM >>> To: 'ECRIT' >>> Subject: Re: [Ecrit] Services with same Service Number >>> >>> Hi, Brian, >>> >>> Thanks for the feedback. >>> >>> >>> >I think a country which only had a single emergency number would not >>> > normally list individual services. It would only list the single >sos >>> > service. >>> > >>> > However, if it did, it would list all services with the single >number as >>> > the >>> > service number as well as the sos service. That shouldn't cause >any >>> > confusion at the endpoint. >>> > >>> > Generally, because of 1-1-2, every country has SOME service that >>> responds >>> > to >>> > 1-1-2 even if they don't really have a single emergency number >system. >> > > That >>> > would be the service whose URI was in sos. >>> >>> OK so far... >>> >>> > I don't see the problem. Every country SHOULD have an sos service. >A >>> > country that has a single number emergency system normally SHOULD >NOT >>> list >>> > other services, but if it does, it uses the single emergency number >and >>> > the >>> > single PSAP URI for all of the services. A country that does not >have a >>> > single emergency number still should list an sos service with some >URI >>> and >>> > service number, and MUST list their services with their service >numbers >>> > and >>> > URIs. >>> >>> I'm with you up to this point. In the problem I thought Karl was >raising, >>> he >>> used these examples: >>> >>> >> > North Carolian Police >Dept. >>> >> > urn:service:sos.police >>> >> > sip:police_nc@irt.cs.columbia.edu > >> >> > 911 >>> >> >>> >> > North Carolian Fire >Dept. >>> >> > urn:service:sos.fire >>> >> > sip:fire_nc@irt.cs.columbia.edu >>> >> > 911 >>> >>> which use the same serviceNumber and DIFFERENT uris for multiple >services. >>> >>> What happens then? I have some thoughts but someone else probably has >>> clearer thoughts. >>> >>> Spencer >>> >>> >>> >>> _______________________________________________ >>> 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 > >***** > >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. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 13:50:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDL4-0000e1-ME; Wed, 16 Jan 2008 13:50:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDL2-0000Wa-L6 for ecrit@ietf.org; Wed, 16 Jan 2008 13:50:12 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFDL2-00054e-0v for ecrit@ietf.org; Wed, 16 Jan 2008 13:50:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFDL0-0002XF-DD; Wed, 16 Jan 2008 12:50:10 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'Stark, Barbara'" , "'Spencer Dawkins'" , "'ECRIT'" References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$64 0fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 13:50:07 -0500 Message-ID: <03c401c85870$9f6fb9e0$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYbUwCePBZF8zGQ+CzY42wjd1JWgAAQzpw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Errors-To: ecrit-bounces@ietf.org > I think you have the mapping wrong. The 911 string dialed by the > user is the UI invocation; it's the 3-button equivalent of the big > red button that says "call for help" in jurisdictions that have a single > response view of the world. If LoST had not been previously run, > I would expect it to cause LoST to take the location of the device > and a service urn of sos (unadorned, since 911 is general). It should > then get back a set of URIs and a service number. Presuming > that the device can use one of those URIs, it would then invoke the > protocol processing associated with the URI scheme (SIP, in > the examples we've been discussing). If it cannot, then it > might use the service Number to create a circuit switched call. > That circuit switched call might be to 112. Huh? The numbers came from LoST. For the phone to recognize them, it has to have them, and it gets them from LoST primarily. There ARE other ways: it can get dial string to service mappings by configuration for example. That's the service number. It compares local strings to these service numbers, and when it has a match, it invokes emergency call processing. The result of the match of dialed digits is the service URN. PhoneBCP says that it should update its location and the service URN to PSAP URI mapping at call time. So it should take the service URN and get a new PSAP URI from LoST. If that fails, it can use the cached URI. That's the PSAP URI The phone looks for the service number, maps the service number to the service URN and maps the service URN to the PSAP URI. > > As "additional data" in a phone with sufficient power, it might > also return to the user the information "dialing local emergency > response at 112", so the user knows it can invoke local emergency > response. When the user next dials 112, them implementation > would do exactly the same thing as it did with 911, only the > service number and invocation string would happen to match. Where did this come from? There isn't anything like that I know of. It may well be the case that you can get two service numbers for one service. This would be the case in, for example, the U.K, where both 9-9-9 and 1-1-2 are acceptable. However, you get that from LoST, or you get it from configuration and it still gives you service number to service URN. You can have more than one service number that maps to the same service URN, but in this thread, we're talking about having a service number map to more than one service URN, and we have a problem with that. > > Again, this is the base case. If the phone pre-loads LoST information > and gets mappings beyond those for which the user knows invocation > UI methods, it might in some cases create them. That might be a drop > down list, a voice prompt (now press one for fire, two for police, three > for medical emergencies, or stay on the line) or something else. > It might also add the service numbers to a list of patterns in looks > for as invocations of emergency services (since an invocation > results in the same device behavior whether the invocation string > matches the resulting service number or not, this is okay). But if it > pre-loads this > information by *replacing* the invocation string 911 with 112 because of > local data on the service number, it has not done anyone any favors. Agree, but that's not the problem at hand. The problem at hand is having 9-1-1 map to urn:service:sos AND having 9-1-1 map to urn:service:sos.police. It's okay to have more than one service number map to the same service URN, it's a problem to have more than one service URN map to the same service number. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 14:19:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDnd-0006Bz-EN; Wed, 16 Jan 2008 14:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDnb-0006Bu-ND for ecrit@ietf.org; Wed, 16 Jan 2008 14:19:44 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFDnb-00072u-9b for ecrit@ietf.org; Wed, 16 Jan 2008 14:19:43 -0500 Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.192942055; Wed, 16 Jan 2008 14:19:24 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 16 Jan 2008 14:19:24 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 16 Jan 2008 14:19:24 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Services with same Service Number Date: Wed, 16 Jan 2008 14:19:22 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA070A41C0@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number thread-index: AchYYfYnvDQwPXwWRSiCVXUkA7Ir1AAEf8Zg References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Ted Hardie" , "Brian Rosen" , "Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 16 Jan 2008 19:19:24.0064 (UTC) FILETIME=[B412CA00:01C85874] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org =20 >We have two options: >1. Disallow the circumstance; two services can't have the same service >number >2. Specify priority somehow As we think about these two options, we should also consider the possibility that configured "home" service numbers might overlap with LoST-provided numbers. It's theoretically possible for the same string to have a completely different service urn in different countries. Based on previous discussions, I'm assuming that you (Brian) would prefer for the LoST urn and uri to have precedence. I think that would be an ok rule. Are you thinking phonebcp for this? 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. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 14:28:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDvw-0007zf-IK; Wed, 16 Jan 2008 14:28:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDvw-0007zZ-1d for ecrit@ietf.org; Wed, 16 Jan 2008 14:28:20 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFDvu-0007B2-KH for ecrit@ietf.org; Wed, 16 Jan 2008 14:28:20 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFDvs-0006lj-Ot; Wed, 16 Jan 2008 13:28:16 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Ted Hardie'" , "'Spencer Dawkins'" , "'ECRIT'" References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A41C0@crexc41p> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 14:28:14 -0500 Message-ID: <03c601c85875$f25bcea0$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: <7582BC68E4994F4ABF0BD4723975C3FA070A41C0@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYYfYnvDQwPXwWRSiCVXUkA7Ir1AAEf8ZgAABhCgA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: ecrit-bounces@ietf.org Good thought. Implies we can't just rule it away; the configuration tool and LoST don't talk to one another. The problem you hint at will definitely occur. The typical use for configuration data is to get "home" dial strings, and LoST gives you "visited" dial strings. I agree we're sure to get problems there. So, yes, I would favor LoST over any other way to get the data, and yes, I'm thinking phonebcp. Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Wednesday, January 16, 2008 2:19 PM > To: Ted Hardie; Brian Rosen; Spencer Dawkins; ECRIT > Subject: RE: [Ecrit] Services with same Service Number > > > >We have two options: > >1. Disallow the circumstance; two services can't have the same service > >number > >2. Specify priority somehow > > As we think about these two options, we should also consider the > possibility that configured "home" service numbers might overlap with > LoST-provided numbers. It's theoretically possible for the same string > to have a completely different service urn in different countries. > > Based on previous discussions, I'm assuming that you (Brian) would > prefer for the LoST urn and uri to have precedence. I think that would > be an ok rule. Are you thinking phonebcp for this? > 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. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 14:41:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFE8B-00027v-JA; Wed, 16 Jan 2008 14:40:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFE8A-00027k-KR for ecrit@ietf.org; Wed, 16 Jan 2008 14:40:58 -0500 Received: from wolverine01.qualcomm.com ([199.106.114.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFE89-0006WI-5M for ecrit@ietf.org; Wed, 16 Jan 2008 14:40:58 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:Date:To:From:Subject: Content-Type; b=kEJD/Ad/DS0LScHdK1yQg/Y8JQVrbCQcC7ptCf2iS0TUYfciiNyk7TUN 4G3b6RwrYrk91R4Pt95vBaBDTzFrbNk2Z7gCz+C2j3spZwfgMUK2FErvt CXvTlEIGudDS/dppvDgfbYBbOV0calbzCoJXF2J0GRJciL6xM2O4Q+R8b Y=; X-IronPort-AV: E=McAfee;i="5100,188,5209"; a="565898" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2008 11:40:55 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0GJesFs004896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jan 2008 11:40:55 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0GJersp010210; Wed, 16 Jan 2008 11:40:54 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$64 0fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> Date: Wed, 16 Jan 2008 11:40:52 -0800 To: "Brian Rosen" , "'Stark, Barbara'" , "'Spencer Dawkins'" , "'ECRIT'" From: Ted Hardie Subject: RE: [Ecrit] Services with same Service Number Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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: , Errors-To: ecrit-bounces@ietf.org At 1:50 PM -0500 1/16/08, Brian Rosen wrote: > > I think you have the mapping wrong. The 911 string dialed by the >> user is the UI invocation; it's the 3-button equivalent of the big >> red button that says "call for help" in jurisdictions that have a single >> response view of the world. If LoST had not been previously run, >> I would expect it to cause LoST to take the location of the device >> and a service urn of sos (unadorned, since 911 is general). It should >> then get back a set of URIs and a service number. Presuming >> that the device can use one of those URIs, it would then invoke the >> protocol processing associated with the URI scheme (SIP, in >> the examples we've been discussing). If it cannot, then it >> might use the service Number to create a circuit switched call. >> That circuit switched call might be to 112. >Huh? > >The numbers came from LoST. For the phone to recognize them, it has to have >them, and it gets them from LoST primarily. There ARE other ways: it can >get dial string to service mappings by configuration for example. First, I just went to look up "service number" in phonebcp, and found that the string isn't even found. It consistently uses "dial string" as you use it above. Some reference mapping "dial string" in phonebcp specifically to "service Number" in LoST seems like a good idea, probably here: ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST [I-D.ietf-ecrit-lost]. Second, if I understood Barbara right, she saying that what users will do on phone is mostly dial numbers; I agree with that, and I think phonebcp agrees with that when it talks about recognition of both local and home dial strings in Section 5. Those largely come out of the user's head as known UI invocations; since a user may or may not know the local dial string, both UI invocations have to work. I think we agree on that, and that the current phonebcp text says it here: ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device, then the service provider could recognize them. SP-2 Proxy servers SHOULD recognize emergency dial string if for some reason the endpoint does not recognize them. This cannot be relied upon by the device if the service provider cannot always determine the location of the device. ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE. ED-5/SP-4 Local dial strings MUST be recognized. ED-6/SP-5 Home dial strings MAY be recognized. Where I have been focused in this discussion is on what a device does if it gets back a service Number with a LoST response and cannot use the URIs in the set that is returned. I think the what it does if it *can* is clear: it uses those URIs. I think where we may disagree is what it does if it cannot: I think either the device or the user should be able to take the service Number and attempt to make a call (either on that phone or another) using just the service Number. The particular case in my head is the one where a device with a cellular data connection that would normally complete this using SIP finds it cannot and falls back to a circuit-switched call instead (e.g. 1xRTT). That , in essence, treats the service Number as both a dialstring and more-or-less as the source of a constructed Tel URI. Possibly we disagree on this point, and I'd be interested to know whether we do or do not. > >> >> Again, this is the base case. If the phone pre-loads LoST information >> and gets mappings beyond those for which the user knows invocation >> UI methods, it might in some cases create them. That might be a drop >> down list, a voice prompt (now press one for fire, two for police, three >> for medical emergencies, or stay on the line) or something else. > > It might also add the service numbers to a list of patterns in looks >> for as invocations of emergency services (since an invocation >> results in the same device behavior whether the invocation string >> matches the resulting service number or not, this is okay). But if it >> pre-loads this >> information by *replacing* the invocation string 911 with 112 because of >> local data on the service number, it has not done anyone any favors. >Agree, but that's not the problem at hand. The problem at hand is having >9-1-1 map to urn:service:sos AND having 9-1-1 map to urn:service:sos.police. If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police and the contact URIs returned in the set are the same, there is no fundamental problem. The call still completes and gets to the right place. If the UI invocation used to make the call was just the dialed string, then I would say that the top-level of the hierarchy should be used (urn:service:sos rather than urn:service:sos.police) as an indicator. If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police and the contact URIs returned in the set are not the same, I believe the sensible thing to do for a UI invocation based on the dial string only is to route to urn:service:sos; it's the top of the hierarchy and if you have no other input, that's what you use. But if there is another way to make the selection (drop down, voice prompt, etc.), you might allow that to make a direct selection of the urn:service:sos.police choice, and then route directly there. Forbidding that because there is no dialstring possibility doesn't make sense to me. People may *mostly* use dialstrings on phones, but there are more capable devices out and allowing them to make more precise choices seems reasonable to me if it does not prevent the base case from working. regards, Ted >It's okay to have more than one service number map to the same service URN, >it's a problem to have more than one service URN map to the same service >number. > >Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 15:06:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEXJ-00062U-DF; Wed, 16 Jan 2008 15:06:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEXH-000613-LA for ecrit@ietf.org; Wed, 16 Jan 2008 15:06:55 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFEXF-0001AB-MQ for ecrit@ietf.org; Wed, 16 Jan 2008 15:06:55 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFEXD-0003Xv-CY; Wed, 16 Jan 2008 14:06:51 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'Stark, Barbara'" , "'Spencer Dawkins'" , "'ECRIT'" References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$64 0fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 15:06:49 -0500 Message-ID: <03e001c8587b$5621b350$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYd7a5gyU9CbbyQeW1ez2wvkV7NQAATi9w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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: , Errors-To: ecrit-bounces@ietf.org I'm doing an update to phonebcp now, so I'll fix the terminology issue. Definitely agree users will dial numbers to reach emergency services. We don't like big red emergency buttons. However, it's possible that better UIs that don't have the problems of big red emergency buttons can be devised, and I wouldn't want to rule them out. IFF the phone has an alternate way to place a call (use CS instead of PS) AND its PS mechanisms fail, then indeed it could use any of the dial strings it has to try to reach someone who can help. I think that such cases are pretty much restricted to IMS systems, and I don't think we need to spend much time on them, but if there is support, we could mention it in phonebcp. I think those cases are rare enough that we don't need much guidance (like what number has priority if there is more than one). The only way you can get to the situation where you have two URIs for the same dial string is something like the case Barbara discusses ("home" configuration + "visited" LoST discovery), or the case described below. When dialing is used, we must just use a rule (highest point in the hierarchy, LoST results preferred over other sources). Generally, making choices when you are stressed is usually NOT a good idea, and getting the call to someone ASAP is probably more important. If the LoST database looked like the example we're using, the rule would work, and it would be possible to generate a UI that allowed a user to choose police/fire/ems or overall emergency, with the call going to the appropriate URI. That may actually be of some use if we could get the UI right. All the URIs may actually resolve to the same domain, but the PSAP may be able to use the information profitably (the user is passing information on which service they think they need). That could preload certain screens at the PSAP. Of course, the call taker may decide to override that based on the information gleaned from the call, and local policy, but it could shave some time off response. However, it ONLY works if there is a clear rule for what the UA should do when the digits that map to two URIs is entered, and it only works if someone develops a UI that really does work better than dial strings. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, January 16, 2008 2:41 PM > To: Brian Rosen; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT' > Subject: RE: [Ecrit] Services with same Service Number > > At 1:50 PM -0500 1/16/08, Brian Rosen wrote: > > > I think you have the mapping wrong. The 911 string dialed by the > >> user is the UI invocation; it's the 3-button equivalent of the big > >> red button that says "call for help" in jurisdictions that have a > single > >> response view of the world. If LoST had not been previously run, > >> I would expect it to cause LoST to take the location of the device > >> and a service urn of sos (unadorned, since 911 is general). It should > >> then get back a set of URIs and a service number. Presuming > >> that the device can use one of those URIs, it would then invoke the > >> protocol processing associated with the URI scheme (SIP, in > >> the examples we've been discussing). If it cannot, then it > >> might use the service Number to create a circuit switched call. > >> That circuit switched call might be to 112. > >Huh? > > > >The numbers came from LoST. For the phone to recognize them, it has to > have > >them, and it gets them from LoST primarily. There ARE other ways: it can > >get dial string to service mappings by configuration for example. > > First, I just went to look up "service number" in phonebcp, and found > that the string isn't even found. It consistently uses "dial string" as > you use it above. Some reference mapping "dial string" in phonebcp > specifically to "service Number" in LoST seems like a good idea, > probably here: > > ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST > [I-D.ietf-ecrit-lost]. > > Second, if I understood Barbara right, she saying that what users will > do on phone is mostly dial numbers; I agree with that, and I think > phonebcp > agrees with that when it talks about recognition of both local and > home dial strings in Section 5. Those largely come out of the user's > head as known UI invocations; since a user may or may not know > the local dial string, both UI invocations have to work. I think > we agree on that, and that the current phonebcp text says it here: > > ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If > the service provider always knows the location of the device, then > the service provider could recognize them. > > SP-2 Proxy servers SHOULD recognize emergency dial string if for some > reason the endpoint does not recognize them. This cannot be relied > upon by the device if the service provider cannot always determine > the location of the device. > > ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the > Request-URI of the INVITE. > > ED-5/SP-4 Local dial strings MUST be recognized. > > ED-6/SP-5 Home dial strings MAY be recognized. > > Where I have been focused in this discussion is on what a device does if > it gets > back a service Number with a LoST response and cannot use the URIs in the > set that is returned. I think the what it does if it *can* is clear: it > uses those > URIs. I think where we may disagree is what it does if it cannot: I > think either > the device or the user should be able to take the service Number and > attempt > to make a call (either on that phone or another) using just the service > Number. > The particular case in my head is the one where a device with a cellular > data connection that would normally complete this using SIP finds it > cannot > and falls back to a circuit-switched call instead (e.g. 1xRTT). That , in > essence, > treats the service Number as both a dialstring and more-or-less as the > source > of a constructed Tel URI. > > Possibly we disagree on this point, and I'd be interested to know whether > we > do or do not. > > > > > > > >> > >> Again, this is the base case. If the phone pre-loads LoST information > >> and gets mappings beyond those for which the user knows invocation > >> UI methods, it might in some cases create them. That might be a drop > >> down list, a voice prompt (now press one for fire, two for police, > three > >> for medical emergencies, or stay on the line) or something else. > > > It might also add the service numbers to a list of patterns in looks > >> for as invocations of emergency services (since an invocation > >> results in the same device behavior whether the invocation string > >> matches the resulting service number or not, this is okay). But if it > >> pre-loads this > >> information by *replacing* the invocation string 911 with 112 because > of > >> local data on the service number, it has not done anyone any favors. > >Agree, but that's not the problem at hand. The problem at hand is having > >9-1-1 map to urn:service:sos AND having 9-1-1 map to > urn:service:sos.police. > > If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police > and the contact URIs returned in the set are the same, there is no > fundamental > problem. The call still completes and gets to the right place. If the UI > invocation used to make the call was just the dialed string, then I would > say that the top-level of the hierarchy should be used (urn:service:sos > rather than urn:service:sos.police) as an indicator. > > If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police > and the contact URIs returned in the set are not the same, I believe > the sensible thing to do for a UI invocation based on the dial > string only is to route to urn:service:sos; it's the top of the hierarchy > and if you have no other input, that's what you use. But if there > is another way to make the selection (drop down, voice prompt, > etc.), you might allow that to make a direct selection of the > urn:service:sos.police choice, and then route directly there. Forbidding > that because there is no dialstring possibility doesn't make sense to > me. People may *mostly* use dialstrings on phones, but there are more > capable devices out and allowing them to make more precise choices > seems reasonable to me if it does not prevent the base case from > working. > > regards, > Ted > > > > > > > >It's okay to have more than one service number map to the same service > URN, > >it's a problem to have more than one service URN map to the same service > >number. > > > >Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 16:34:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFuJ-0000kj-1i; Wed, 16 Jan 2008 16:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFuH-0000kb-4I for ecrit@ietf.org; Wed, 16 Jan 2008 16:34:45 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFFuE-0002zO-Qw for ecrit@ietf.org; Wed, 16 Jan 2008 16:34:45 -0500 X-SEF-Processed: 5_0_0_910__2008_01_16_15_46_26 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 16 Jan 2008 15:46:26 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 15:34:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 15:34:39 -0600 Message-ID: In-Reply-To: <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number Thread-Index: AchYd7a5gyU9CbbyQeW1ez2wvkV7NQAATi9wAANb60A= References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> From: "Thomson, Martin" To: "Brian Rosen" , "Ted Hardie" , "Stark, Barbara" , "Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 16 Jan 2008 21:34:42.0248 (UTC) FILETIME=[9AE35C80:01C85887] X-Spam-Score: -0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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="===============1191747642==" Errors-To: ecrit-bounces@ietf.org --===============1191747642== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXNpbmcgb3JkZXJpbmcgdG8gaW1wbHkgcHJpb3JpdHkgaXNuJ3QgaWRlYWwsIGJ1dCBhcyBsb25n IGFzIGl0IGlzIHZlcnkgY2xlYXIgaW4gTG9TVCAobm90IHBob25lYmNwLCB0aGlzIGlzIHByb3Rv Y29sIHNlbWFudGljcykgaXQgc2hvdWxkIHdvcmsuDQoNCkknbSBjb25jZXJuZWQgYWJvdXQgdGhl IHF1ZXN0aW9uIEJhcmJhcmEgcmFpc2VkIHRob3VnaC4NCg0KVG8gcHJvdmlkZSBhbiBleHRyZW1l IGV4YW1wbGUgb2YgQmFyYmFyYSdzIGNvbnVuZHJ1bTogV2hhdCBpZiA5MTEgY2FsbGVkIGZvciBh IHBpenphIGluIEdyZWVubGFuZD8gIEkgYXNzdW1lZCB0aGF0IHRoaXMgY291bGQgYmUgYWRkcmVz c2VkIGJ5IFVBIGNvbmZpZ3VyYXRpb24gb24gYSBkZXZpY2UgdGhhdCB0aGUgdXNlciBvd25zOyB0 aGF0IGlzLCB0aGV5IHRlYWNoIHRoZWlyIFVBIHRvIHVuZGVyc3RhbmQgdGhhdCA5MTEgPT0gdXJu OnNlcnZpY2U6c29zLiAgSG93ZXZlciwgdGhhdCBkb2Vzbid0IHdvcmsgaWYgdGhleSBhcmUgdmlz aXRpbmcgc29tZW9uZSBhbmQganVzdCBwaWNrIHVwIHRoZWlyIGhvc3QncyBVQS4gIEl0IGFsc28g ZG9lc24ndCB3b3JrIGlmIHlvdSBmb3JjZSBMb1NUIHRvIHRha2UgcHJpb3JpdHkuDQoNCkkgYWdy ZWUgdGhvdWdoLCBmb3JjaW5nIGEgc2VyaWVzIG9mIHF1ZXN0aW9ucyBmb3IgYW4gZW1lcmdlbmN5 IGNhbGwgaXNuJ3QgYSBnb29kIGlkZWEuICBXZSBuZWVkIGEgc2Vuc2libGUgZGVmYXVsdCBiZWhh dmlvdXIuICBQZXJoYXBzIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgYW55IHNlcnZpY2Ug aW4gdGhlIHVybjpzZXJ2aWNlOnNvcyogcGF0aCBvdmVycmlkZXMgYW55IG90aGVyIHNlcnZpY2Uu DQoNCl9NDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gUm9z ZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIDE3IEphbnVh cnkgMjAwOCA3OjA3IEFNDQo+IFRvOiAnVGVkIEhhcmRpZSc7ICdTdGFyaywgQmFyYmFyYSc7ICdT cGVuY2VyIERhd2tpbnMnOyAnRUNSSVQnDQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFNlcnZpY2Vz IHdpdGggc2FtZSBTZXJ2aWNlIE51bWJlcg0KPiANCj4gSSdtIGRvaW5nIGFuIHVwZGF0ZSB0byBw aG9uZWJjcCBub3csIHNvIEknbGwgZml4IHRoZSB0ZXJtaW5vbG9neSBpc3N1ZS4NCj4gDQo+IERl ZmluaXRlbHkgYWdyZWUgdXNlcnMgd2lsbCBkaWFsIG51bWJlcnMgdG8gcmVhY2ggZW1lcmdlbmN5 IHNlcnZpY2VzLiAgV2UNCj4gZG9uJ3QgbGlrZSBiaWcgcmVkIGVtZXJnZW5jeSBidXR0b25zLiAg SG93ZXZlciwgaXQncyBwb3NzaWJsZSB0aGF0IGJldHRlcg0KPiBVSXMgdGhhdCBkb24ndCBoYXZl IHRoZSBwcm9ibGVtcyBvZiBiaWcgcmVkIGVtZXJnZW5jeSBidXR0b25zIGNhbiBiZQ0KPiBkZXZp c2VkLCBhbmQgSSB3b3VsZG4ndCB3YW50IHRvIHJ1bGUgdGhlbSBvdXQuDQo+IA0KPiBJRkYgdGhl IHBob25lIGhhcyBhbiBhbHRlcm5hdGUgd2F5IHRvIHBsYWNlIGEgY2FsbCAodXNlIENTIGluc3Rl YWQgb2YgUFMpDQo+IEFORCBpdHMgUFMgbWVjaGFuaXNtcyBmYWlsLCB0aGVuIGluZGVlZCBpdCBj b3VsZCB1c2UgYW55IG9mIHRoZSBkaWFsDQo+IHN0cmluZ3MNCj4gaXQgaGFzIHRvIHRyeSB0byBy ZWFjaCBzb21lb25lIHdobyBjYW4gaGVscC4gIEkgdGhpbmsgdGhhdCBzdWNoIGNhc2VzIGFyZQ0K PiBwcmV0dHkgbXVjaCByZXN0cmljdGVkIHRvIElNUyBzeXN0ZW1zLCBhbmQgSSBkb24ndCB0aGlu ayB3ZSBuZWVkIHRvIHNwZW5kDQo+IG11Y2ggdGltZSBvbiB0aGVtLCBidXQgaWYgdGhlcmUgaXMg c3VwcG9ydCwgd2UgY291bGQgbWVudGlvbiBpdCBpbg0KPiBwaG9uZWJjcC4NCj4gSSB0aGluayB0 aG9zZSBjYXNlcyBhcmUgcmFyZSBlbm91Z2ggdGhhdCB3ZSBkb24ndCBuZWVkIG11Y2ggZ3VpZGFu Y2UgKGxpa2UNCj4gd2hhdCBudW1iZXIgaGFzIHByaW9yaXR5IGlmIHRoZXJlIGlzIG1vcmUgdGhh biBvbmUpLg0KPiANCj4gVGhlIG9ubHkgd2F5IHlvdSBjYW4gZ2V0IHRvIHRoZSBzaXR1YXRpb24g d2hlcmUgeW91IGhhdmUgdHdvIFVSSXMgZm9yIHRoZQ0KPiBzYW1lIGRpYWwgc3RyaW5nIGlzIHNv bWV0aGluZyBsaWtlIHRoZSBjYXNlIEJhcmJhcmEgZGlzY3Vzc2VzICgiaG9tZSINCj4gY29uZmln dXJhdGlvbiArICJ2aXNpdGVkIiBMb1NUIGRpc2NvdmVyeSksIG9yIHRoZSBjYXNlIGRlc2NyaWJl ZCBiZWxvdy4NCj4gV2hlbiBkaWFsaW5nIGlzIHVzZWQsIHdlIG11c3QganVzdCB1c2UgYSBydWxl IChoaWdoZXN0IHBvaW50IGluIHRoZQ0KPiBoaWVyYXJjaHksIExvU1QgcmVzdWx0cyBwcmVmZXJy ZWQgb3ZlciBvdGhlciBzb3VyY2VzKS4NCj4gDQo+IEdlbmVyYWxseSwgbWFraW5nIGNob2ljZXMg d2hlbiB5b3UgYXJlIHN0cmVzc2VkIGlzIHVzdWFsbHkgTk9UIGEgZ29vZCBpZGVhLA0KPiBhbmQg Z2V0dGluZyB0aGUgY2FsbCB0byBzb21lb25lIEFTQVAgaXMgcHJvYmFibHkgbW9yZSBpbXBvcnRh bnQuDQo+IA0KPiBJZiB0aGUgTG9TVCBkYXRhYmFzZSBsb29rZWQgbGlrZSB0aGUgZXhhbXBsZSB3 ZSdyZSB1c2luZywgdGhlIHJ1bGUgd291bGQNCj4gd29yaywgYW5kIGl0IHdvdWxkIGJlIHBvc3Np YmxlIHRvIGdlbmVyYXRlIGEgVUkgdGhhdCBhbGxvd2VkIGEgdXNlciB0bw0KPiBjaG9vc2UgcG9s aWNlL2ZpcmUvZW1zIG9yIG92ZXJhbGwgZW1lcmdlbmN5LCB3aXRoIHRoZSBjYWxsIGdvaW5nIHRv IHRoZQ0KPiBhcHByb3ByaWF0ZSBVUkkuICBUaGF0IG1heSBhY3R1YWxseSBiZSBvZiBzb21lIHVz ZSBpZiB3ZSBjb3VsZCBnZXQgdGhlIFVJDQo+IHJpZ2h0LiAgQWxsIHRoZSBVUklzIG1heSBhY3R1 YWxseSByZXNvbHZlIHRvIHRoZSBzYW1lIGRvbWFpbiwgYnV0IHRoZSBQU0FQDQo+IG1heSBiZSBh YmxlIHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gcHJvZml0YWJseSAodGhlIHVzZXIgaXMgcGFzc2lu Zw0KPiBpbmZvcm1hdGlvbiBvbiB3aGljaCBzZXJ2aWNlIHRoZXkgdGhpbmsgdGhleSBuZWVkKS4g IFRoYXQgY291bGQgcHJlbG9hZA0KPiBjZXJ0YWluIHNjcmVlbnMgYXQgdGhlIFBTQVAuICBPZiBj b3Vyc2UsIHRoZSBjYWxsIHRha2VyIG1heSBkZWNpZGUgdG8NCj4gb3ZlcnJpZGUgdGhhdCBiYXNl ZCBvbiB0aGUgaW5mb3JtYXRpb24gZ2xlYW5lZCBmcm9tIHRoZSBjYWxsLCBhbmQgbG9jYWwNCj4g cG9saWN5LCBidXQgaXQgY291bGQgc2hhdmUgc29tZSB0aW1lIG9mZiByZXNwb25zZS4NCj4gDQo+ IEhvd2V2ZXIsIGl0IE9OTFkgd29ya3MgaWYgdGhlcmUgaXMgYSBjbGVhciBydWxlIGZvciB3aGF0 IHRoZSBVQSBzaG91bGQgZG8NCj4gd2hlbiB0aGUgZGlnaXRzIHRoYXQgbWFwIHRvIHR3byBVUklz IGlzIGVudGVyZWQsIGFuZCBpdCBvbmx5IHdvcmtzIGlmDQo+IHNvbWVvbmUgZGV2ZWxvcHMgYSBV SSB0aGF0IHJlYWxseSBkb2VzIHdvcmsgYmV0dGVyIHRoYW4gZGlhbCBzdHJpbmdzLg0KPiANCj4g QnJpYW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBUZWQg SGFyZGllIFttYWlsdG86aGFyZGllQHF1YWxjb21tLmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMTYsIDIwMDggMjo0MSBQTQ0KPiA+IFRvOiBCcmlhbiBSb3NlbjsgJ1N0YXJrLCBC YXJiYXJhJzsgJ1NwZW5jZXIgRGF3a2lucyc7ICdFQ1JJVCcNCj4gPiBTdWJqZWN0OiBSRTogW0Vj cml0XSBTZXJ2aWNlcyB3aXRoIHNhbWUgU2VydmljZSBOdW1iZXINCj4gPg0KPiA+IEF0IDE6NTAg UE0gLTA1MDAgMS8xNi8wOCwgQnJpYW4gUm9zZW4gd3JvdGU6DQo+ID4gPiA+IEkgdGhpbmsgeW91 IGhhdmUgdGhlIG1hcHBpbmcgd3JvbmcuICBUaGUgOTExIHN0cmluZyBkaWFsZWQgYnkgdGhlDQo+ ID4gPj4gdXNlciBpcyB0aGUgVUkgaW52b2NhdGlvbjsgaXQncyB0aGUgMy1idXR0b24gZXF1aXZh bGVudCBvZiB0aGUgYmlnDQo+ID4gPj4gcmVkIGJ1dHRvbiB0aGF0IHNheXMgImNhbGwgZm9yIGhl bHAiIGluIGp1cmlzZGljdGlvbnMgdGhhdCBoYXZlIGENCj4gPiBzaW5nbGUNCj4gPiA+PiByZXNw b25zZSB2aWV3IG9mIHRoZSB3b3JsZC4gIElmIExvU1QgaGFkIG5vdCBiZWVuIHByZXZpb3VzbHkg cnVuLA0KPiA+ID4+IEkgd291bGQgZXhwZWN0IGl0IHRvIGNhdXNlIExvU1QgdG8gdGFrZSB0aGUg bG9jYXRpb24gb2YgdGhlIGRldmljZQ0KPiA+ID4+IGFuZCBhIHNlcnZpY2UgdXJuIG9mIHNvcyAo dW5hZG9ybmVkLCBzaW5jZSA5MTEgaXMgZ2VuZXJhbCkuICBJdA0KPiBzaG91bGQNCj4gPiA+PiB0 aGVuIGdldCBiYWNrIGEgc2V0IG9mIFVSSXMgYW5kIGEgc2VydmljZSBudW1iZXIuICBQcmVzdW1p bmcNCj4gPiA+PiB0aGF0IHRoZSBkZXZpY2UgY2FuIHVzZSBvbmUgb2YgdGhvc2UgVVJJcywgaXQg d291bGQgdGhlbiBpbnZva2UgdGhlDQo+ID4gPj4gcHJvdG9jb2wgcHJvY2Vzc2luZyBhc3NvY2lh dGVkIHdpdGggdGhlIFVSSSBzY2hlbWUgKFNJUCwgaW4NCj4gPiA+PiB0aGUgZXhhbXBsZXMgd2Un dmUgYmVlbiBkaXNjdXNzaW5nKS4gIElmIGl0IGNhbm5vdCwgdGhlbiBpdA0KPiA+ID4+IG1pZ2h0 IHVzZSB0aGUgc2VydmljZSBOdW1iZXIgdG8gY3JlYXRlIGEgY2lyY3VpdCBzd2l0Y2hlZCBjYWxs Lg0KPiA+ID4+IFRoYXQgY2lyY3VpdCBzd2l0Y2hlZCBjYWxsIG1pZ2h0IGJlIHRvIDExMi4NCj4g PiA+SHVoPw0KPiA+ID4NCj4gPiA+VGhlIG51bWJlcnMgY2FtZSBmcm9tIExvU1QuICBGb3IgdGhl IHBob25lIHRvIHJlY29nbml6ZSB0aGVtLCBpdCBoYXMgdG8NCj4gPiBoYXZlDQo+ID4gPnRoZW0s IGFuZCBpdCBnZXRzIHRoZW0gZnJvbSBMb1NUIHByaW1hcmlseS4gIFRoZXJlIEFSRSBvdGhlciB3 YXlzOiBpdA0KPiBjYW4NCj4gPiA+Z2V0IGRpYWwgc3RyaW5nIHRvIHNlcnZpY2UgbWFwcGluZ3Mg YnkgY29uZmlndXJhdGlvbiBmb3IgZXhhbXBsZS4NCj4gPg0KPiA+IEZpcnN0LCBJIGp1c3Qgd2Vu dCB0byBsb29rIHVwICJzZXJ2aWNlIG51bWJlciIgaW4gcGhvbmViY3AsIGFuZCBmb3VuZA0KPiA+ IHRoYXQgdGhlIHN0cmluZyBpc24ndCBldmVuIGZvdW5kLiAgSXQgY29uc2lzdGVudGx5IHVzZXMg ImRpYWwgc3RyaW5nIiBhcw0KPiA+IHlvdSB1c2UgaXQgYWJvdmUuICBTb21lIHJlZmVyZW5jZSBt YXBwaW5nICJkaWFsIHN0cmluZyIgaW4gcGhvbmViY3ANCj4gPiBzcGVjaWZpY2FsbHkgdG8gInNl cnZpY2UgTnVtYmVyIiBpbiBMb1NUIHNlZW1zIGxpa2UgYSBnb29kIGlkZWEsDQo+ID4gcHJvYmFi bHkgaGVyZToNCj4gPg0KPiA+IEVELTcvU1AtNiBMb2NhbCBlbWVyZ2VuY3kgZGlhbCBzdHJpbmdz IFNIT1VMRCBiZSBkZXRlcm1pbmVkIGZyb20gTG9TVA0KPiA+ICAgIFtJLUQuaWV0Zi1lY3JpdC1s b3N0XS4NCj4gPg0KPiA+IFNlY29uZCwgaWYgSSB1bmRlcnN0b29kIEJhcmJhcmEgcmlnaHQsIHNo ZSBzYXlpbmcgdGhhdCB3aGF0IHVzZXJzIHdpbGwNCj4gPiBkbyBvbiBwaG9uZSBpcyBtb3N0bHkg ZGlhbCBudW1iZXJzOyBJIGFncmVlIHdpdGggdGhhdCwgYW5kIEkgdGhpbmsNCj4gPiBwaG9uZWJj cA0KPiA+IGFncmVlcyB3aXRoIHRoYXQgd2hlbiBpdCB0YWxrcyBhYm91dCByZWNvZ25pdGlvbiBv ZiBib3RoIGxvY2FsIGFuZA0KPiA+IGhvbWUgZGlhbCBzdHJpbmdzIGluIFNlY3Rpb24gNS4gIFRo b3NlIGxhcmdlbHkgY29tZSBvdXQgb2YgdGhlIHVzZXIncw0KPiA+IGhlYWQgYXMga25vd24gVUkg aW52b2NhdGlvbnM7IHNpbmNlIGEgdXNlciBtYXkgb3IgbWF5IG5vdCBrbm93DQo+ID4gdGhlIGxv Y2FsIGRpYWwgc3RyaW5nLCBib3RoIFVJIGludm9jYXRpb25zIGhhdmUgdG8gd29yay4gIEkgdGhp bmsNCj4gPiB3ZSBhZ3JlZSBvbiB0aGF0LCBhbmQgdGhhdCB0aGUgY3VycmVudCBwaG9uZWJjcCB0 ZXh0IHNheXMgaXQgaGVyZToNCj4gPg0KPiA+ICAgIEVELTMgRW5kcG9pbnRzIFNIT1VMRCByZWNv Z25pemUgZGlhbCBzdHJpbmdzIG9mIGVtZXJnZW5jeSBjYWxscy4gIElmDQo+ID4gICAgdGhlIHNl cnZpY2UgcHJvdmlkZXIgYWx3YXlzIGtub3dzIHRoZSBsb2NhdGlvbiBvZiB0aGUgZGV2aWNlLCB0 aGVuDQo+ID4gICAgdGhlIHNlcnZpY2UgcHJvdmlkZXIgY291bGQgcmVjb2duaXplIHRoZW0uDQo+ ID4NCj4gPiAgICBTUC0yIFByb3h5IHNlcnZlcnMgU0hPVUxEIHJlY29nbml6ZSBlbWVyZ2VuY3kg ZGlhbCBzdHJpbmcgaWYgZm9yIHNvbWUNCj4gPiAgICByZWFzb24gdGhlIGVuZHBvaW50IGRvZXMg bm90IHJlY29nbml6ZSB0aGVtLiAgVGhpcyBjYW5ub3QgYmUgcmVsaWVkDQo+ID4gICAgdXBvbiBi eSB0aGUgZGV2aWNlIGlmIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGNhbm5vdCBhbHdheXMgZGV0ZXJt aW5lDQo+ID4gICAgdGhlIGxvY2F0aW9uIG9mIHRoZSBkZXZpY2UuDQo+ID4NCj4gPiAgICBFRC00 L1NQLTMgRW1lcmdlbmN5IGNhbGxzIE1VU1QgYmUgbWFya2VkIHdpdGggYSBTZXJ2aWNlIFVSTiBp biB0aGUNCj4gPiAgICBSZXF1ZXN0LVVSSSBvZiB0aGUgSU5WSVRFLg0KPiA+DQo+ID4gICAgRUQt NS9TUC00IExvY2FsIGRpYWwgc3RyaW5ncyBNVVNUIGJlIHJlY29nbml6ZWQuDQo+ID4NCj4gPiAg ICBFRC02L1NQLTUgSG9tZSBkaWFsIHN0cmluZ3MgTUFZIGJlIHJlY29nbml6ZWQuDQo+ID4NCj4g PiBXaGVyZSBJIGhhdmUgYmVlbiBmb2N1c2VkIGluIHRoaXMgZGlzY3Vzc2lvbiBpcyBvbiB3aGF0 IGEgZGV2aWNlIGRvZXMgaWYNCj4gPiBpdCBnZXRzDQo+ID4gYmFjayBhIHNlcnZpY2UgTnVtYmVy IHdpdGggYSBMb1NUIHJlc3BvbnNlIGFuZCBjYW5ub3QgdXNlIHRoZSBVUklzIGluDQo+IHRoZQ0K PiA+IHNldCB0aGF0IGlzIHJldHVybmVkLiAgSSB0aGluayB0aGUgd2hhdCBpdCBkb2VzIGlmIGl0 ICpjYW4qIGlzIGNsZWFyOg0KPiBpdA0KPiA+IHVzZXMgdGhvc2UNCj4gPiBVUklzLiAgSSB0aGlu ayB3aGVyZSB3ZSBtYXkgZGlzYWdyZWUgaXMgd2hhdCBpdCBkb2VzIGlmIGl0IGNhbm5vdDogIEkN Cj4gPiB0aGluayBlaXRoZXINCj4gPiB0aGUgZGV2aWNlIG9yIHRoZSB1c2VyIHNob3VsZCBiZSBh YmxlIHRvIHRha2UgdGhlIHNlcnZpY2UgTnVtYmVyIGFuZA0KPiA+IGF0dGVtcHQNCj4gPiB0byBt YWtlIGEgY2FsbCAoZWl0aGVyIG9uIHRoYXQgcGhvbmUgb3IgYW5vdGhlcikgdXNpbmcganVzdCB0 aGUgc2VydmljZQ0KPiA+IE51bWJlci4NCj4gPiBUaGUgcGFydGljdWxhciBjYXNlIGluIG15IGhl YWQgaXMgdGhlIG9uZSB3aGVyZSBhIGRldmljZSB3aXRoIGEgY2VsbHVsYXINCj4gPiBkYXRhIGNv bm5lY3Rpb24gdGhhdCB3b3VsZCBub3JtYWxseSBjb21wbGV0ZSB0aGlzIHVzaW5nIFNJUCBmaW5k cyBpdA0KPiA+IGNhbm5vdA0KPiA+IGFuZCBmYWxscyBiYWNrIHRvIGEgY2lyY3VpdC1zd2l0Y2hl ZCBjYWxsIGluc3RlYWQgKGUuZy4gMXhSVFQpLiAgVGhhdCAsDQo+IGluDQo+ID4gZXNzZW5jZSwN Cj4gPiB0cmVhdHMgdGhlIHNlcnZpY2UgTnVtYmVyIGFzIGJvdGggYSBkaWFsc3RyaW5nIGFuZCBt b3JlLW9yLWxlc3MgYXMgdGhlDQo+ID4gc291cmNlDQo+ID4gb2YgYSBjb25zdHJ1Y3RlZCBUZWwg VVJJLg0KPiA+DQo+ID4gUG9zc2libHkgd2UgZGlzYWdyZWUgb24gdGhpcyBwb2ludCwgYW5kIEkn ZCBiZSBpbnRlcmVzdGVkIHRvIGtub3cNCj4gd2hldGhlcg0KPiA+IHdlDQo+ID4gZG8gb3IgZG8g bm90Lg0KPiA+DQo+ID4NCj4gPiA8c25pcD4NCj4gPg0KPiA+ID4NCj4gPiA+Pg0KPiA+ID4+IEFn YWluLCB0aGlzIGlzIHRoZSBiYXNlIGNhc2UuICBJZiB0aGUgcGhvbmUgcHJlLWxvYWRzIExvU1QN Cj4gaW5mb3JtYXRpb24NCj4gPiA+PiBhbmQgZ2V0cyBtYXBwaW5ncyBiZXlvbmQgdGhvc2UgZm9y IHdoaWNoIHRoZSB1c2VyIGtub3dzIGludm9jYXRpb24NCj4gPiA+PiBVSSBtZXRob2RzLCBpdCBt aWdodCBpbiBzb21lIGNhc2VzIGNyZWF0ZSB0aGVtLiAgVGhhdCBtaWdodCBiZSBhIGRyb3ANCj4g PiA+PiBkb3duIGxpc3QsIGEgdm9pY2UgcHJvbXB0IChub3cgcHJlc3Mgb25lIGZvciBmaXJlLCB0 d28gZm9yIHBvbGljZSwNCj4gPiB0aHJlZQ0KPiA+ID4+IGZvciBtZWRpY2FsIGVtZXJnZW5jaWVz LCBvciBzdGF5IG9uIHRoZSBsaW5lKSBvciBzb21ldGhpbmcgZWxzZS4NCj4gPiA+ID4gSXQgbWln aHQgYWxzbyBhZGQgdGhlIHNlcnZpY2UgbnVtYmVycyB0byBhIGxpc3Qgb2YgcGF0dGVybnMgaW4g bG9va3MNCj4gPiA+PiBmb3IgYXMgaW52b2NhdGlvbnMgb2YgZW1lcmdlbmN5IHNlcnZpY2VzIChz aW5jZSBhbiBpbnZvY2F0aW9uDQo+ID4gPj4gcmVzdWx0cyBpbiB0aGUgc2FtZSBkZXZpY2UgYmVo YXZpb3Igd2hldGhlciAgdGhlIGludm9jYXRpb24gc3RyaW5nDQo+ID4gPj4gbWF0Y2hlcyB0aGUg cmVzdWx0aW5nIHNlcnZpY2UgbnVtYmVyIG9yIG5vdCwgdGhpcyBpcyBva2F5KS4gIEJ1dCBpZg0K PiBpdA0KPiA+ID4+IHByZS1sb2FkcyB0aGlzDQo+ID4gPj4gaW5mb3JtYXRpb24gYnkgKnJlcGxh Y2luZyogdGhlIGludm9jYXRpb24gc3RyaW5nIDkxMSB3aXRoIDExMiBiZWNhdXNlDQo+ID4gb2YN Cj4gPiA+PiBsb2NhbCBkYXRhIG9uIHRoZSBzZXJ2aWNlIG51bWJlciwgaXQgaGFzIG5vdCBkb25l IGFueW9uZSBhbnkgZmF2b3JzLg0KPiA+ID5BZ3JlZSwgYnV0IHRoYXQncyBub3QgdGhlIHByb2Js ZW0gYXQgaGFuZC4gIFRoZSBwcm9ibGVtIGF0IGhhbmQgaXMNCj4gaGF2aW5nDQo+ID4gPjktMS0x IG1hcCB0byB1cm46c2VydmljZTpzb3MgQU5EIGhhdmluZyA5LTEtMSBtYXAgdG8NCj4gPiB1cm46 c2VydmljZTpzb3MucG9saWNlLg0KPiA+DQo+ID4gSWYgOS0xLTEgbWFwcyB0byB1cm46c2Vydmlj ZTpzb3MgYW5kIDktMS0xIG1hcHMgdG8NCj4gdXJuOnNlcnZpY2U6c29zLnBvbGljZQ0KPiA+IGFu ZCB0aGUgY29udGFjdCBVUklzIHJldHVybmVkIGluIHRoZSBzZXQgYXJlIHRoZSBzYW1lLCB0aGVy ZSBpcyBubw0KPiA+IGZ1bmRhbWVudGFsDQo+ID4gcHJvYmxlbS4gIFRoZSBjYWxsIHN0aWxsIGNv bXBsZXRlcyBhbmQgZ2V0cyB0byB0aGUgcmlnaHQgcGxhY2UuICBJZiB0aGUNCj4gVUkNCj4gPiBp bnZvY2F0aW9uIHVzZWQgdG8gbWFrZSB0aGUgY2FsbCB3YXMganVzdCB0aGUgZGlhbGVkIHN0cmlu ZywgdGhlbiBJDQo+IHdvdWxkDQo+ID4gc2F5IHRoYXQgdGhlIHRvcC1sZXZlbCBvZiB0aGUgaGll cmFyY2h5IHNob3VsZCBiZSB1c2VkICh1cm46c2VydmljZTpzb3MNCj4gPiByYXRoZXIgdGhhbiB1 cm46c2VydmljZTpzb3MucG9saWNlKSBhcyBhbiBpbmRpY2F0b3IuDQo+ID4NCj4gPiBJZiA5LTEt MSBtYXBzIHRvIHVybjpzZXJ2aWNlOnNvcyBhbmQgOS0xLTEgbWFwcyB0bw0KPiB1cm46c2Vydmlj ZTpzb3MucG9saWNlDQo+ID4gYW5kIHRoZSBjb250YWN0IFVSSXMgcmV0dXJuZWQgaW4gdGhlIHNl dCBhcmUgbm90IHRoZSBzYW1lLCBJIGJlbGlldmUNCj4gPiB0aGUgc2Vuc2libGUgdGhpbmcgdG8g ZG8gZm9yIGEgVUkgaW52b2NhdGlvbiBiYXNlZCBvbiB0aGUgZGlhbA0KPiA+IHN0cmluZyBvbmx5 IGlzIHRvIHJvdXRlIHRvIHVybjpzZXJ2aWNlOnNvczsgaXQncyB0aGUgdG9wIG9mIHRoZQ0KPiBo aWVyYXJjaHkNCj4gPiBhbmQgaWYgeW91IGhhdmUgbm8gb3RoZXIgaW5wdXQsIHRoYXQncyB3aGF0 IHlvdSB1c2UuICBCdXQgaWYgdGhlcmUNCj4gPiBpcyBhbm90aGVyIHdheSB0byBtYWtlIHRoZSBz ZWxlY3Rpb24gKGRyb3AgZG93biwgdm9pY2UgcHJvbXB0LA0KPiA+IGV0Yy4pLCB5b3UgbWlnaHQg YWxsb3cgdGhhdCB0byBtYWtlIGEgZGlyZWN0IHNlbGVjdGlvbiBvZiB0aGUNCj4gPiB1cm46c2Vy dmljZTpzb3MucG9saWNlIGNob2ljZSwgYW5kIHRoZW4gcm91dGUgZGlyZWN0bHkgdGhlcmUuDQo+ IEZvcmJpZGRpbmcNCj4gPiB0aGF0IGJlY2F1c2UgdGhlcmUgaXMgbm8gZGlhbHN0cmluZyBwb3Nz aWJpbGl0eSBkb2Vzbid0IG1ha2Ugc2Vuc2UgdG8NCj4gPiBtZS4gIFBlb3BsZSBtYXkgKm1vc3Rs eSogdXNlIGRpYWxzdHJpbmdzIG9uIHBob25lcywgYnV0IHRoZXJlIGFyZSBtb3JlDQo+ID4gY2Fw YWJsZSBkZXZpY2VzIG91dCBhbmQgYWxsb3dpbmcgdGhlbSB0byBtYWtlIG1vcmUgcHJlY2lzZSBj aG9pY2VzDQo+ID4gc2VlbXMgcmVhc29uYWJsZSB0byBtZSBpZiBpdCBkb2VzIG5vdCBwcmV2ZW50 IHRoZSBiYXNlIGNhc2UgZnJvbQ0KPiA+IHdvcmtpbmcuDQo+ID4NCj4gPiAJCQkJcmVnYXJkcywN Cj4gPiAJCQkJCVRlZA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ID5JdCdzIG9r YXkgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIHNlcnZpY2UgbnVtYmVyIG1hcCB0byB0aGUgc2FtZSBz ZXJ2aWNlDQo+ID4gVVJOLA0KPiA+ID5pdCdzIGEgcHJvYmxlbSB0byBoYXZlIG1vcmUgdGhhbiBv bmUgc2VydmljZSBVUk4gbWFwIHRvIHRoZSBzYW1lDQo+IHNlcnZpY2UNCj4gPiA+bnVtYmVyLg0K PiA+ID4NCj4gPiA+QnJpYW4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9y IHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdl ZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQpp bW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNl IG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============1191747642== 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 --===============1191747642==-- From ecrit-bounces@ietf.org Wed Jan 16 16:56:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGFD-000896-Hz; Wed, 16 Jan 2008 16:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGFC-00084N-SW for ecrit@ietf.org; Wed, 16 Jan 2008 16:56:22 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFGFB-0003VX-H4 for ecrit@ietf.org; Wed, 16 Jan 2008 16:56:22 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFGF8-0005af-Fp; Wed, 16 Jan 2008 15:56:19 -0600 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Ted Hardie'" , "'Stark, Barbara'" , "'Spencer Dawkins'" , "'ECRIT'" References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 16:56:16 -0500 Message-ID: <03ff01c8588a$a0c11a40$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYd7a5gyU9CbbyQeW1ez2wvkV7NQAATi9wAANb60AAAOpCcA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 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: , Errors-To: ecrit-bounces@ietf.org We're not proposing to use ordering. We're proposing to use hierarchy (sos is higher than sos.police). I agree that sos is higher than any other service. I'm not sure I understand why you think following LoST doesn't work. If you are visiting the U.S. from Greenland, and you dial 9-1-1, you should get a PSAP. If you intended to order pizza, you will be surprised. However, you definitely DON'T want to get the local pizza service. Always preferring LoST would always make the local dialing plan take priority. That is correct. Any configuration is wrong. I don't feel great about not having a way to override LoST, but I think it's a much more likely failure to have local configuration be wrong then to have LoST be wrong. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Wednesday, January 16, 2008 4:35 PM > To: Brian Rosen; Ted Hardie; Stark, Barbara; Spencer Dawkins; ECRIT > Subject: RE: [Ecrit] Services with same Service Number > > Using ordering to imply priority isn't ideal, but as long as it is very > clear in LoST (not phonebcp, this is protocol semantics) it should work. > > I'm concerned about the question Barbara raised though. > > To provide an extreme example of Barbara's conundrum: What if 911 called > for a pizza in Greenland? I assumed that this could be addressed by UA > configuration on a device that the user owns; that is, they teach their UA > to understand that 911 == urn:service:sos. However, that doesn't work if > they are visiting someone and just pick up their host's UA. It also > doesn't work if you force LoST to take priority. > > I agree though, forcing a series of questions for an emergency call isn't > a good idea. We need a sensible default behaviour. Perhaps something > along the lines of any service in the urn:service:sos* path overrides any > other service. > > _M > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 17 January 2008 7:07 AM > > To: 'Ted Hardie'; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT' > > Subject: RE: [Ecrit] Services with same Service Number > > > > I'm doing an update to phonebcp now, so I'll fix the terminology issue. > > > > Definitely agree users will dial numbers to reach emergency services. > We > > don't like big red emergency buttons. However, it's possible that > better > > UIs that don't have the problems of big red emergency buttons can be > > devised, and I wouldn't want to rule them out. > > > > IFF the phone has an alternate way to place a call (use CS instead of > PS) > > AND its PS mechanisms fail, then indeed it could use any of the dial > > strings > > it has to try to reach someone who can help. I think that such cases > are > > pretty much restricted to IMS systems, and I don't think we need to > spend > > much time on them, but if there is support, we could mention it in > > phonebcp. > > I think those cases are rare enough that we don't need much guidance > (like > > what number has priority if there is more than one). > > > > The only way you can get to the situation where you have two URIs for > the > > same dial string is something like the case Barbara discusses ("home" > > configuration + "visited" LoST discovery), or the case described below. > > When dialing is used, we must just use a rule (highest point in the > > hierarchy, LoST results preferred over other sources). > > > > Generally, making choices when you are stressed is usually NOT a good > idea, > > and getting the call to someone ASAP is probably more important. > > > > If the LoST database looked like the example we're using, the rule would > > work, and it would be possible to generate a UI that allowed a user to > > choose police/fire/ems or overall emergency, with the call going to the > > appropriate URI. That may actually be of some use if we could get the > UI > > right. All the URIs may actually resolve to the same domain, but the > PSAP > > may be able to use the information profitably (the user is passing > > information on which service they think they need). That could preload > > certain screens at the PSAP. Of course, the call taker may decide to > > override that based on the information gleaned from the call, and local > > policy, but it could shave some time off response. > > > > However, it ONLY works if there is a clear rule for what the UA should > do > > when the digits that map to two URIs is entered, and it only works if > > someone develops a UI that really does work better than dial strings. > > > > Brian > > > > > -----Original Message----- > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > Sent: Wednesday, January 16, 2008 2:41 PM > > > To: Brian Rosen; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT' > > > Subject: RE: [Ecrit] Services with same Service Number > > > > > > At 1:50 PM -0500 1/16/08, Brian Rosen wrote: > > > > > I think you have the mapping wrong. The 911 string dialed by the > > > >> user is the UI invocation; it's the 3-button equivalent of the big > > > >> red button that says "call for help" in jurisdictions that have a > > > single > > > >> response view of the world. If LoST had not been previously run, > > > >> I would expect it to cause LoST to take the location of the device > > > >> and a service urn of sos (unadorned, since 911 is general). It > > should > > > >> then get back a set of URIs and a service number. Presuming > > > >> that the device can use one of those URIs, it would then invoke the > > > >> protocol processing associated with the URI scheme (SIP, in > > > >> the examples we've been discussing). If it cannot, then it > > > >> might use the service Number to create a circuit switched call. > > > >> That circuit switched call might be to 112. > > > >Huh? > > > > > > > >The numbers came from LoST. For the phone to recognize them, it has > to > > > have > > > >them, and it gets them from LoST primarily. There ARE other ways: it > > can > > > >get dial string to service mappings by configuration for example. > > > > > > First, I just went to look up "service number" in phonebcp, and found > > > that the string isn't even found. It consistently uses "dial string" > as > > > you use it above. Some reference mapping "dial string" in phonebcp > > > specifically to "service Number" in LoST seems like a good idea, > > > probably here: > > > > > > ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST > > > [I-D.ietf-ecrit-lost]. > > > > > > Second, if I understood Barbara right, she saying that what users will > > > do on phone is mostly dial numbers; I agree with that, and I think > > > phonebcp > > > agrees with that when it talks about recognition of both local and > > > home dial strings in Section 5. Those largely come out of the user's > > > head as known UI invocations; since a user may or may not know > > > the local dial string, both UI invocations have to work. I think > > > we agree on that, and that the current phonebcp text says it here: > > > > > > ED-3 Endpoints SHOULD recognize dial strings of emergency calls. > If > > > the service provider always knows the location of the device, then > > > the service provider could recognize them. > > > > > > SP-2 Proxy servers SHOULD recognize emergency dial string if for > some > > > reason the endpoint does not recognize them. This cannot be relied > > > upon by the device if the service provider cannot always determine > > > the location of the device. > > > > > > ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the > > > Request-URI of the INVITE. > > > > > > ED-5/SP-4 Local dial strings MUST be recognized. > > > > > > ED-6/SP-5 Home dial strings MAY be recognized. > > > > > > Where I have been focused in this discussion is on what a device does > if > > > it gets > > > back a service Number with a LoST response and cannot use the URIs in > > the > > > set that is returned. I think the what it does if it *can* is clear: > > it > > > uses those > > > URIs. I think where we may disagree is what it does if it cannot: I > > > think either > > > the device or the user should be able to take the service Number and > > > attempt > > > to make a call (either on that phone or another) using just the > service > > > Number. > > > The particular case in my head is the one where a device with a > cellular > > > data connection that would normally complete this using SIP finds it > > > cannot > > > and falls back to a circuit-switched call instead (e.g. 1xRTT). That > , > > in > > > essence, > > > treats the service Number as both a dialstring and more-or-less as the > > > source > > > of a constructed Tel URI. > > > > > > Possibly we disagree on this point, and I'd be interested to know > > whether > > > we > > > do or do not. > > > > > > > > > > > > > > > > > > > >> > > > >> Again, this is the base case. If the phone pre-loads LoST > > information > > > >> and gets mappings beyond those for which the user knows invocation > > > >> UI methods, it might in some cases create them. That might be a > drop > > > >> down list, a voice prompt (now press one for fire, two for police, > > > three > > > >> for medical emergencies, or stay on the line) or something else. > > > > > It might also add the service numbers to a list of patterns in > looks > > > >> for as invocations of emergency services (since an invocation > > > >> results in the same device behavior whether the invocation string > > > >> matches the resulting service number or not, this is okay). But if > > it > > > >> pre-loads this > > > >> information by *replacing* the invocation string 911 with 112 > because > > > of > > > >> local data on the service number, it has not done anyone any > favors. > > > >Agree, but that's not the problem at hand. The problem at hand is > > having > > > >9-1-1 map to urn:service:sos AND having 9-1-1 map to > > > urn:service:sos.police. > > > > > > If 9-1-1 maps to urn:service:sos and 9-1-1 maps to > > urn:service:sos.police > > > and the contact URIs returned in the set are the same, there is no > > > fundamental > > > problem. The call still completes and gets to the right place. If > the > > UI > > > invocation used to make the call was just the dialed string, then I > > would > > > say that the top-level of the hierarchy should be used > (urn:service:sos > > > rather than urn:service:sos.police) as an indicator. > > > > > > If 9-1-1 maps to urn:service:sos and 9-1-1 maps to > > urn:service:sos.police > > > and the contact URIs returned in the set are not the same, I believe > > > the sensible thing to do for a UI invocation based on the dial > > > string only is to route to urn:service:sos; it's the top of the > > hierarchy > > > and if you have no other input, that's what you use. But if there > > > is another way to make the selection (drop down, voice prompt, > > > etc.), you might allow that to make a direct selection of the > > > urn:service:sos.police choice, and then route directly there. > > Forbidding > > > that because there is no dialstring possibility doesn't make sense to > > > me. People may *mostly* use dialstrings on phones, but there are more > > > capable devices out and allowing them to make more precise choices > > > seems reasonable to me if it does not prevent the base case from > > > working. > > > > > > regards, > > > Ted > > > > > > > > > > > > > > > > > > > > > >It's okay to have more than one service number map to the same > service > > > URN, > > > >it's a problem to have more than one service URN map to the same > > service > > > >number. > > > > > > > >Brian > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > 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 Wed Jan 16 16:57:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGGj-0004Km-AE; Wed, 16 Jan 2008 16:57:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGGg-00041l-OK for ecrit@ietf.org; Wed, 16 Jan 2008 16:57:54 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFGGe-0003XU-IT for ecrit@ietf.org; Wed, 16 Jan 2008 16:57:54 -0500 Received: from dhcp100.cs.columbia.edu (dhcp100.cs.columbia.edu [128.59.17.200]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m0GLvme0020837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2008 16:57:48 -0500 (EST) Message-Id: From: Henning Schulzrinne To: "Thomson, Martin" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 16:57:50 -0500 References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org This is not purely hypothetical. There are numbers (118 is an example) that are both emergency numbers and have other functions elsewhere (directory assistance). One reasonable mechanism is to display a warning when you dial an emergency dial string. If you expected pizza, you'll investigate. This case can only arise if that number is emergency at home, non-emergency in the visited country. In other words, the person dialing will probably recognize the source of the problem if given a sensible error message. ("The number you have dialed - 911 - is configured as an emergency number.") The incidence of such cases should be very small, since it only affects tourists and certain short dialing strings. It seems highly unlikely that somebody remembers the US poison control 800# and then dials that while vacationing in Europe. We have this problem today, to some extent: Dialing 112 on a GSM cellphone gets you emergency services anywhere, or so I've been told. I don't know if there's a directory service or pizza parlor using that number outside Europe. Henning On Jan 16, 2008, at 4:34 PM, Thomson, Martin wrote: > Using ordering to imply priority isn't ideal, but as long as it is > very clear in LoST (not phonebcp, this is protocol semantics) it > should work. > > I'm concerned about the question Barbara raised though. > > To provide an extreme example of Barbara's conundrum: What if 911 > called for a pizza in Greenland? I assumed that this could be > addressed by UA configuration on a device that the user owns; that > is, they teach their UA to understand that 911 == urn:service:sos. > However, that doesn't work if they are visiting someone and just > pick up their host's UA. It also doesn't work if you force LoST to > take priority. > > I agree though, forcing a series of questions for an emergency call > isn't a good idea. We need a sensible default behaviour. Perhaps > something along the lines of any service in the urn:service:sos* > path overrides any other service. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 17:31:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGnN-00072S-R9; Wed, 16 Jan 2008 17:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGnM-00072H-V1 for ecrit@ietf.org; Wed, 16 Jan 2008 17:31:40 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFGnL-00049n-CE for ecrit@ietf.org; Wed, 16 Jan 2008 17:31:40 -0500 X-SEF-Processed: 5_0_0_910__2008_01_16_16_43_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 16 Jan 2008 16:43:23 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 16:31:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 16:31:36 -0600 Message-ID: In-Reply-To: <03ff01c8588a$a0c11a40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number Thread-Index: AchYd7a5gyU9CbbyQeW1ez2wvkV7NQAATi9wAANb60AAAOpCcAABRMLA References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> <03ff01c8588a$a0c11a40$640fa8c0@cis.neustar.com> From: "Thomson, Martin" To: "Brian Rosen" , "Ted Hardie" , "Stark, Barbara" , "Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 16 Jan 2008 22:31:39.0216 (UTC) FILETIME=[8F8F4D00:01C8588F] X-Spam-Score: -0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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="===============0904898347==" Errors-To: ecrit-bounces@ietf.org --===============0904898347== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4sIEkgdGhpbmsgdGhhdCB5b3UgbWlzdW5kZXJzdG9vZC4gIFRoZSBMb1NUIF9pc18gb3Zl cnJpZGluZyBjb25maWd1cmF0aW9uLCBidXQgaXQgaXMgZ2l2aW5nIHlvdSBwaXp6YSwgbm90IGEg UFNBUC4gIFlvdSBjYW4ndCBzYXkgdGhhdCB5b3UgZGVmaW5pdGVseSB3YW50IGEgUFNBUCBhbmQg aGF2ZSBMb1NUIG92ZXJyaWRlIGNvbmZpZ3VyYXRpb24gYXQgdGhlIHNhbWUgdGltZS4NCg0KQXMg SGVubmluZyBoYXMgcG9pbnRlZCBvdXQsIHRoaXMgaXMgbm90IGh5cG90aGV0aWNhbC4gIFNvbWVv bmUgd2hvIGlzIHVzZWQgdG8gMTE4IGZvciBlbWVyZ2VuY3kgaXMgZ29pbmcgdG8gZ2V0IGRpcmVj dG9yeSBzZXJ2aWNlcyBpbnN0ZWFkIG9mIGEgUFNBUCBpZiBMb1NUIGlzIGdpdmVuIHN1cHJlbWUg cG93ZXJzIG9mIHByaW9yaXR5Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdDQo+IFNlbnQ6IFRodXJz ZGF5LCAxNyBKYW51YXJ5IDIwMDggODo1NiBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluOyAnVGVk IEhhcmRpZSc7ICdTdGFyaywgQmFyYmFyYSc7ICdTcGVuY2VyIERhd2tpbnMnOw0KPiAnRUNSSVQn DQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFNlcnZpY2VzIHdpdGggc2FtZSBTZXJ2aWNlIE51bWJl cg0KPiANCj4gV2UncmUgbm90IHByb3Bvc2luZyB0byB1c2Ugb3JkZXJpbmcuICBXZSdyZSBwcm9w b3NpbmcgdG8gdXNlIGhpZXJhcmNoeQ0KPiAoc29zDQo+IGlzIGhpZ2hlciB0aGFuIHNvcy5wb2xp Y2UpLiAgSSBhZ3JlZSB0aGF0IHNvcyBpcyBoaWdoZXIgdGhhbiBhbnkgb3RoZXINCj4gc2Vydmlj ZS4NCj4gDQo+IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2h5IHlvdSB0aGluayBmb2xsb3dp bmcgTG9TVCBkb2Vzbid0IHdvcmsuDQo+IElmIHlvdSBhcmUgdmlzaXRpbmcgdGhlIFUuUy4gZnJv bSBHcmVlbmxhbmQsIGFuZCB5b3UgZGlhbCA5LTEtMSwgeW91DQo+IHNob3VsZA0KPiBnZXQgYSBQ U0FQLiAgSWYgeW91IGludGVuZGVkIHRvIG9yZGVyIHBpenphLCB5b3Ugd2lsbCBiZSBzdXJwcmlz ZWQuDQo+IEhvd2V2ZXIsIHlvdSBkZWZpbml0ZWx5IERPTidUIHdhbnQgdG8gZ2V0IHRoZSBsb2Nh bCBwaXp6YSBzZXJ2aWNlLg0KPiBBbHdheXMgcHJlZmVycmluZyBMb1NUIHdvdWxkIGFsd2F5cyBt YWtlIHRoZSBsb2NhbCBkaWFsaW5nIHBsYW4gdGFrZQ0KPiBwcmlvcml0eS4gIFRoYXQgaXMgY29y cmVjdC4gIEFueSBjb25maWd1cmF0aW9uIGlzIHdyb25nLiAgSSBkb24ndCBmZWVsDQo+IGdyZWF0 DQo+IGFib3V0IG5vdCBoYXZpbmcgYSB3YXkgdG8gb3ZlcnJpZGUgTG9TVCwgYnV0IEkgdGhpbmsg aXQncyBhIG11Y2ggbW9yZQ0KPiBsaWtlbHkNCj4gZmFpbHVyZSB0byBoYXZlIGxvY2FsIGNvbmZp Z3VyYXRpb24gYmUgd3JvbmcgdGhlbiB0byBoYXZlIExvU1QgYmUgd3JvbmcuDQo+IA0KPiBCcmlh bg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFRob21zb24s IE1hcnRpbiBbbWFpbHRvOk1hcnRpbi5UaG9tc29uQGFuZHJldy5jb21dDQo+ID4gU2VudDogV2Vk bmVzZGF5LCBKYW51YXJ5IDE2LCAyMDA4IDQ6MzUgUE0NCj4gPiBUbzogQnJpYW4gUm9zZW47IFRl ZCBIYXJkaWU7IFN0YXJrLCBCYXJiYXJhOyBTcGVuY2VyIERhd2tpbnM7IEVDUklUDQo+ID4gU3Vi amVjdDogUkU6IFtFY3JpdF0gU2VydmljZXMgd2l0aCBzYW1lIFNlcnZpY2UgTnVtYmVyDQo+ID4N Cj4gPiBVc2luZyBvcmRlcmluZyB0byBpbXBseSBwcmlvcml0eSBpc24ndCBpZGVhbCwgYnV0IGFz IGxvbmcgYXMgaXQgaXMgdmVyeQ0KPiA+IGNsZWFyIGluIExvU1QgKG5vdCBwaG9uZWJjcCwgdGhp cyBpcyBwcm90b2NvbCBzZW1hbnRpY3MpIGl0IHNob3VsZCB3b3JrLg0KPiA+DQo+ID4gSSdtIGNv bmNlcm5lZCBhYm91dCB0aGUgcXVlc3Rpb24gQmFyYmFyYSByYWlzZWQgdGhvdWdoLg0KPiA+DQo+ ID4gVG8gcHJvdmlkZSBhbiBleHRyZW1lIGV4YW1wbGUgb2YgQmFyYmFyYSdzIGNvbnVuZHJ1bTog V2hhdCBpZiA5MTEgY2FsbGVkDQo+ID4gZm9yIGEgcGl6emEgaW4gR3JlZW5sYW5kPyAgSSBhc3N1 bWVkIHRoYXQgdGhpcyBjb3VsZCBiZSBhZGRyZXNzZWQgYnkgVUENCj4gPiBjb25maWd1cmF0aW9u IG9uIGEgZGV2aWNlIHRoYXQgdGhlIHVzZXIgb3duczsgdGhhdCBpcywgdGhleSB0ZWFjaCB0aGVp cg0KPiBVQQ0KPiA+IHRvIHVuZGVyc3RhbmQgdGhhdCA5MTEgPT0gdXJuOnNlcnZpY2U6c29zLiAg SG93ZXZlciwgdGhhdCBkb2Vzbid0IHdvcmsNCj4gaWYNCj4gPiB0aGV5IGFyZSB2aXNpdGluZyBz b21lb25lIGFuZCBqdXN0IHBpY2sgdXAgdGhlaXIgaG9zdCdzIFVBLiAgSXQgYWxzbw0KPiA+IGRv ZXNuJ3Qgd29yayBpZiB5b3UgZm9yY2UgTG9TVCB0byB0YWtlIHByaW9yaXR5Lg0KPiA+DQo+ID4g SSBhZ3JlZSB0aG91Z2gsIGZvcmNpbmcgYSBzZXJpZXMgb2YgcXVlc3Rpb25zIGZvciBhbiBlbWVy Z2VuY3kgY2FsbA0KPiBpc24ndA0KPiA+IGEgZ29vZCBpZGVhLiAgV2UgbmVlZCBhIHNlbnNpYmxl IGRlZmF1bHQgYmVoYXZpb3VyLiAgUGVyaGFwcyBzb21ldGhpbmcNCj4gPiBhbG9uZyB0aGUgbGlu ZXMgb2YgYW55IHNlcnZpY2UgaW4gdGhlIHVybjpzZXJ2aWNlOnNvcyogcGF0aCBvdmVycmlkZXMN Cj4gYW55DQo+ID4gb3RoZXIgc2VydmljZS4NCj4gPg0KPiA+IF9NDQo+ID4NCj4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBCcmlhbiBSb3NlbiBbbWFpbHRvOmJy QGJyaWFucm9zZW4ubmV0XQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIDE3IEphbnVhcnkgMjAwOCA3 OjA3IEFNDQo+ID4gPiBUbzogJ1RlZCBIYXJkaWUnOyAnU3RhcmssIEJhcmJhcmEnOyAnU3BlbmNl ciBEYXdraW5zJzsgJ0VDUklUJw0KPiA+ID4gU3ViamVjdDogUkU6IFtFY3JpdF0gU2VydmljZXMg d2l0aCBzYW1lIFNlcnZpY2UgTnVtYmVyDQo+ID4gPg0KPiA+ID4gSSdtIGRvaW5nIGFuIHVwZGF0 ZSB0byBwaG9uZWJjcCBub3csIHNvIEknbGwgZml4IHRoZSB0ZXJtaW5vbG9neSBpc3N1ZS4NCj4g PiA+DQo+ID4gPiBEZWZpbml0ZWx5IGFncmVlIHVzZXJzIHdpbGwgZGlhbCBudW1iZXJzIHRvIHJl YWNoIGVtZXJnZW5jeSBzZXJ2aWNlcy4NCj4gPiBXZQ0KPiA+ID4gZG9uJ3QgbGlrZSBiaWcgcmVk IGVtZXJnZW5jeSBidXR0b25zLiAgSG93ZXZlciwgaXQncyBwb3NzaWJsZSB0aGF0DQo+ID4gYmV0 dGVyDQo+ID4gPiBVSXMgdGhhdCBkb24ndCBoYXZlIHRoZSBwcm9ibGVtcyBvZiBiaWcgcmVkIGVt ZXJnZW5jeSBidXR0b25zIGNhbiBiZQ0KPiA+ID4gZGV2aXNlZCwgYW5kIEkgd291bGRuJ3Qgd2Fu dCB0byBydWxlIHRoZW0gb3V0Lg0KPiA+ID4NCj4gPiA+IElGRiB0aGUgcGhvbmUgaGFzIGFuIGFs dGVybmF0ZSB3YXkgdG8gcGxhY2UgYSBjYWxsICh1c2UgQ1MgaW5zdGVhZCBvZg0KPiA+IFBTKQ0K PiA+ID4gQU5EIGl0cyBQUyBtZWNoYW5pc21zIGZhaWwsIHRoZW4gaW5kZWVkIGl0IGNvdWxkIHVz ZSBhbnkgb2YgdGhlIGRpYWwNCj4gPiA+IHN0cmluZ3MNCj4gPiA+IGl0IGhhcyB0byB0cnkgdG8g cmVhY2ggc29tZW9uZSB3aG8gY2FuIGhlbHAuICBJIHRoaW5rIHRoYXQgc3VjaCBjYXNlcw0KPiA+ IGFyZQ0KPiA+ID4gcHJldHR5IG11Y2ggcmVzdHJpY3RlZCB0byBJTVMgc3lzdGVtcywgYW5kIEkg ZG9uJ3QgdGhpbmsgd2UgbmVlZCB0bw0KPiA+IHNwZW5kDQo+ID4gPiBtdWNoIHRpbWUgb24gdGhl bSwgYnV0IGlmIHRoZXJlIGlzIHN1cHBvcnQsIHdlIGNvdWxkIG1lbnRpb24gaXQgaW4NCj4gPiA+ IHBob25lYmNwLg0KPiA+ID4gSSB0aGluayB0aG9zZSBjYXNlcyBhcmUgcmFyZSBlbm91Z2ggdGhh dCB3ZSBkb24ndCBuZWVkIG11Y2ggZ3VpZGFuY2UNCj4gPiAobGlrZQ0KPiA+ID4gd2hhdCBudW1i ZXIgaGFzIHByaW9yaXR5IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUpLg0KPiA+ID4NCj4gPiA+ IFRoZSBvbmx5IHdheSB5b3UgY2FuIGdldCB0byB0aGUgc2l0dWF0aW9uIHdoZXJlIHlvdSBoYXZl IHR3byBVUklzIGZvcg0KPiA+IHRoZQ0KPiA+ID4gc2FtZSBkaWFsIHN0cmluZyBpcyBzb21ldGhp bmcgbGlrZSB0aGUgY2FzZSBCYXJiYXJhIGRpc2N1c3NlcyAoImhvbWUiDQo+ID4gPiBjb25maWd1 cmF0aW9uICsgInZpc2l0ZWQiIExvU1QgZGlzY292ZXJ5KSwgb3IgdGhlIGNhc2UgZGVzY3JpYmVk IGJlbG93Lg0KPiA+ID4gV2hlbiBkaWFsaW5nIGlzIHVzZWQsIHdlIG11c3QganVzdCB1c2UgYSBy dWxlIChoaWdoZXN0IHBvaW50IGluIHRoZQ0KPiA+ID4gaGllcmFyY2h5LCBMb1NUIHJlc3VsdHMg cHJlZmVycmVkIG92ZXIgb3RoZXIgc291cmNlcykuDQo+ID4gPg0KPiA+ID4gR2VuZXJhbGx5LCBt YWtpbmcgY2hvaWNlcyB3aGVuIHlvdSBhcmUgc3RyZXNzZWQgaXMgdXN1YWxseSBOT1QgYSBnb29k DQo+ID4gaWRlYSwNCj4gPiA+IGFuZCBnZXR0aW5nIHRoZSBjYWxsIHRvIHNvbWVvbmUgQVNBUCBp cyBwcm9iYWJseSBtb3JlIGltcG9ydGFudC4NCj4gPiA+DQo+ID4gPiBJZiB0aGUgTG9TVCBkYXRh YmFzZSBsb29rZWQgbGlrZSB0aGUgZXhhbXBsZSB3ZSdyZSB1c2luZywgdGhlIHJ1bGUNCj4gd291 bGQNCj4gPiA+IHdvcmssIGFuZCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBnZW5lcmF0ZSBhIFVJ IHRoYXQgYWxsb3dlZCBhIHVzZXIgdG8NCj4gPiA+IGNob29zZSBwb2xpY2UvZmlyZS9lbXMgb3Ig b3ZlcmFsbCBlbWVyZ2VuY3ksIHdpdGggdGhlIGNhbGwgZ29pbmcgdG8NCj4gdGhlDQo+ID4gPiBh cHByb3ByaWF0ZSBVUkkuICBUaGF0IG1heSBhY3R1YWxseSBiZSBvZiBzb21lIHVzZSBpZiB3ZSBj b3VsZCBnZXQgdGhlDQo+ID4gVUkNCj4gPiA+IHJpZ2h0LiAgQWxsIHRoZSBVUklzIG1heSBhY3R1 YWxseSByZXNvbHZlIHRvIHRoZSBzYW1lIGRvbWFpbiwgYnV0IHRoZQ0KPiA+IFBTQVANCj4gPiA+ IG1heSBiZSBhYmxlIHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gcHJvZml0YWJseSAodGhlIHVzZXIg aXMgcGFzc2luZw0KPiA+ID4gaW5mb3JtYXRpb24gb24gd2hpY2ggc2VydmljZSB0aGV5IHRoaW5r IHRoZXkgbmVlZCkuICBUaGF0IGNvdWxkDQo+IHByZWxvYWQNCj4gPiA+IGNlcnRhaW4gc2NyZWVu cyBhdCB0aGUgUFNBUC4gIE9mIGNvdXJzZSwgdGhlIGNhbGwgdGFrZXIgbWF5IGRlY2lkZSB0bw0K PiA+ID4gb3ZlcnJpZGUgdGhhdCBiYXNlZCBvbiB0aGUgaW5mb3JtYXRpb24gZ2xlYW5lZCBmcm9t IHRoZSBjYWxsLCBhbmQNCj4gbG9jYWwNCj4gPiA+IHBvbGljeSwgYnV0IGl0IGNvdWxkIHNoYXZl IHNvbWUgdGltZSBvZmYgcmVzcG9uc2UuDQo+ID4gPg0KPiA+ID4gSG93ZXZlciwgaXQgT05MWSB3 b3JrcyBpZiB0aGVyZSBpcyBhIGNsZWFyIHJ1bGUgZm9yIHdoYXQgdGhlIFVBIHNob3VsZA0KPiA+ IGRvDQo+ID4gPiB3aGVuIHRoZSBkaWdpdHMgdGhhdCBtYXAgdG8gdHdvIFVSSXMgaXMgZW50ZXJl ZCwgYW5kIGl0IG9ubHkgd29ya3MgaWYNCj4gPiA+IHNvbWVvbmUgZGV2ZWxvcHMgYSBVSSB0aGF0 IHJlYWxseSBkb2VzIHdvcmsgYmV0dGVyIHRoYW4gZGlhbCBzdHJpbmdzLg0KPiA+ID4NCj4gPiA+ IEJyaWFuDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g PiBGcm9tOiBUZWQgSGFyZGllIFttYWlsdG86aGFyZGllQHF1YWxjb21tLmNvbV0NCj4gPiA+ID4g U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE2LCAyMDA4IDI6NDEgUE0NCj4gPiA+ID4gVG86IEJy aWFuIFJvc2VuOyAnU3RhcmssIEJhcmJhcmEnOyAnU3BlbmNlciBEYXdraW5zJzsgJ0VDUklUJw0K PiA+ID4gPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBTZXJ2aWNlcyB3aXRoIHNhbWUgU2VydmljZSBO dW1iZXINCj4gPiA+ID4NCj4gPiA+ID4gQXQgMTo1MCBQTSAtMDUwMCAxLzE2LzA4LCBCcmlhbiBS b3NlbiB3cm90ZToNCj4gPiA+ID4gPiA+IEkgdGhpbmsgeW91IGhhdmUgdGhlIG1hcHBpbmcgd3Jv bmcuICBUaGUgOTExIHN0cmluZyBkaWFsZWQgYnkNCj4gdGhlDQo+ID4gPiA+ID4+IHVzZXIgaXMg dGhlIFVJIGludm9jYXRpb247IGl0J3MgdGhlIDMtYnV0dG9uIGVxdWl2YWxlbnQgb2YgdGhlDQo+ IGJpZw0KPiA+ID4gPiA+PiByZWQgYnV0dG9uIHRoYXQgc2F5cyAiY2FsbCBmb3IgaGVscCIgaW4g anVyaXNkaWN0aW9ucyB0aGF0IGhhdmUgYQ0KPiA+ID4gPiBzaW5nbGUNCj4gPiA+ID4gPj4gcmVz cG9uc2UgdmlldyBvZiB0aGUgd29ybGQuICBJZiBMb1NUIGhhZCBub3QgYmVlbiBwcmV2aW91c2x5 IHJ1biwNCj4gPiA+ID4gPj4gSSB3b3VsZCBleHBlY3QgaXQgdG8gY2F1c2UgTG9TVCB0byB0YWtl IHRoZSBsb2NhdGlvbiBvZiB0aGUNCj4gZGV2aWNlDQo+ID4gPiA+ID4+IGFuZCBhIHNlcnZpY2Ug dXJuIG9mIHNvcyAodW5hZG9ybmVkLCBzaW5jZSA5MTEgaXMgZ2VuZXJhbCkuICBJdA0KPiA+ID4g c2hvdWxkDQo+ID4gPiA+ID4+IHRoZW4gZ2V0IGJhY2sgYSBzZXQgb2YgVVJJcyBhbmQgYSBzZXJ2 aWNlIG51bWJlci4gIFByZXN1bWluZw0KPiA+ID4gPiA+PiB0aGF0IHRoZSBkZXZpY2UgY2FuIHVz ZSBvbmUgb2YgdGhvc2UgVVJJcywgaXQgd291bGQgdGhlbiBpbnZva2UNCj4gdGhlDQo+ID4gPiA+ ID4+IHByb3RvY29sIHByb2Nlc3NpbmcgYXNzb2NpYXRlZCB3aXRoIHRoZSBVUkkgc2NoZW1lIChT SVAsIGluDQo+ID4gPiA+ID4+IHRoZSBleGFtcGxlcyB3ZSd2ZSBiZWVuIGRpc2N1c3NpbmcpLiAg SWYgaXQgY2Fubm90LCB0aGVuIGl0DQo+ID4gPiA+ID4+IG1pZ2h0IHVzZSB0aGUgc2VydmljZSBO dW1iZXIgdG8gY3JlYXRlIGEgY2lyY3VpdCBzd2l0Y2hlZCBjYWxsLg0KPiA+ID4gPiA+PiBUaGF0 IGNpcmN1aXQgc3dpdGNoZWQgY2FsbCBtaWdodCBiZSB0byAxMTIuDQo+ID4gPiA+ID5IdWg/DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPlRoZSBudW1iZXJzIGNhbWUgZnJvbSBMb1NULiAgRm9yIHRoZSBw aG9uZSB0byByZWNvZ25pemUgdGhlbSwgaXQNCj4gaGFzDQo+ID4gdG8NCj4gPiA+ID4gaGF2ZQ0K PiA+ID4gPiA+dGhlbSwgYW5kIGl0IGdldHMgdGhlbSBmcm9tIExvU1QgcHJpbWFyaWx5LiAgVGhl cmUgQVJFIG90aGVyIHdheXM6DQo+IGl0DQo+ID4gPiBjYW4NCj4gPiA+ID4gPmdldCBkaWFsIHN0 cmluZyB0byBzZXJ2aWNlIG1hcHBpbmdzIGJ5IGNvbmZpZ3VyYXRpb24gZm9yIGV4YW1wbGUuDQo+ ID4gPiA+DQo+ID4gPiA+IEZpcnN0LCBJIGp1c3Qgd2VudCB0byBsb29rIHVwICJzZXJ2aWNlIG51 bWJlciIgaW4gcGhvbmViY3AsIGFuZA0KPiBmb3VuZA0KPiA+ID4gPiB0aGF0IHRoZSBzdHJpbmcg aXNuJ3QgZXZlbiBmb3VuZC4gIEl0IGNvbnNpc3RlbnRseSB1c2VzICJkaWFsDQo+IHN0cmluZyIN Cj4gPiBhcw0KPiA+ID4gPiB5b3UgdXNlIGl0IGFib3ZlLiAgU29tZSByZWZlcmVuY2UgbWFwcGlu ZyAiZGlhbCBzdHJpbmciIGluIHBob25lYmNwDQo+ID4gPiA+IHNwZWNpZmljYWxseSB0byAic2Vy dmljZSBOdW1iZXIiIGluIExvU1Qgc2VlbXMgbGlrZSBhIGdvb2QgaWRlYSwNCj4gPiA+ID4gcHJv YmFibHkgaGVyZToNCj4gPiA+ID4NCj4gPiA+ID4gRUQtNy9TUC02IExvY2FsIGVtZXJnZW5jeSBk aWFsIHN0cmluZ3MgU0hPVUxEIGJlIGRldGVybWluZWQgZnJvbQ0KPiBMb1NUDQo+ID4gPiA+ICAg IFtJLUQuaWV0Zi1lY3JpdC1sb3N0XS4NCj4gPiA+ID4NCj4gPiA+ID4gU2Vjb25kLCBpZiBJIHVu ZGVyc3Rvb2QgQmFyYmFyYSByaWdodCwgc2hlIHNheWluZyB0aGF0IHdoYXQgdXNlcnMNCj4gd2ls bA0KPiA+ID4gPiBkbyBvbiBwaG9uZSBpcyBtb3N0bHkgZGlhbCBudW1iZXJzOyBJIGFncmVlIHdp dGggdGhhdCwgYW5kIEkgdGhpbmsNCj4gPiA+ID4gcGhvbmViY3ANCj4gPiA+ID4gYWdyZWVzIHdp dGggdGhhdCB3aGVuIGl0IHRhbGtzIGFib3V0IHJlY29nbml0aW9uIG9mIGJvdGggbG9jYWwgYW5k DQo+ID4gPiA+IGhvbWUgZGlhbCBzdHJpbmdzIGluIFNlY3Rpb24gNS4gIFRob3NlIGxhcmdlbHkg Y29tZSBvdXQgb2YgdGhlDQo+IHVzZXIncw0KPiA+ID4gPiBoZWFkIGFzIGtub3duIFVJIGludm9j YXRpb25zOyBzaW5jZSBhIHVzZXIgbWF5IG9yIG1heSBub3Qga25vdw0KPiA+ID4gPiB0aGUgbG9j YWwgZGlhbCBzdHJpbmcsIGJvdGggVUkgaW52b2NhdGlvbnMgaGF2ZSB0byB3b3JrLiAgSSB0aGlu aw0KPiA+ID4gPiB3ZSBhZ3JlZSBvbiB0aGF0LCBhbmQgdGhhdCB0aGUgY3VycmVudCBwaG9uZWJj cCB0ZXh0IHNheXMgaXQgaGVyZToNCj4gPiA+ID4NCj4gPiA+ID4gICAgRUQtMyBFbmRwb2ludHMg U0hPVUxEIHJlY29nbml6ZSBkaWFsIHN0cmluZ3Mgb2YgZW1lcmdlbmN5IGNhbGxzLg0KPiA+IElm DQo+ID4gPiA+ICAgIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGFsd2F5cyBrbm93cyB0aGUgbG9jYXRp b24gb2YgdGhlIGRldmljZSwNCj4gdGhlbg0KPiA+ID4gPiAgICB0aGUgc2VydmljZSBwcm92aWRl ciBjb3VsZCByZWNvZ25pemUgdGhlbS4NCj4gPiA+ID4NCj4gPiA+ID4gICAgU1AtMiBQcm94eSBz ZXJ2ZXJzIFNIT1VMRCByZWNvZ25pemUgZW1lcmdlbmN5IGRpYWwgc3RyaW5nIGlmIGZvcg0KPiA+ IHNvbWUNCj4gPiA+ID4gICAgcmVhc29uIHRoZSBlbmRwb2ludCBkb2VzIG5vdCByZWNvZ25pemUg dGhlbS4gIFRoaXMgY2Fubm90IGJlDQo+IHJlbGllZA0KPiA+ID4gPiAgICB1cG9uIGJ5IHRoZSBk ZXZpY2UgaWYgdGhlIHNlcnZpY2UgcHJvdmlkZXIgY2Fubm90IGFsd2F5cw0KPiBkZXRlcm1pbmUN Cj4gPiA+ID4gICAgdGhlIGxvY2F0aW9uIG9mIHRoZSBkZXZpY2UuDQo+ID4gPiA+DQo+ID4gPiA+ ICAgIEVELTQvU1AtMyBFbWVyZ2VuY3kgY2FsbHMgTVVTVCBiZSBtYXJrZWQgd2l0aCBhIFNlcnZp Y2UgVVJOIGluDQo+IHRoZQ0KPiA+ID4gPiAgICBSZXF1ZXN0LVVSSSBvZiB0aGUgSU5WSVRFLg0K PiA+ID4gPg0KPiA+ID4gPiAgICBFRC01L1NQLTQgTG9jYWwgZGlhbCBzdHJpbmdzIE1VU1QgYmUg cmVjb2duaXplZC4NCj4gPiA+ID4NCj4gPiA+ID4gICAgRUQtNi9TUC01IEhvbWUgZGlhbCBzdHJp bmdzIE1BWSBiZSByZWNvZ25pemVkLg0KPiA+ID4gPg0KPiA+ID4gPiBXaGVyZSBJIGhhdmUgYmVl biBmb2N1c2VkIGluIHRoaXMgZGlzY3Vzc2lvbiBpcyBvbiB3aGF0IGEgZGV2aWNlDQo+IGRvZXMN Cj4gPiBpZg0KPiA+ID4gPiBpdCBnZXRzDQo+ID4gPiA+IGJhY2sgYSBzZXJ2aWNlIE51bWJlciB3 aXRoIGEgTG9TVCByZXNwb25zZSBhbmQgY2Fubm90IHVzZSB0aGUgVVJJcw0KPiBpbg0KPiA+ID4g dGhlDQo+ID4gPiA+IHNldCB0aGF0IGlzIHJldHVybmVkLiAgSSB0aGluayB0aGUgd2hhdCBpdCBk b2VzIGlmIGl0ICpjYW4qIGlzDQo+IGNsZWFyOg0KPiA+ID4gaXQNCj4gPiA+ID4gdXNlcyB0aG9z ZQ0KPiA+ID4gPiBVUklzLiAgSSB0aGluayB3aGVyZSB3ZSBtYXkgZGlzYWdyZWUgaXMgd2hhdCBp dCBkb2VzIGlmIGl0IGNhbm5vdDoNCj4gSQ0KPiA+ID4gPiB0aGluayBlaXRoZXINCj4gPiA+ID4g dGhlIGRldmljZSBvciB0aGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byB0YWtlIHRoZSBzZXJ2aWNl IE51bWJlciBhbmQNCj4gPiA+ID4gYXR0ZW1wdA0KPiA+ID4gPiB0byBtYWtlIGEgY2FsbCAoZWl0 aGVyIG9uIHRoYXQgcGhvbmUgb3IgYW5vdGhlcikgdXNpbmcganVzdCB0aGUNCj4gPiBzZXJ2aWNl DQo+ID4gPiA+IE51bWJlci4NCj4gPiA+ID4gVGhlIHBhcnRpY3VsYXIgY2FzZSBpbiBteSBoZWFk IGlzIHRoZSBvbmUgd2hlcmUgYSBkZXZpY2Ugd2l0aCBhDQo+ID4gY2VsbHVsYXINCj4gPiA+ID4g ZGF0YSBjb25uZWN0aW9uIHRoYXQgd291bGQgbm9ybWFsbHkgY29tcGxldGUgdGhpcyB1c2luZyBT SVAgZmluZHMgaXQNCj4gPiA+ID4gY2Fubm90DQo+ID4gPiA+IGFuZCBmYWxscyBiYWNrIHRvIGEg Y2lyY3VpdC1zd2l0Y2hlZCBjYWxsIGluc3RlYWQgKGUuZy4gMXhSVFQpLg0KPiBUaGF0DQo+ID4g LA0KPiA+ID4gaW4NCj4gPiA+ID4gZXNzZW5jZSwNCj4gPiA+ID4gdHJlYXRzIHRoZSBzZXJ2aWNl IE51bWJlciBhcyBib3RoIGEgZGlhbHN0cmluZyBhbmQgbW9yZS1vci1sZXNzIGFzDQo+IHRoZQ0K PiA+ID4gPiBzb3VyY2UNCj4gPiA+ID4gb2YgYSBjb25zdHJ1Y3RlZCBUZWwgVVJJLg0KPiA+ID4g Pg0KPiA+ID4gPiBQb3NzaWJseSB3ZSBkaXNhZ3JlZSBvbiB0aGlzIHBvaW50LCBhbmQgSSdkIGJl IGludGVyZXN0ZWQgdG8ga25vdw0KPiA+ID4gd2hldGhlcg0KPiA+ID4gPiB3ZQ0KPiA+ID4gPiBk byBvciBkbyBub3QuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IDxzbmlwPg0KPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEFnYWluLCB0aGlzIGlzIHRoZSBiYXNl IGNhc2UuICBJZiB0aGUgcGhvbmUgcHJlLWxvYWRzIExvU1QNCj4gPiA+IGluZm9ybWF0aW9uDQo+ ID4gPiA+ID4+IGFuZCBnZXRzIG1hcHBpbmdzIGJleW9uZCB0aG9zZSBmb3Igd2hpY2ggdGhlIHVz ZXIga25vd3MNCj4gaW52b2NhdGlvbg0KPiA+ID4gPiA+PiBVSSBtZXRob2RzLCBpdCBtaWdodCBp biBzb21lIGNhc2VzIGNyZWF0ZSB0aGVtLiAgVGhhdCBtaWdodCBiZSBhDQo+ID4gZHJvcA0KPiA+ ID4gPiA+PiBkb3duIGxpc3QsIGEgdm9pY2UgcHJvbXB0IChub3cgcHJlc3Mgb25lIGZvciBmaXJl LCB0d28gZm9yIHBvbGljZSwNCj4gPiA+ID4gdGhyZWUNCj4gPiA+ID4gPj4gZm9yIG1lZGljYWwg ZW1lcmdlbmNpZXMsIG9yIHN0YXkgb24gdGhlIGxpbmUpIG9yIHNvbWV0aGluZyBlbHNlLg0KPiA+ ID4gPiA+ID4gSXQgbWlnaHQgYWxzbyBhZGQgdGhlIHNlcnZpY2UgbnVtYmVycyB0byBhIGxpc3Qg b2YgcGF0dGVybnMgaW4NCj4gPiBsb29rcw0KPiA+ID4gPiA+PiBmb3IgYXMgaW52b2NhdGlvbnMg b2YgZW1lcmdlbmN5IHNlcnZpY2VzIChzaW5jZSBhbiBpbnZvY2F0aW9uDQo+ID4gPiA+ID4+IHJl c3VsdHMgaW4gdGhlIHNhbWUgZGV2aWNlIGJlaGF2aW9yIHdoZXRoZXIgIHRoZSBpbnZvY2F0aW9u DQo+IHN0cmluZw0KPiA+ID4gPiA+PiBtYXRjaGVzIHRoZSByZXN1bHRpbmcgc2VydmljZSBudW1i ZXIgb3Igbm90LCB0aGlzIGlzIG9rYXkpLiAgQnV0DQo+IGlmDQo+ID4gPiBpdA0KPiA+ID4gPiA+ PiBwcmUtbG9hZHMgdGhpcw0KPiA+ID4gPiA+PiBpbmZvcm1hdGlvbiBieSAqcmVwbGFjaW5nKiB0 aGUgaW52b2NhdGlvbiBzdHJpbmcgOTExIHdpdGggMTEyDQo+ID4gYmVjYXVzZQ0KPiA+ID4gPiBv Zg0KPiA+ID4gPiA+PiBsb2NhbCBkYXRhIG9uIHRoZSBzZXJ2aWNlIG51bWJlciwgaXQgaGFzIG5v dCBkb25lIGFueW9uZSBhbnkNCj4gPiBmYXZvcnMuDQo+ID4gPiA+ID5BZ3JlZSwgYnV0IHRoYXQn cyBub3QgdGhlIHByb2JsZW0gYXQgaGFuZC4gIFRoZSBwcm9ibGVtIGF0IGhhbmQgaXMNCj4gPiA+ IGhhdmluZw0KPiA+ID4gPiA+OS0xLTEgbWFwIHRvIHVybjpzZXJ2aWNlOnNvcyBBTkQgaGF2aW5n IDktMS0xIG1hcCB0bw0KPiA+ID4gPiB1cm46c2VydmljZTpzb3MucG9saWNlLg0KPiA+ID4gPg0K PiA+ID4gPiBJZiA5LTEtMSBtYXBzIHRvIHVybjpzZXJ2aWNlOnNvcyBhbmQgOS0xLTEgbWFwcyB0 bw0KPiA+ID4gdXJuOnNlcnZpY2U6c29zLnBvbGljZQ0KPiA+ID4gPiBhbmQgdGhlIGNvbnRhY3Qg VVJJcyByZXR1cm5lZCBpbiB0aGUgc2V0IGFyZSB0aGUgc2FtZSwgdGhlcmUgaXMgbm8NCj4gPiA+ ID4gZnVuZGFtZW50YWwNCj4gPiA+ID4gcHJvYmxlbS4gIFRoZSBjYWxsIHN0aWxsIGNvbXBsZXRl cyBhbmQgZ2V0cyB0byB0aGUgcmlnaHQgcGxhY2UuICBJZg0KPiA+IHRoZQ0KPiA+ID4gVUkNCj4g PiA+ID4gaW52b2NhdGlvbiB1c2VkIHRvIG1ha2UgdGhlIGNhbGwgd2FzIGp1c3QgdGhlIGRpYWxl ZCBzdHJpbmcsIHRoZW4gSQ0KPiA+ID4gd291bGQNCj4gPiA+ID4gc2F5IHRoYXQgdGhlIHRvcC1s ZXZlbCBvZiB0aGUgaGllcmFyY2h5IHNob3VsZCBiZSB1c2VkDQo+ID4gKHVybjpzZXJ2aWNlOnNv cw0KPiA+ID4gPiByYXRoZXIgdGhhbiB1cm46c2VydmljZTpzb3MucG9saWNlKSBhcyBhbiBpbmRp Y2F0b3IuDQo+ID4gPiA+DQo+ID4gPiA+IElmIDktMS0xIG1hcHMgdG8gdXJuOnNlcnZpY2U6c29z IGFuZCA5LTEtMSBtYXBzIHRvDQo+ID4gPiB1cm46c2VydmljZTpzb3MucG9saWNlDQo+ID4gPiA+ IGFuZCB0aGUgY29udGFjdCBVUklzIHJldHVybmVkIGluIHRoZSBzZXQgYXJlIG5vdCB0aGUgc2Ft ZSwgSSBiZWxpZXZlDQo+ID4gPiA+IHRoZSBzZW5zaWJsZSB0aGluZyB0byBkbyBmb3IgYSBVSSBp bnZvY2F0aW9uIGJhc2VkIG9uIHRoZSBkaWFsDQo+ID4gPiA+IHN0cmluZyBvbmx5IGlzIHRvIHJv dXRlIHRvIHVybjpzZXJ2aWNlOnNvczsgaXQncyB0aGUgdG9wIG9mIHRoZQ0KPiA+ID4gaGllcmFy Y2h5DQo+ID4gPiA+IGFuZCBpZiB5b3UgaGF2ZSBubyBvdGhlciBpbnB1dCwgdGhhdCdzIHdoYXQg eW91IHVzZS4gIEJ1dCBpZiB0aGVyZQ0KPiA+ID4gPiBpcyBhbm90aGVyIHdheSB0byBtYWtlIHRo ZSBzZWxlY3Rpb24gKGRyb3AgZG93biwgdm9pY2UgcHJvbXB0LA0KPiA+ID4gPiBldGMuKSwgeW91 IG1pZ2h0IGFsbG93IHRoYXQgdG8gbWFrZSBhIGRpcmVjdCBzZWxlY3Rpb24gb2YgdGhlDQo+ID4g PiA+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UgY2hvaWNlLCBhbmQgdGhlbiByb3V0ZSBkaXJlY3Rs eSB0aGVyZS4NCj4gPiA+IEZvcmJpZGRpbmcNCj4gPiA+ID4gdGhhdCBiZWNhdXNlIHRoZXJlIGlz IG5vIGRpYWxzdHJpbmcgcG9zc2liaWxpdHkgZG9lc24ndCBtYWtlIHNlbnNlDQo+IHRvDQo+ID4g PiA+IG1lLiAgUGVvcGxlIG1heSAqbW9zdGx5KiB1c2UgZGlhbHN0cmluZ3Mgb24gcGhvbmVzLCBi dXQgdGhlcmUgYXJlDQo+IG1vcmUNCj4gPiA+ID4gY2FwYWJsZSBkZXZpY2VzIG91dCBhbmQgYWxs b3dpbmcgdGhlbSB0byBtYWtlIG1vcmUgcHJlY2lzZSBjaG9pY2VzDQo+ID4gPiA+IHNlZW1zIHJl YXNvbmFibGUgdG8gbWUgaWYgaXQgZG9lcyBub3QgcHJldmVudCB0aGUgYmFzZSBjYXNlIGZyb20N Cj4gPiA+ID4gd29ya2luZy4NCj4gPiA+ID4NCj4gPiA+ID4gCQkJCXJlZ2FyZHMsDQo+ID4gPiA+ IAkJCQkJVGVkDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+ID5JdCdzIG9rYXkgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIHNlcnZpY2Ug bnVtYmVyIG1hcCB0byB0aGUgc2FtZQ0KPiA+IHNlcnZpY2UNCj4gPiA+ID4gVVJOLA0KPiA+ID4g PiA+aXQncyBhIHByb2JsZW0gdG8gaGF2ZSBtb3JlIHRoYW4gb25lIHNlcnZpY2UgVVJOIG1hcCB0 byB0aGUgc2FtZQ0KPiA+ID4gc2VydmljZQ0KPiA+ID4gPiA+bnVtYmVyLg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID5Ccmlhbg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ID4g PiBFY3JpdEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJl Y2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiBjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5 LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4gPiBJZiB5b3UgaGF2ZSByZWNl aXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4gaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiA+ IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4g PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gW21mMl0NCj4gDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0 YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBl bWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpbbWYyXQ0K --===============0904898347== 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 --===============0904898347==-- From ecrit-bounces@ietf.org Wed Jan 16 17:34:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGpp-00038S-E5; Wed, 16 Jan 2008 17:34:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGpp-00038N-0F for ecrit@ietf.org; Wed, 16 Jan 2008 17:34:13 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFGpn-0004By-Bx for ecrit@ietf.org; Wed, 16 Jan 2008 17:34:12 -0500 X-SEF-Processed: 5_0_0_910__2008_01_16_16_45_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 16 Jan 2008 16:45:54 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 16:34:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 16:34:07 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number Thread-Index: AchYitbrPEc/x+pVQqqVn0pAGDaM3AABLnBA References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> From: "Thomson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 16 Jan 2008 22:34:09.0752 (UTC) FILETIME=[E9494580:01C8588F] X-Spam-Score: -0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ECRIT 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="===============0768019357==" Errors-To: ecrit-bounces@ietf.org --===============0768019357== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4gIFlvdSdsbCBob3BlZnVsbHkgb25seSBoYXZlIGEgZmV3IHNlY29uZHMgYmVmb3Jl IHlvdSBhY3R1YWxseSBjb25uZWN0LCBidXQgYXQgbGVhc3QgeW91IGNhbiB0aGVuIHF1aWNrbHkg YXBvbG9naXNlIChpbiBhbiBhcHByb3ByaWF0ZWx5IGNvbnRyaXRlIHRvbmUsIG9mIGNvdXJzZSkg dG8gdGhlIFBTQVAgb3BlcmF0b3IgYW5kIG5vdCB3YXN0ZSBQU0FQIHJlc291cmNlcy4gIFRoZW4g eW91IGdvIGxvb2tpbmcgZm9yIHBpenphIGluIGEgcGhvbmUgYm9vay4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdz QGNzLmNvbHVtYmlhLmVkdV0NCj4gU2VudDogVGh1cnNkYXksIDE3IEphbnVhcnkgMjAwOCA4OjU4 IEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW4NCj4gQ2M6IEJyaWFuIFJvc2VuOyBUZWQgSGFyZGll OyBTdGFyaywgQmFyYmFyYTsgU3BlbmNlciBEYXdraW5zOyBFQ1JJVA0KPiBTdWJqZWN0OiBSZTog W0Vjcml0XSBTZXJ2aWNlcyB3aXRoIHNhbWUgU2VydmljZSBOdW1iZXINCj4gDQo+IFRoaXMgaXMg bm90IHB1cmVseSBoeXBvdGhldGljYWwuIFRoZXJlIGFyZSBudW1iZXJzICgxMTggaXMgYW4gZXhh bXBsZSkNCj4gdGhhdCBhcmUgYm90aCBlbWVyZ2VuY3kgbnVtYmVycyBhbmQgaGF2ZSBvdGhlciBm dW5jdGlvbnMgZWxzZXdoZXJlDQo+IChkaXJlY3RvcnkgYXNzaXN0YW5jZSkuDQo+IA0KPiBPbmUg cmVhc29uYWJsZSBtZWNoYW5pc20gaXMgdG8gZGlzcGxheSBhIHdhcm5pbmcgd2hlbiB5b3UgZGlh bCBhbg0KPiBlbWVyZ2VuY3kgZGlhbCBzdHJpbmcuIElmIHlvdSBleHBlY3RlZCBwaXp6YSwgeW91 J2xsIGludmVzdGlnYXRlLiBUaGlzDQo+IGNhc2UgY2FuIG9ubHkgYXJpc2UgaWYgdGhhdCBudW1i ZXIgaXMgZW1lcmdlbmN5IGF0IGhvbWUsIG5vbi1lbWVyZ2VuY3kNCj4gaW4gdGhlIHZpc2l0ZWQg Y291bnRyeS4gSW4gb3RoZXIgd29yZHMsIHRoZSBwZXJzb24gZGlhbGluZyB3aWxsDQo+IHByb2Jh Ymx5IHJlY29nbml6ZSB0aGUgc291cmNlIG9mIHRoZSBwcm9ibGVtIGlmIGdpdmVuIGEgc2Vuc2li bGUgZXJyb3INCj4gbWVzc2FnZS4gKCJUaGUgbnVtYmVyIHlvdSBoYXZlIGRpYWxlZCAtIDkxMSAt IGlzIGNvbmZpZ3VyZWQgYXMgYW4NCj4gZW1lcmdlbmN5IG51bWJlci4iKQ0KPiANCj4gVGhlIGlu Y2lkZW5jZSBvZiBzdWNoIGNhc2VzIHNob3VsZCBiZSB2ZXJ5IHNtYWxsLCBzaW5jZSBpdCBvbmx5 DQo+IGFmZmVjdHMgdG91cmlzdHMgYW5kIGNlcnRhaW4gc2hvcnQgZGlhbGluZyBzdHJpbmdzLiBJ dCBzZWVtcyBoaWdobHkNCj4gdW5saWtlbHkgdGhhdCBzb21lYm9keSByZW1lbWJlcnMgdGhlIFVT IHBvaXNvbiBjb250cm9sIDgwMCMgYW5kIHRoZW4NCj4gZGlhbHMgdGhhdCB3aGlsZSB2YWNhdGlv bmluZyBpbiBFdXJvcGUuDQo+IA0KPiBXZSBoYXZlIHRoaXMgcHJvYmxlbSB0b2RheSwgdG8gc29t ZSBleHRlbnQ6IERpYWxpbmcgMTEyIG9uIGEgR1NNDQo+IGNlbGxwaG9uZSBnZXRzIHlvdSBlbWVy Z2VuY3kgc2VydmljZXMgYW55d2hlcmUsIG9yIHNvIEkndmUgYmVlbiB0b2xkLg0KPiBJIGRvbid0 IGtub3cgaWYgdGhlcmUncyBhIGRpcmVjdG9yeSBzZXJ2aWNlIG9yIHBpenphIHBhcmxvciB1c2lu ZyB0aGF0DQo+IG51bWJlciBvdXRzaWRlIEV1cm9wZS4NCj4gDQo+IEhlbm5pbmcNCj4gDQo+IE9u IEphbiAxNiwgMjAwOCwgYXQgNDozNCBQTSwgVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KPiANCj4g PiBVc2luZyBvcmRlcmluZyB0byBpbXBseSBwcmlvcml0eSBpc24ndCBpZGVhbCwgYnV0IGFzIGxv bmcgYXMgaXQgaXMNCj4gPiB2ZXJ5IGNsZWFyIGluIExvU1QgKG5vdCBwaG9uZWJjcCwgdGhpcyBp cyBwcm90b2NvbCBzZW1hbnRpY3MpIGl0DQo+ID4gc2hvdWxkIHdvcmsuDQo+ID4NCj4gPiBJJ20g Y29uY2VybmVkIGFib3V0IHRoZSBxdWVzdGlvbiBCYXJiYXJhIHJhaXNlZCB0aG91Z2guDQo+ID4N Cj4gPiBUbyBwcm92aWRlIGFuIGV4dHJlbWUgZXhhbXBsZSBvZiBCYXJiYXJhJ3MgY29udW5kcnVt OiBXaGF0IGlmIDkxMQ0KPiA+IGNhbGxlZCBmb3IgYSBwaXp6YSBpbiBHcmVlbmxhbmQ/ICBJIGFz c3VtZWQgdGhhdCB0aGlzIGNvdWxkIGJlDQo+ID4gYWRkcmVzc2VkIGJ5IFVBIGNvbmZpZ3VyYXRp b24gb24gYSBkZXZpY2UgdGhhdCB0aGUgdXNlciBvd25zOyB0aGF0DQo+ID4gaXMsIHRoZXkgdGVh Y2ggdGhlaXIgVUEgdG8gdW5kZXJzdGFuZCB0aGF0IDkxMSA9PSB1cm46c2VydmljZTpzb3MuDQo+ ID4gSG93ZXZlciwgdGhhdCBkb2Vzbid0IHdvcmsgaWYgdGhleSBhcmUgdmlzaXRpbmcgc29tZW9u ZSBhbmQganVzdA0KPiA+IHBpY2sgdXAgdGhlaXIgaG9zdCdzIFVBLiAgSXQgYWxzbyBkb2Vzbid0 IHdvcmsgaWYgeW91IGZvcmNlIExvU1QgdG8NCj4gPiB0YWtlIHByaW9yaXR5Lg0KPiA+DQo+ID4g SSBhZ3JlZSB0aG91Z2gsIGZvcmNpbmcgYSBzZXJpZXMgb2YgcXVlc3Rpb25zIGZvciBhbiBlbWVy Z2VuY3kgY2FsbA0KPiA+IGlzbid0IGEgZ29vZCBpZGVhLiAgV2UgbmVlZCBhIHNlbnNpYmxlIGRl ZmF1bHQgYmVoYXZpb3VyLiAgUGVyaGFwcw0KPiA+IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMg b2YgYW55IHNlcnZpY2UgaW4gdGhlIHVybjpzZXJ2aWNlOnNvcyoNCj4gPiBwYXRoIG92ZXJyaWRl cyBhbnkgb3RoZXIgc2VydmljZS4NCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQg b25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndp c2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUg b3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJp dGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============0768019357== 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 --===============0768019357==-- From ecrit-bounces@ietf.org Wed Jan 16 17:48:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFH3z-0008If-Lr; Wed, 16 Jan 2008 17:48:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFH3y-0008G2-Su for ecrit@ietf.org; Wed, 16 Jan 2008 17:48:50 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFH3x-0004Uj-6O for ecrit@ietf.org; Wed, 16 Jan 2008 17:48:50 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JFH3r-0001XQ-GS; Wed, 16 Jan 2008 16:48:44 -0600 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Ted Hardie'" , "'Stark, Barbara'" , "'Spencer Dawkins'" , "'ECRIT'" References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> <03ff01c8588a$a0c11a40$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 17:48:41 -0500 Message-ID: <041a01c85891$f3841140$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchYd7a5gyU9CbbyQeW1ez2wvkV7NQAATi9wAANb60AAAOpCcAABRMLAAAB2RdA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 562cdc9baa87554b29d950396a30cf75 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: , Errors-To: ecrit-bounces@ietf.org I had only meant "LoST overrides" to apply to emergency services. If in fact the visited directory service number is 116, and your home fire emergency number is 1-1-6, and you dial 1-1-6 on your phone while visiting, you probably should get fire. I say "probably", only because I wished it would work that way. It's not really clear to me that it actually should, because it means we need to have escape mechanisms. After all, this is a change from current practice. Currently, the VISITED dial plan holds, not the home dial plan, for most services. Something like Vonage is an exception of course. I wonder if we can actually specify this. We may have to leave it to implementers. Vonage's answer, who does not normally support the visited/home idea may have different needs than a mobile phone system which does. Do we really even have to specify what happens when a visited dial string is NOT an emergency number but it is in the home dial plan? We DO need to specify what happens when the dial string is an emergency number in the local dial plan. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Wednesday, January 16, 2008 5:32 PM > To: Brian Rosen; Ted Hardie; Stark, Barbara; Spencer Dawkins; ECRIT > Subject: RE: [Ecrit] Services with same Service Number > > Brian, I think that you misunderstood. The LoST _is_ overriding > configuration, but it is giving you pizza, not a PSAP. You can't say that > you definitely want a PSAP and have LoST override configuration at the > same time. > > As Henning has pointed out, this is not hypothetical. Someone who is used > to 118 for emergency is going to get directory services instead of a PSAP > if LoST is given supreme powers of priority. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 17 January 2008 8:56 AM > > To: Thomson, Martin; 'Ted Hardie'; 'Stark, Barbara'; 'Spencer Dawkins'; > > 'ECRIT' > > Subject: RE: [Ecrit] Services with same Service Number > > > > We're not proposing to use ordering. We're proposing to use hierarchy > > (sos > > is higher than sos.police). I agree that sos is higher than any other > > service. > > > > I'm not sure I understand why you think following LoST doesn't work. > > If you are visiting the U.S. from Greenland, and you dial 9-1-1, you > > should > > get a PSAP. If you intended to order pizza, you will be surprised. > > However, you definitely DON'T want to get the local pizza service. > > Always preferring LoST would always make the local dialing plan take > > priority. That is correct. Any configuration is wrong. I don't feel > > great > > about not having a way to override LoST, but I think it's a much more > > likely > > failure to have local configuration be wrong then to have LoST be wrong. > > > > Brian > > > > > -----Original Message----- > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > Sent: Wednesday, January 16, 2008 4:35 PM > > > To: Brian Rosen; Ted Hardie; Stark, Barbara; Spencer Dawkins; ECRIT > > > Subject: RE: [Ecrit] Services with same Service Number > > > > > > Using ordering to imply priority isn't ideal, but as long as it is > very > > > clear in LoST (not phonebcp, this is protocol semantics) it should > work. > > > > > > I'm concerned about the question Barbara raised though. > > > > > > To provide an extreme example of Barbara's conundrum: What if 911 > called > > > for a pizza in Greenland? I assumed that this could be addressed by > UA > > > configuration on a device that the user owns; that is, they teach > their > > UA > > > to understand that 911 == urn:service:sos. However, that doesn't work > > if > > > they are visiting someone and just pick up their host's UA. It also > > > doesn't work if you force LoST to take priority. > > > > > > I agree though, forcing a series of questions for an emergency call > > isn't > > > a good idea. We need a sensible default behaviour. Perhaps something > > > along the lines of any service in the urn:service:sos* path overrides > > any > > > other service. > > > > > > _M > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, 17 January 2008 7:07 AM > > > > To: 'Ted Hardie'; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT' > > > > Subject: RE: [Ecrit] Services with same Service Number > > > > > > > > I'm doing an update to phonebcp now, so I'll fix the terminology > issue. > > > > > > > > Definitely agree users will dial numbers to reach emergency > services. > > > We > > > > don't like big red emergency buttons. However, it's possible that > > > better > > > > UIs that don't have the problems of big red emergency buttons can be > > > > devised, and I wouldn't want to rule them out. > > > > > > > > IFF the phone has an alternate way to place a call (use CS instead > of > > > PS) > > > > AND its PS mechanisms fail, then indeed it could use any of the dial > > > > strings > > > > it has to try to reach someone who can help. I think that such > cases > > > are > > > > pretty much restricted to IMS systems, and I don't think we need to > > > spend > > > > much time on them, but if there is support, we could mention it in > > > > phonebcp. > > > > I think those cases are rare enough that we don't need much guidance > > > (like > > > > what number has priority if there is more than one). > > > > > > > > The only way you can get to the situation where you have two URIs > for > > > the > > > > same dial string is something like the case Barbara discusses > ("home" > > > > configuration + "visited" LoST discovery), or the case described > below. > > > > When dialing is used, we must just use a rule (highest point in the > > > > hierarchy, LoST results preferred over other sources). > > > > > > > > Generally, making choices when you are stressed is usually NOT a > good > > > idea, > > > > and getting the call to someone ASAP is probably more important. > > > > > > > > If the LoST database looked like the example we're using, the rule > > would > > > > work, and it would be possible to generate a UI that allowed a user > to > > > > choose police/fire/ems or overall emergency, with the call going to > > the > > > > appropriate URI. That may actually be of some use if we could get > the > > > UI > > > > right. All the URIs may actually resolve to the same domain, but > the > > > PSAP > > > > may be able to use the information profitably (the user is passing > > > > information on which service they think they need). That could > > preload > > > > certain screens at the PSAP. Of course, the call taker may decide > to > > > > override that based on the information gleaned from the call, and > > local > > > > policy, but it could shave some time off response. > > > > > > > > However, it ONLY works if there is a clear rule for what the UA > should > > > do > > > > when the digits that map to two URIs is entered, and it only works > if > > > > someone develops a UI that really does work better than dial > strings. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > > > Sent: Wednesday, January 16, 2008 2:41 PM > > > > > To: Brian Rosen; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT' > > > > > Subject: RE: [Ecrit] Services with same Service Number > > > > > > > > > > At 1:50 PM -0500 1/16/08, Brian Rosen wrote: > > > > > > > I think you have the mapping wrong. The 911 string dialed by > > the > > > > > >> user is the UI invocation; it's the 3-button equivalent of the > > big > > > > > >> red button that says "call for help" in jurisdictions that have > a > > > > > single > > > > > >> response view of the world. If LoST had not been previously > run, > > > > > >> I would expect it to cause LoST to take the location of the > > device > > > > > >> and a service urn of sos (unadorned, since 911 is general). It > > > > should > > > > > >> then get back a set of URIs and a service number. Presuming > > > > > >> that the device can use one of those URIs, it would then invoke > > the > > > > > >> protocol processing associated with the URI scheme (SIP, in > > > > > >> the examples we've been discussing). If it cannot, then it > > > > > >> might use the service Number to create a circuit switched call. > > > > > >> That circuit switched call might be to 112. > > > > > >Huh? > > > > > > > > > > > >The numbers came from LoST. For the phone to recognize them, it > > has > > > to > > > > > have > > > > > >them, and it gets them from LoST primarily. There ARE other > ways: > > it > > > > can > > > > > >get dial string to service mappings by configuration for example. > > > > > > > > > > First, I just went to look up "service number" in phonebcp, and > > found > > > > > that the string isn't even found. It consistently uses "dial > > string" > > > as > > > > > you use it above. Some reference mapping "dial string" in > phonebcp > > > > > specifically to "service Number" in LoST seems like a good idea, > > > > > probably here: > > > > > > > > > > ED-7/SP-6 Local emergency dial strings SHOULD be determined from > > LoST > > > > > [I-D.ietf-ecrit-lost]. > > > > > > > > > > Second, if I understood Barbara right, she saying that what users > > will > > > > > do on phone is mostly dial numbers; I agree with that, and I think > > > > > phonebcp > > > > > agrees with that when it talks about recognition of both local and > > > > > home dial strings in Section 5. Those largely come out of the > > user's > > > > > head as known UI invocations; since a user may or may not know > > > > > the local dial string, both UI invocations have to work. I think > > > > > we agree on that, and that the current phonebcp text says it here: > > > > > > > > > > ED-3 Endpoints SHOULD recognize dial strings of emergency > calls. > > > If > > > > > the service provider always knows the location of the device, > > then > > > > > the service provider could recognize them. > > > > > > > > > > SP-2 Proxy servers SHOULD recognize emergency dial string if > for > > > some > > > > > reason the endpoint does not recognize them. This cannot be > > relied > > > > > upon by the device if the service provider cannot always > > determine > > > > > the location of the device. > > > > > > > > > > ED-4/SP-3 Emergency calls MUST be marked with a Service URN in > > the > > > > > Request-URI of the INVITE. > > > > > > > > > > ED-5/SP-4 Local dial strings MUST be recognized. > > > > > > > > > > ED-6/SP-5 Home dial strings MAY be recognized. > > > > > > > > > > Where I have been focused in this discussion is on what a device > > does > > > if > > > > > it gets > > > > > back a service Number with a LoST response and cannot use the URIs > > in > > > > the > > > > > set that is returned. I think the what it does if it *can* is > > clear: > > > > it > > > > > uses those > > > > > URIs. I think where we may disagree is what it does if it cannot: > > I > > > > > think either > > > > > the device or the user should be able to take the service Number > and > > > > > attempt > > > > > to make a call (either on that phone or another) using just the > > > service > > > > > Number. > > > > > The particular case in my head is the one where a device with a > > > cellular > > > > > data connection that would normally complete this using SIP finds > it > > > > > cannot > > > > > and falls back to a circuit-switched call instead (e.g. 1xRTT). > > That > > > , > > > > in > > > > > essence, > > > > > treats the service Number as both a dialstring and more-or-less as > > the > > > > > source > > > > > of a constructed Tel URI. > > > > > > > > > > Possibly we disagree on this point, and I'd be interested to know > > > > whether > > > > > we > > > > > do or do not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > >> Again, this is the base case. If the phone pre-loads LoST > > > > information > > > > > >> and gets mappings beyond those for which the user knows > > invocation > > > > > >> UI methods, it might in some cases create them. That might be > a > > > drop > > > > > >> down list, a voice prompt (now press one for fire, two for > police, > > > > > three > > > > > >> for medical emergencies, or stay on the line) or something > else. > > > > > > > It might also add the service numbers to a list of patterns in > > > looks > > > > > >> for as invocations of emergency services (since an invocation > > > > > >> results in the same device behavior whether the invocation > > string > > > > > >> matches the resulting service number or not, this is okay). > But > > if > > > > it > > > > > >> pre-loads this > > > > > >> information by *replacing* the invocation string 911 with 112 > > > because > > > > > of > > > > > >> local data on the service number, it has not done anyone any > > > favors. > > > > > >Agree, but that's not the problem at hand. The problem at hand > is > > > > having > > > > > >9-1-1 map to urn:service:sos AND having 9-1-1 map to > > > > > urn:service:sos.police. > > > > > > > > > > If 9-1-1 maps to urn:service:sos and 9-1-1 maps to > > > > urn:service:sos.police > > > > > and the contact URIs returned in the set are the same, there is no > > > > > fundamental > > > > > problem. The call still completes and gets to the right place. > If > > > the > > > > UI > > > > > invocation used to make the call was just the dialed string, then > I > > > > would > > > > > say that the top-level of the hierarchy should be used > > > (urn:service:sos > > > > > rather than urn:service:sos.police) as an indicator. > > > > > > > > > > If 9-1-1 maps to urn:service:sos and 9-1-1 maps to > > > > urn:service:sos.police > > > > > and the contact URIs returned in the set are not the same, I > believe > > > > > the sensible thing to do for a UI invocation based on the dial > > > > > string only is to route to urn:service:sos; it's the top of the > > > > hierarchy > > > > > and if you have no other input, that's what you use. But if there > > > > > is another way to make the selection (drop down, voice prompt, > > > > > etc.), you might allow that to make a direct selection of the > > > > > urn:service:sos.police choice, and then route directly there. > > > > Forbidding > > > > > that because there is no dialstring possibility doesn't make sense > > to > > > > > me. People may *mostly* use dialstrings on phones, but there are > > more > > > > > capable devices out and allowing them to make more precise choices > > > > > seems reasonable to me if it does not prevent the base case from > > > > > working. > > > > > > > > > > regards, > > > > > Ted > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >It's okay to have more than one service number map to the same > > > service > > > > > URN, > > > > > >it's a problem to have more than one service URN map to the same > > > > service > > > > > >number. > > > > > > > > > > > >Brian > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ---------------------------------------------------------------------- > -- > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > 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] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > 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 Wed Jan 16 17:49:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFH4b-00008G-5y; Wed, 16 Jan 2008 17:49:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFH4a-00008A-Ew for ecrit@ietf.org; Wed, 16 Jan 2008 17:49:28 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFH4Z-0004VP-Ok for ecrit@ietf.org; Wed, 16 Jan 2008 17:49:28 -0500 Received: from dhcp100.cs.columbia.edu (dhcp100.cs.columbia.edu [128.59.17.200]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m0GMnMgd003916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2008 17:49:22 -0500 (EST) Message-Id: <94E7822A-CD8C-409D-83F8-7498FBA84E01@cs.columbia.edu> From: Henning Schulzrinne To: "Thomson, Martin" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 17:49:22 -0500 References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> <03ff01c8588a$a0c11a40$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org On Jan 16, 2008, at 5:31 PM, Thomson, Martin wrote: > Brian, I think that you misunderstood. The LoST _is_ overriding > configuration, but it is giving you pizza, not a PSAP. You can't > say that you definitely want a PSAP and have LoST override > configuration at the same time. > > As Henning has pointed out, this is not hypothetical. Someone who > is used to 118 for emergency is going to get directory services > instead of a PSAP if LoST is given supreme powers of priority. I think only the opposite can happen (get police instead of directory assistance), unless LoST service strings are used for directory services, for a yet-to-be-defined urn:service:directory. Also, the case only occurs if the pre-configured home emergency dial string matches another non-emergency services *and* the user dials that number while traveling, thinking they are getting the non-emergency service (e.g., because they saw it advertised in the front section of the phone book). While this is a theoretical problem, I don't see it as a major one that needs fixing. The number of such cases seems small, given that it has to involve 3-digit numbers and tourists. The 118 case is for Finland: http://www.fonecta.com/directory_assistance/index.php http://en.wikipedia.org/wiki/Emergency_telephone_number documents a number of uses of 118 for emergencies, for example, Switzerland and Bolivia. Thus, a Bolivian tourist would have to come to Finland, want to get directory assistance and then find that his phone recognizes that as the home dial string for an ambulance. If this is a problem, the only possible solution is to only recognize a few "universal" emergency numbers as home dial strings (112, 911) and make sure that no other non-emergency service uses those numbers. As I mentioned before, 112 pretty much has achieved that status - you're going to be lonely repairman if you advertise that number for your plumbing service. The problem of having a single dial string for multiple emergency services (sos, sos.police) is a separate one. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 16 18:00:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHFU-0007Sc-O7; Wed, 16 Jan 2008 18:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHFS-0007RA-Ul for ecrit@ietf.org; Wed, 16 Jan 2008 18:00:42 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFHFQ-0004hF-0k for ecrit@ietf.org; Wed, 16 Jan 2008 18:00:42 -0500 X-SEF-Processed: 5_0_0_910__2008_01_16_17_12_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 16 Jan 2008 17:12:24 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 17:00:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Services with same Service Number Date: Wed, 16 Jan 2008 17:00:36 -0600 Message-ID: In-Reply-To: <041a01c85891$f3841140$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number Thread-Index: AchYd7a5gyU9CbbyQeW1ez2wvkV7NQAATi9wAANb60AAAOpCcAABRMLAAAB2RdAAAJAWgA== References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640fa8c0@cis.neustar.com><186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p><03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <03e001c8587b$5621b350$640fa8c0@cis.neustar.com> <03ff01c8588a$a0c11a40$640fa8c0@cis.neustar.com> <041a01c85891$f3841140$640fa8c0@cis.neustar.com> From: "Thomson, Martin" To: "Brian Rosen" , "Ted Hardie" , "Stark, Barbara" , "Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 16 Jan 2008 23:00:39.0585 (UTC) FILETIME=[9CE68910:01C85893] X-Spam-Score: -0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec 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="===============1278696710==" Errors-To: ecrit-bounces@ietf.org --===============1278696710== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc291bmRzIGxpa2UgYm90aCB5b3UgYW5kIEhlbm5pbmcgYXJlIHNheWluZyB0aGUgc2FtZSB0 aGluZy4gIEFuZCBpdCBzb3VuZHMgT0sgdG8gbWU6DQoNCl9FbWVyZ2VuY3lfIG51bWJlcnMgaW4g dGhlIGxvY2FsIGRpYWwgcGxhbiBvdmVycnVsZSBhbGwgZWxzZS4NCg0KV2UnbGwgZW5zdXJlIHRo YXQgTG9TVCBydWxlcyBzdXByZW1lIGZvciB0aG9zZS4gIERvIHlvdSB3YW50IGEgc3BlY2lmaWMg b3JkZXI/ICBpLmUuDQoNCkVtZXJnZW5jeSAoTG9jYWwsIGZyb20gTG9TVCkNCkVtZXJnZW5jeSAo SG9tZSkNCk90aGVyLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog QnJpYW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogVGh1cnNkYXks IDE3IEphbnVhcnkgMjAwOCA5OjQ5IEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47ICdUZWQgSGFy ZGllJzsgJ1N0YXJrLCBCYXJiYXJhJzsgJ1NwZW5jZXIgRGF3a2lucyc7DQo+ICdFQ1JJVCcNCj4g U3ViamVjdDogUkU6IFtFY3JpdF0gU2VydmljZXMgd2l0aCBzYW1lIFNlcnZpY2UgTnVtYmVyDQo+ IA0KPiBJIGhhZCBvbmx5IG1lYW50ICJMb1NUIG92ZXJyaWRlcyIgdG8gYXBwbHkgdG8gZW1lcmdl bmN5IHNlcnZpY2VzLiAgSWYgaW4NCj4gZmFjdCB0aGUgdmlzaXRlZCBkaXJlY3Rvcnkgc2Vydmlj ZSBudW1iZXIgaXMgMTE2LCBhbmQgeW91ciBob21lIGZpcmUNCj4gZW1lcmdlbmN5IG51bWJlciBp cyAxLTEtNiwgYW5kIHlvdSBkaWFsIDEtMS02IG9uIHlvdXIgcGhvbmUgd2hpbGUgdmlzaXRpbmcs DQo+IHlvdSBwcm9iYWJseSBzaG91bGQgZ2V0IGZpcmUuICBJIHNheSAicHJvYmFibHkiLCBvbmx5 IGJlY2F1c2UgSSB3aXNoZWQgaXQNCj4gd291bGQgd29yayB0aGF0IHdheS4gIEl0J3Mgbm90IHJl YWxseSBjbGVhciB0byBtZSB0aGF0IGl0IGFjdHVhbGx5IHNob3VsZCwNCj4gYmVjYXVzZSBpdCBt ZWFucyB3ZSBuZWVkIHRvIGhhdmUgZXNjYXBlIG1lY2hhbmlzbXMuICBBZnRlciBhbGwsIHRoaXMg aXMgYQ0KPiBjaGFuZ2UgZnJvbSBjdXJyZW50IHByYWN0aWNlLiAgQ3VycmVudGx5LCB0aGUgVklT SVRFRCBkaWFsIHBsYW4gaG9sZHMsIG5vdA0KPiB0aGUgaG9tZSBkaWFsIHBsYW4sIGZvciBtb3N0 IHNlcnZpY2VzLiAgU29tZXRoaW5nIGxpa2UgVm9uYWdlIGlzIGFuDQo+IGV4Y2VwdGlvbiBvZiBj b3Vyc2UuDQo+IA0KPiBJIHdvbmRlciBpZiB3ZSBjYW4gYWN0dWFsbHkgc3BlY2lmeSB0aGlzLiAg V2UgbWF5IGhhdmUgdG8gbGVhdmUgaXQgdG8NCj4gaW1wbGVtZW50ZXJzLiAgVm9uYWdlJ3MgYW5z d2VyLCB3aG8gZG9lcyBub3Qgbm9ybWFsbHkgc3VwcG9ydCB0aGUNCj4gdmlzaXRlZC9ob21lIGlk ZWEgbWF5IGhhdmUgZGlmZmVyZW50IG5lZWRzIHRoYW4gYSBtb2JpbGUgcGhvbmUgc3lzdGVtDQo+ IHdoaWNoDQo+IGRvZXMuICBEbyB3ZSByZWFsbHkgZXZlbiBoYXZlIHRvIHNwZWNpZnkgd2hhdCBo YXBwZW5zIHdoZW4gYSB2aXNpdGVkIGRpYWwNCj4gc3RyaW5nIGlzIE5PVCBhbiBlbWVyZ2VuY3kg bnVtYmVyIGJ1dCBpdCBpcyBpbiB0aGUgaG9tZSBkaWFsIHBsYW4/ICBXZSBETw0KPiBuZWVkIHRv IHNwZWNpZnkgd2hhdCBoYXBwZW5zIHdoZW4gdGhlIGRpYWwgc3RyaW5nIGlzIGFuIGVtZXJnZW5j eSBudW1iZXINCj4gaW4NCj4gdGhlIGxvY2FsIGRpYWwgcGxhbi4NCj4gDQo+IEJyaWFuDQo+IA0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogVGhvbXNvbiwgTWFydGlu IFttYWlsdG86TWFydGluLlRob21zb25AYW5kcmV3LmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMTYsIDIwMDggNTozMiBQTQ0KPiA+IFRvOiBCcmlhbiBSb3NlbjsgVGVkIEhhcmRp ZTsgU3RhcmssIEJhcmJhcmE7IFNwZW5jZXIgRGF3a2luczsgRUNSSVQNCj4gPiBTdWJqZWN0OiBS RTogW0Vjcml0XSBTZXJ2aWNlcyB3aXRoIHNhbWUgU2VydmljZSBOdW1iZXINCj4gPg0KPiA+IEJy aWFuLCBJIHRoaW5rIHRoYXQgeW91IG1pc3VuZGVyc3Rvb2QuICBUaGUgTG9TVCBfaXNfIG92ZXJy aWRpbmcNCj4gPiBjb25maWd1cmF0aW9uLCBidXQgaXQgaXMgZ2l2aW5nIHlvdSBwaXp6YSwgbm90 IGEgUFNBUC4gIFlvdSBjYW4ndCBzYXkNCj4gdGhhdA0KPiA+IHlvdSBkZWZpbml0ZWx5IHdhbnQg YSBQU0FQIGFuZCBoYXZlIExvU1Qgb3ZlcnJpZGUgY29uZmlndXJhdGlvbiBhdCB0aGUNCj4gPiBz YW1lIHRpbWUuDQo+ID4NCj4gPiBBcyBIZW5uaW5nIGhhcyBwb2ludGVkIG91dCwgdGhpcyBpcyBu b3QgaHlwb3RoZXRpY2FsLiAgU29tZW9uZSB3aG8gaXMNCj4gdXNlZA0KPiA+IHRvIDExOCBmb3Ig ZW1lcmdlbmN5IGlzIGdvaW5nIHRvIGdldCBkaXJlY3Rvcnkgc2VydmljZXMgaW5zdGVhZCBvZiBh DQo+IFBTQVANCj4gPiBpZiBMb1NUIGlzIGdpdmVuIHN1cHJlbWUgcG93ZXJzIG9mIHByaW9yaXR5 Lg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQnJp YW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gPiA+IFNlbnQ6IFRodXJzZGF5 LCAxNyBKYW51YXJ5IDIwMDggODo1NiBBTQ0KPiA+ID4gVG86IFRob21zb24sIE1hcnRpbjsgJ1Rl ZCBIYXJkaWUnOyAnU3RhcmssIEJhcmJhcmEnOyAnU3BlbmNlcg0KPiBEYXdraW5zJzsNCj4gPiA+ ICdFQ1JJVCcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFNlcnZpY2VzIHdpdGggc2FtZSBT ZXJ2aWNlIE51bWJlcg0KPiA+ID4NCj4gPiA+IFdlJ3JlIG5vdCBwcm9wb3NpbmcgdG8gdXNlIG9y ZGVyaW5nLiAgV2UncmUgcHJvcG9zaW5nIHRvIHVzZSBoaWVyYXJjaHkNCj4gPiA+IChzb3MNCj4g PiA+IGlzIGhpZ2hlciB0aGFuIHNvcy5wb2xpY2UpLiAgSSBhZ3JlZSB0aGF0IHNvcyBpcyBoaWdo ZXIgdGhhbiBhbnkgb3RoZXINCj4gPiA+IHNlcnZpY2UuDQo+ID4gPg0KPiA+ID4gSSdtIG5vdCBz dXJlIEkgdW5kZXJzdGFuZCB3aHkgeW91IHRoaW5rIGZvbGxvd2luZyBMb1NUIGRvZXNuJ3Qgd29y ay4NCj4gPiA+IElmIHlvdSBhcmUgdmlzaXRpbmcgdGhlIFUuUy4gZnJvbSBHcmVlbmxhbmQsIGFu ZCB5b3UgZGlhbCA5LTEtMSwgeW91DQo+ID4gPiBzaG91bGQNCj4gPiA+IGdldCBhIFBTQVAuICBJ ZiB5b3UgaW50ZW5kZWQgdG8gb3JkZXIgcGl6emEsIHlvdSB3aWxsIGJlIHN1cnByaXNlZC4NCj4g PiA+IEhvd2V2ZXIsIHlvdSBkZWZpbml0ZWx5IERPTidUIHdhbnQgdG8gZ2V0IHRoZSBsb2NhbCBw aXp6YSBzZXJ2aWNlLg0KPiA+ID4gQWx3YXlzIHByZWZlcnJpbmcgTG9TVCB3b3VsZCBhbHdheXMg bWFrZSB0aGUgbG9jYWwgZGlhbGluZyBwbGFuIHRha2UNCj4gPiA+IHByaW9yaXR5LiAgVGhhdCBp cyBjb3JyZWN0LiAgQW55IGNvbmZpZ3VyYXRpb24gaXMgd3JvbmcuICBJIGRvbid0IGZlZWwNCj4g PiA+IGdyZWF0DQo+ID4gPiBhYm91dCBub3QgaGF2aW5nIGEgd2F5IHRvIG92ZXJyaWRlIExvU1Qs IGJ1dCBJIHRoaW5rIGl0J3MgYSBtdWNoIG1vcmUNCj4gPiA+IGxpa2VseQ0KPiA+ID4gZmFpbHVy ZSB0byBoYXZlIGxvY2FsIGNvbmZpZ3VyYXRpb24gYmUgd3JvbmcgdGhlbiB0byBoYXZlIExvU1Qg YmUNCj4gd3JvbmcuDQo+ID4gPg0KPiA+ID4gQnJpYW4NCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IFRob21zb24sIE1hcnRpbiBbbWFpbHRv Ok1hcnRpbi5UaG9tc29uQGFuZHJldy5jb21dDQo+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFu dWFyeSAxNiwgMjAwOCA0OjM1IFBNDQo+ID4gPiA+IFRvOiBCcmlhbiBSb3NlbjsgVGVkIEhhcmRp ZTsgU3RhcmssIEJhcmJhcmE7IFNwZW5jZXIgRGF3a2luczsgRUNSSVQNCj4gPiA+ID4gU3ViamVj dDogUkU6IFtFY3JpdF0gU2VydmljZXMgd2l0aCBzYW1lIFNlcnZpY2UgTnVtYmVyDQo+ID4gPiA+ DQo+ID4gPiA+IFVzaW5nIG9yZGVyaW5nIHRvIGltcGx5IHByaW9yaXR5IGlzbid0IGlkZWFsLCBi dXQgYXMgbG9uZyBhcyBpdCBpcw0KPiA+IHZlcnkNCj4gPiA+ID4gY2xlYXIgaW4gTG9TVCAobm90 IHBob25lYmNwLCB0aGlzIGlzIHByb3RvY29sIHNlbWFudGljcykgaXQgc2hvdWxkDQo+ID4gd29y ay4NCj4gPiA+ID4NCj4gPiA+ID4gSSdtIGNvbmNlcm5lZCBhYm91dCB0aGUgcXVlc3Rpb24gQmFy YmFyYSByYWlzZWQgdGhvdWdoLg0KPiA+ID4gPg0KPiA+ID4gPiBUbyBwcm92aWRlIGFuIGV4dHJl bWUgZXhhbXBsZSBvZiBCYXJiYXJhJ3MgY29udW5kcnVtOiBXaGF0IGlmIDkxMQ0KPiA+IGNhbGxl ZA0KPiA+ID4gPiBmb3IgYSBwaXp6YSBpbiBHcmVlbmxhbmQ/ICBJIGFzc3VtZWQgdGhhdCB0aGlz IGNvdWxkIGJlIGFkZHJlc3NlZCBieQ0KPiA+IFVBDQo+ID4gPiA+IGNvbmZpZ3VyYXRpb24gb24g YSBkZXZpY2UgdGhhdCB0aGUgdXNlciBvd25zOyB0aGF0IGlzLCB0aGV5IHRlYWNoDQo+ID4gdGhl aXINCj4gPiA+IFVBDQo+ID4gPiA+IHRvIHVuZGVyc3RhbmQgdGhhdCA5MTEgPT0gdXJuOnNlcnZp Y2U6c29zLiAgSG93ZXZlciwgdGhhdCBkb2Vzbid0DQo+IHdvcmsNCj4gPiA+IGlmDQo+ID4gPiA+ IHRoZXkgYXJlIHZpc2l0aW5nIHNvbWVvbmUgYW5kIGp1c3QgcGljayB1cCB0aGVpciBob3N0J3Mg VUEuICBJdCBhbHNvDQo+ID4gPiA+IGRvZXNuJ3Qgd29yayBpZiB5b3UgZm9yY2UgTG9TVCB0byB0 YWtlIHByaW9yaXR5Lg0KPiA+ID4gPg0KPiA+ID4gPiBJIGFncmVlIHRob3VnaCwgZm9yY2luZyBh IHNlcmllcyBvZiBxdWVzdGlvbnMgZm9yIGFuIGVtZXJnZW5jeSBjYWxsDQo+ID4gPiBpc24ndA0K PiA+ID4gPiBhIGdvb2QgaWRlYS4gIFdlIG5lZWQgYSBzZW5zaWJsZSBkZWZhdWx0IGJlaGF2aW91 ci4gIFBlcmhhcHMNCj4gc29tZXRoaW5nDQo+ID4gPiA+IGFsb25nIHRoZSBsaW5lcyBvZiBhbnkg c2VydmljZSBpbiB0aGUgdXJuOnNlcnZpY2U6c29zKiBwYXRoDQo+IG92ZXJyaWRlcw0KPiA+ID4g YW55DQo+ID4gPiA+IG90aGVyIHNlcnZpY2UuDQo+ID4gPiA+DQo+ID4gPiA+IF9NDQo+ID4gPiA+ DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBC cmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPiA+ID4gPiA+IFNlbnQ6IFRo dXJzZGF5LCAxNyBKYW51YXJ5IDIwMDggNzowNyBBTQ0KPiA+ID4gPiA+IFRvOiAnVGVkIEhhcmRp ZSc7ICdTdGFyaywgQmFyYmFyYSc7ICdTcGVuY2VyIERhd2tpbnMnOyAnRUNSSVQnDQo+ID4gPiA+ ID4gU3ViamVjdDogUkU6IFtFY3JpdF0gU2VydmljZXMgd2l0aCBzYW1lIFNlcnZpY2UgTnVtYmVy DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJJ20gZG9pbmcgYW4gdXBkYXRlIHRvIHBob25lYmNwIG5v dywgc28gSSdsbCBmaXggdGhlIHRlcm1pbm9sb2d5DQo+ID4gaXNzdWUuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBEZWZpbml0ZWx5IGFncmVlIHVzZXJzIHdpbGwgZGlhbCBudW1iZXJzIHRvIHJlYWNo IGVtZXJnZW5jeQ0KPiA+IHNlcnZpY2VzLg0KPiA+ID4gPiBXZQ0KPiA+ID4gPiA+IGRvbid0IGxp a2UgYmlnIHJlZCBlbWVyZ2VuY3kgYnV0dG9ucy4gIEhvd2V2ZXIsIGl0J3MgcG9zc2libGUgdGhh dA0KPiA+ID4gPiBiZXR0ZXINCj4gPiA+ID4gPiBVSXMgdGhhdCBkb24ndCBoYXZlIHRoZSBwcm9i bGVtcyBvZiBiaWcgcmVkIGVtZXJnZW5jeSBidXR0b25zIGNhbg0KPiBiZQ0KPiA+ID4gPiA+IGRl dmlzZWQsIGFuZCBJIHdvdWxkbid0IHdhbnQgdG8gcnVsZSB0aGVtIG91dC4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IElGRiB0aGUgcGhvbmUgaGFzIGFuIGFsdGVybmF0ZSB3YXkgdG8gcGxhY2UgYSBj YWxsICh1c2UgQ1MgaW5zdGVhZA0KPiA+IG9mDQo+ID4gPiA+IFBTKQ0KPiA+ID4gPiA+IEFORCBp dHMgUFMgbWVjaGFuaXNtcyBmYWlsLCB0aGVuIGluZGVlZCBpdCBjb3VsZCB1c2UgYW55IG9mIHRo ZQ0KPiBkaWFsDQo+ID4gPiA+ID4gc3RyaW5ncw0KPiA+ID4gPiA+IGl0IGhhcyB0byB0cnkgdG8g cmVhY2ggc29tZW9uZSB3aG8gY2FuIGhlbHAuICBJIHRoaW5rIHRoYXQgc3VjaA0KPiA+IGNhc2Vz DQo+ID4gPiA+IGFyZQ0KPiA+ID4gPiA+IHByZXR0eSBtdWNoIHJlc3RyaWN0ZWQgdG8gSU1TIHN5 c3RlbXMsIGFuZCBJIGRvbid0IHRoaW5rIHdlIG5lZWQNCj4gdG8NCj4gPiA+ID4gc3BlbmQNCj4g PiA+ID4gPiBtdWNoIHRpbWUgb24gdGhlbSwgYnV0IGlmIHRoZXJlIGlzIHN1cHBvcnQsIHdlIGNv dWxkIG1lbnRpb24gaXQgaW4NCj4gPiA+ID4gPiBwaG9uZWJjcC4NCj4gPiA+ID4gPiBJIHRoaW5r IHRob3NlIGNhc2VzIGFyZSByYXJlIGVub3VnaCB0aGF0IHdlIGRvbid0IG5lZWQgbXVjaA0KPiBn dWlkYW5jZQ0KPiA+ID4gPiAobGlrZQ0KPiA+ID4gPiA+IHdoYXQgbnVtYmVyIGhhcyBwcmlvcml0 eSBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBv bmx5IHdheSB5b3UgY2FuIGdldCB0byB0aGUgc2l0dWF0aW9uIHdoZXJlIHlvdSBoYXZlIHR3byBV UklzDQo+ID4gZm9yDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+IHNhbWUgZGlhbCBzdHJpbmcgaXMg c29tZXRoaW5nIGxpa2UgdGhlIGNhc2UgQmFyYmFyYSBkaXNjdXNzZXMNCj4gPiAoImhvbWUiDQo+ ID4gPiA+ID4gY29uZmlndXJhdGlvbiArICJ2aXNpdGVkIiBMb1NUIGRpc2NvdmVyeSksIG9yIHRo ZSBjYXNlIGRlc2NyaWJlZA0KPiA+IGJlbG93Lg0KPiA+ID4gPiA+IFdoZW4gZGlhbGluZyBpcyB1 c2VkLCB3ZSBtdXN0IGp1c3QgdXNlIGEgcnVsZSAoaGlnaGVzdCBwb2ludCBpbg0KPiB0aGUNCj4g PiA+ID4gPiBoaWVyYXJjaHksIExvU1QgcmVzdWx0cyBwcmVmZXJyZWQgb3ZlciBvdGhlciBzb3Vy Y2VzKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEdlbmVyYWxseSwgbWFraW5nIGNob2ljZXMgd2hl biB5b3UgYXJlIHN0cmVzc2VkIGlzIHVzdWFsbHkgTk9UIGENCj4gPiBnb29kDQo+ID4gPiA+IGlk ZWEsDQo+ID4gPiA+ID4gYW5kIGdldHRpbmcgdGhlIGNhbGwgdG8gc29tZW9uZSBBU0FQIGlzIHBy b2JhYmx5IG1vcmUgaW1wb3J0YW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSWYgdGhlIExvU1Qg ZGF0YWJhc2UgbG9va2VkIGxpa2UgdGhlIGV4YW1wbGUgd2UncmUgdXNpbmcsIHRoZSBydWxlDQo+ ID4gPiB3b3VsZA0KPiA+ID4gPiA+IHdvcmssIGFuZCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBn ZW5lcmF0ZSBhIFVJIHRoYXQgYWxsb3dlZCBhDQo+IHVzZXINCj4gPiB0bw0KPiA+ID4gPiA+IGNo b29zZSBwb2xpY2UvZmlyZS9lbXMgb3Igb3ZlcmFsbCBlbWVyZ2VuY3ksIHdpdGggdGhlIGNhbGwg Z29pbmcNCj4gdG8NCj4gPiA+IHRoZQ0KPiA+ID4gPiA+IGFwcHJvcHJpYXRlIFVSSS4gIFRoYXQg bWF5IGFjdHVhbGx5IGJlIG9mIHNvbWUgdXNlIGlmIHdlIGNvdWxkIGdldA0KPiA+IHRoZQ0KPiA+ ID4gPiBVSQ0KPiA+ID4gPiA+IHJpZ2h0LiAgQWxsIHRoZSBVUklzIG1heSBhY3R1YWxseSByZXNv bHZlIHRvIHRoZSBzYW1lIGRvbWFpbiwgYnV0DQo+ID4gdGhlDQo+ID4gPiA+IFBTQVANCj4gPiA+ ID4gPiBtYXkgYmUgYWJsZSB0byB1c2UgdGhlIGluZm9ybWF0aW9uIHByb2ZpdGFibHkgKHRoZSB1 c2VyIGlzIHBhc3NpbmcNCj4gPiA+ID4gPiBpbmZvcm1hdGlvbiBvbiB3aGljaCBzZXJ2aWNlIHRo ZXkgdGhpbmsgdGhleSBuZWVkKS4gIFRoYXQgY291bGQNCj4gPiA+IHByZWxvYWQNCj4gPiA+ID4g PiBjZXJ0YWluIHNjcmVlbnMgYXQgdGhlIFBTQVAuICBPZiBjb3Vyc2UsIHRoZSBjYWxsIHRha2Vy IG1heSBkZWNpZGUNCj4gPiB0bw0KPiA+ID4gPiA+IG92ZXJyaWRlIHRoYXQgYmFzZWQgb24gdGhl IGluZm9ybWF0aW9uIGdsZWFuZWQgZnJvbSB0aGUgY2FsbCwgYW5kDQo+ID4gPiBsb2NhbA0KPiA+ ID4gPiA+IHBvbGljeSwgYnV0IGl0IGNvdWxkIHNoYXZlIHNvbWUgdGltZSBvZmYgcmVzcG9uc2Uu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIb3dldmVyLCBpdCBPTkxZIHdvcmtzIGlmIHRoZXJlIGlz IGEgY2xlYXIgcnVsZSBmb3Igd2hhdCB0aGUgVUENCj4gPiBzaG91bGQNCj4gPiA+ID4gZG8NCj4g PiA+ID4gPiB3aGVuIHRoZSBkaWdpdHMgdGhhdCBtYXAgdG8gdHdvIFVSSXMgaXMgZW50ZXJlZCwg YW5kIGl0IG9ubHkgd29ya3MNCj4gPiBpZg0KPiA+ID4gPiA+IHNvbWVvbmUgZGV2ZWxvcHMgYSBV SSB0aGF0IHJlYWxseSBkb2VzIHdvcmsgYmV0dGVyIHRoYW4gZGlhbA0KPiA+IHN0cmluZ3MuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBCcmlhbg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogVGVkIEhhcmRpZSBbbWFpbHRv OmhhcmRpZUBxdWFsY29tbS5jb21dDQo+ID4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVh cnkgMTYsIDIwMDggMjo0MSBQTQ0KPiA+ID4gPiA+ID4gVG86IEJyaWFuIFJvc2VuOyAnU3Rhcmss IEJhcmJhcmEnOyAnU3BlbmNlciBEYXdraW5zJzsgJ0VDUklUJw0KPiA+ID4gPiA+ID4gU3ViamVj dDogUkU6IFtFY3JpdF0gU2VydmljZXMgd2l0aCBzYW1lIFNlcnZpY2UgTnVtYmVyDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gQXQgMTo1MCBQTSAtMDUwMCAxLzE2LzA4LCBCcmlhbiBSb3NlbiB3 cm90ZToNCj4gPiA+ID4gPiA+ID4gPiBJIHRoaW5rIHlvdSBoYXZlIHRoZSBtYXBwaW5nIHdyb25n LiAgVGhlIDkxMSBzdHJpbmcgZGlhbGVkDQo+IGJ5DQo+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4+ IHVzZXIgaXMgdGhlIFVJIGludm9jYXRpb247IGl0J3MgdGhlIDMtYnV0dG9uIGVxdWl2YWxlbnQg b2YNCj4gdGhlDQo+ID4gPiBiaWcNCj4gPiA+ID4gPiA+ID4+IHJlZCBidXR0b24gdGhhdCBzYXlz ICJjYWxsIGZvciBoZWxwIiBpbiBqdXJpc2RpY3Rpb25zIHRoYXQNCj4gaGF2ZQ0KPiA+IGENCj4g PiA+ID4gPiA+IHNpbmdsZQ0KPiA+ID4gPiA+ID4gPj4gcmVzcG9uc2UgdmlldyBvZiB0aGUgd29y bGQuICBJZiBMb1NUIGhhZCBub3QgYmVlbiBwcmV2aW91c2x5DQo+ID4gcnVuLA0KPiA+ID4gPiA+ ID4gPj4gSSB3b3VsZCBleHBlY3QgaXQgdG8gY2F1c2UgTG9TVCB0byB0YWtlIHRoZSBsb2NhdGlv biBvZiB0aGUNCj4gPiA+IGRldmljZQ0KPiA+ID4gPiA+ID4gPj4gYW5kIGEgc2VydmljZSB1cm4g b2Ygc29zICh1bmFkb3JuZWQsIHNpbmNlIDkxMSBpcyBnZW5lcmFsKS4NCj4gSXQNCj4gPiA+ID4g PiBzaG91bGQNCj4gPiA+ID4gPiA+ID4+IHRoZW4gZ2V0IGJhY2sgYSBzZXQgb2YgVVJJcyBhbmQg YSBzZXJ2aWNlIG51bWJlci4gIFByZXN1bWluZw0KPiA+ID4gPiA+ID4gPj4gdGhhdCB0aGUgZGV2 aWNlIGNhbiB1c2Ugb25lIG9mIHRob3NlIFVSSXMsIGl0IHdvdWxkIHRoZW4NCj4gaW52b2tlDQo+ ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4+IHByb3RvY29sIHByb2Nlc3NpbmcgYXNzb2NpYXRlZCB3 aXRoIHRoZSBVUkkgc2NoZW1lIChTSVAsIGluDQo+ID4gPiA+ID4gPiA+PiB0aGUgZXhhbXBsZXMg d2UndmUgYmVlbiBkaXNjdXNzaW5nKS4gIElmIGl0IGNhbm5vdCwgdGhlbiBpdA0KPiA+ID4gPiA+ ID4gPj4gbWlnaHQgdXNlIHRoZSBzZXJ2aWNlIE51bWJlciB0byBjcmVhdGUgYSBjaXJjdWl0IHN3 aXRjaGVkDQo+IGNhbGwuDQo+ID4gPiA+ID4gPiA+PiBUaGF0IGNpcmN1aXQgc3dpdGNoZWQgY2Fs bCBtaWdodCBiZSB0byAxMTIuDQo+ID4gPiA+ID4gPiA+SHVoPw0KPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPlRoZSBudW1iZXJzIGNhbWUgZnJvbSBMb1NULiAgRm9yIHRoZSBwaG9uZSB0byBy ZWNvZ25pemUgdGhlbSwNCj4gaXQNCj4gPiA+IGhhcw0KPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4g aGF2ZQ0KPiA+ID4gPiA+ID4gPnRoZW0sIGFuZCBpdCBnZXRzIHRoZW0gZnJvbSBMb1NUIHByaW1h cmlseS4gIFRoZXJlIEFSRSBvdGhlcg0KPiA+IHdheXM6DQo+ID4gPiBpdA0KPiA+ID4gPiA+IGNh bg0KPiA+ID4gPiA+ID4gPmdldCBkaWFsIHN0cmluZyB0byBzZXJ2aWNlIG1hcHBpbmdzIGJ5IGNv bmZpZ3VyYXRpb24gZm9yDQo+IGV4YW1wbGUuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gRmly c3QsIEkganVzdCB3ZW50IHRvIGxvb2sgdXAgInNlcnZpY2UgbnVtYmVyIiBpbiBwaG9uZWJjcCwg YW5kDQo+ID4gPiBmb3VuZA0KPiA+ID4gPiA+ID4gdGhhdCB0aGUgc3RyaW5nIGlzbid0IGV2ZW4g Zm91bmQuICBJdCBjb25zaXN0ZW50bHkgdXNlcyAiZGlhbA0KPiA+ID4gc3RyaW5nIg0KPiA+ID4g PiBhcw0KPiA+ID4gPiA+ID4geW91IHVzZSBpdCBhYm92ZS4gIFNvbWUgcmVmZXJlbmNlIG1hcHBp bmcgImRpYWwgc3RyaW5nIiBpbg0KPiA+IHBob25lYmNwDQo+ID4gPiA+ID4gPiBzcGVjaWZpY2Fs bHkgdG8gInNlcnZpY2UgTnVtYmVyIiBpbiBMb1NUIHNlZW1zIGxpa2UgYSBnb29kIGlkZWEsDQo+ ID4gPiA+ID4gPiBwcm9iYWJseSBoZXJlOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEVELTcv U1AtNiBMb2NhbCBlbWVyZ2VuY3kgZGlhbCBzdHJpbmdzIFNIT1VMRCBiZSBkZXRlcm1pbmVkIGZy b20NCj4gPiA+IExvU1QNCj4gPiA+ID4gPiA+ICAgIFtJLUQuaWV0Zi1lY3JpdC1sb3N0XS4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTZWNvbmQsIGlmIEkgdW5kZXJzdG9vZCBCYXJiYXJhIHJp Z2h0LCBzaGUgc2F5aW5nIHRoYXQgd2hhdA0KPiB1c2Vycw0KPiA+ID4gd2lsbA0KPiA+ID4gPiA+ ID4gZG8gb24gcGhvbmUgaXMgbW9zdGx5IGRpYWwgbnVtYmVyczsgSSBhZ3JlZSB3aXRoIHRoYXQs IGFuZCBJDQo+IHRoaW5rDQo+ID4gPiA+ID4gPiBwaG9uZWJjcA0KPiA+ID4gPiA+ID4gYWdyZWVz IHdpdGggdGhhdCB3aGVuIGl0IHRhbGtzIGFib3V0IHJlY29nbml0aW9uIG9mIGJvdGggbG9jYWwN Cj4gYW5kDQo+ID4gPiA+ID4gPiBob21lIGRpYWwgc3RyaW5ncyBpbiBTZWN0aW9uIDUuICBUaG9z ZSBsYXJnZWx5IGNvbWUgb3V0IG9mIHRoZQ0KPiA+ID4gdXNlcidzDQo+ID4gPiA+ID4gPiBoZWFk IGFzIGtub3duIFVJIGludm9jYXRpb25zOyBzaW5jZSBhIHVzZXIgbWF5IG9yIG1heSBub3Qga25v dw0KPiA+ID4gPiA+ID4gdGhlIGxvY2FsIGRpYWwgc3RyaW5nLCBib3RoIFVJIGludm9jYXRpb25z IGhhdmUgdG8gd29yay4gIEkNCj4gdGhpbmsNCj4gPiA+ID4gPiA+IHdlIGFncmVlIG9uIHRoYXQs IGFuZCB0aGF0IHRoZSBjdXJyZW50IHBob25lYmNwIHRleHQgc2F5cyBpdA0KPiBoZXJlOg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgIEVELTMgRW5kcG9pbnRzIFNIT1VMRCByZWNvZ25pemUg ZGlhbCBzdHJpbmdzIG9mIGVtZXJnZW5jeQ0KPiA+IGNhbGxzLg0KPiA+ID4gPiBJZg0KPiA+ID4g PiA+ID4gICAgdGhlIHNlcnZpY2UgcHJvdmlkZXIgYWx3YXlzIGtub3dzIHRoZSBsb2NhdGlvbiBv ZiB0aGUgZGV2aWNlLA0KPiA+ID4gdGhlbg0KPiA+ID4gPiA+ID4gICAgdGhlIHNlcnZpY2UgcHJv dmlkZXIgY291bGQgcmVjb2duaXplIHRoZW0uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAg U1AtMiBQcm94eSBzZXJ2ZXJzIFNIT1VMRCByZWNvZ25pemUgZW1lcmdlbmN5IGRpYWwgc3RyaW5n IGlmDQo+ID4gZm9yDQo+ID4gPiA+IHNvbWUNCj4gPiA+ID4gPiA+ICAgIHJlYXNvbiB0aGUgZW5k cG9pbnQgZG9lcyBub3QgcmVjb2duaXplIHRoZW0uICBUaGlzIGNhbm5vdCBiZQ0KPiA+ID4gcmVs aWVkDQo+ID4gPiA+ID4gPiAgICB1cG9uIGJ5IHRoZSBkZXZpY2UgaWYgdGhlIHNlcnZpY2UgcHJv dmlkZXIgY2Fubm90IGFsd2F5cw0KPiA+ID4gZGV0ZXJtaW5lDQo+ID4gPiA+ID4gPiAgICB0aGUg bG9jYXRpb24gb2YgdGhlIGRldmljZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgICBFRC00 L1NQLTMgRW1lcmdlbmN5IGNhbGxzIE1VU1QgYmUgbWFya2VkIHdpdGggYSBTZXJ2aWNlIFVSTg0K PiBpbg0KPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiAgICBSZXF1ZXN0LVVSSSBvZiB0aGUgSU5WSVRF Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgIEVELTUvU1AtNCBMb2NhbCBkaWFsIHN0cmlu Z3MgTVVTVCBiZSByZWNvZ25pemVkLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgIEVELTYv U1AtNSBIb21lIGRpYWwgc3RyaW5ncyBNQVkgYmUgcmVjb2duaXplZC4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBXaGVyZSBJIGhhdmUgYmVlbiBmb2N1c2VkIGluIHRoaXMgZGlzY3Vzc2lvbiBp cyBvbiB3aGF0IGEgZGV2aWNlDQo+ID4gPiBkb2VzDQo+ID4gPiA+IGlmDQo+ID4gPiA+ID4gPiBp dCBnZXRzDQo+ID4gPiA+ID4gPiBiYWNrIGEgc2VydmljZSBOdW1iZXIgd2l0aCBhIExvU1QgcmVz cG9uc2UgYW5kIGNhbm5vdCB1c2UgdGhlDQo+IFVSSXMNCj4gPiA+IGluDQo+ID4gPiA+ID4gdGhl DQo+ID4gPiA+ID4gPiBzZXQgdGhhdCBpcyByZXR1cm5lZC4gIEkgdGhpbmsgdGhlIHdoYXQgaXQg ZG9lcyBpZiBpdCAqY2FuKiBpcw0KPiA+ID4gY2xlYXI6DQo+ID4gPiA+ID4gaXQNCj4gPiA+ID4g PiA+IHVzZXMgdGhvc2UNCj4gPiA+ID4gPiA+IFVSSXMuICBJIHRoaW5rIHdoZXJlIHdlIG1heSBk aXNhZ3JlZSBpcyB3aGF0IGl0IGRvZXMgaWYgaXQNCj4gY2Fubm90Og0KPiA+ID4gSQ0KPiA+ID4g PiA+ID4gdGhpbmsgZWl0aGVyDQo+ID4gPiA+ID4gPiB0aGUgZGV2aWNlIG9yIHRoZSB1c2VyIHNo b3VsZCBiZSBhYmxlIHRvIHRha2UgdGhlIHNlcnZpY2UgTnVtYmVyDQo+ID4gYW5kDQo+ID4gPiA+ ID4gPiBhdHRlbXB0DQo+ID4gPiA+ID4gPiB0byBtYWtlIGEgY2FsbCAoZWl0aGVyIG9uIHRoYXQg cGhvbmUgb3IgYW5vdGhlcikgdXNpbmcganVzdCB0aGUNCj4gPiA+ID4gc2VydmljZQ0KPiA+ID4g PiA+ID4gTnVtYmVyLg0KPiA+ID4gPiA+ID4gVGhlIHBhcnRpY3VsYXIgY2FzZSBpbiBteSBoZWFk IGlzIHRoZSBvbmUgd2hlcmUgYSBkZXZpY2Ugd2l0aCBhDQo+ID4gPiA+IGNlbGx1bGFyDQo+ID4g PiA+ID4gPiBkYXRhIGNvbm5lY3Rpb24gdGhhdCB3b3VsZCBub3JtYWxseSBjb21wbGV0ZSB0aGlz IHVzaW5nIFNJUA0KPiBmaW5kcw0KPiA+IGl0DQo+ID4gPiA+ID4gPiBjYW5ub3QNCj4gPiA+ID4g PiA+IGFuZCBmYWxscyBiYWNrIHRvIGEgY2lyY3VpdC1zd2l0Y2hlZCBjYWxsIGluc3RlYWQgKGUu Zy4gMXhSVFQpLg0KPiA+ID4gVGhhdA0KPiA+ID4gPiAsDQo+ID4gPiA+ID4gaW4NCj4gPiA+ID4g PiA+IGVzc2VuY2UsDQo+ID4gPiA+ID4gPiB0cmVhdHMgdGhlIHNlcnZpY2UgTnVtYmVyIGFzIGJv dGggYSBkaWFsc3RyaW5nIGFuZCBtb3JlLW9yLWxlc3MNCj4gYXMNCj4gPiA+IHRoZQ0KPiA+ID4g PiA+ID4gc291cmNlDQo+ID4gPiA+ID4gPiBvZiBhIGNvbnN0cnVjdGVkIFRlbCBVUkkuDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gUG9zc2libHkgd2UgZGlzYWdyZWUgb24gdGhpcyBwb2ludCwg YW5kIEknZCBiZSBpbnRlcmVzdGVkIHRvDQo+IGtub3cNCj4gPiA+ID4gPiB3aGV0aGVyDQo+ID4g PiA+ID4gPiB3ZQ0KPiA+ID4gPiA+ID4gZG8gb3IgZG8gbm90Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA8c25pcD4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gQWdhaW4sIHRoaXMgaXMgdGhlIGJhc2UgY2Fz ZS4gIElmIHRoZSBwaG9uZSBwcmUtbG9hZHMgTG9TVA0KPiA+ID4gPiA+IGluZm9ybWF0aW9uDQo+ ID4gPiA+ID4gPiA+PiBhbmQgZ2V0cyBtYXBwaW5ncyBiZXlvbmQgdGhvc2UgZm9yIHdoaWNoIHRo ZSB1c2VyIGtub3dzDQo+ID4gPiBpbnZvY2F0aW9uDQo+ID4gPiA+ID4gPiA+PiBVSSBtZXRob2Rz LCBpdCBtaWdodCBpbiBzb21lIGNhc2VzIGNyZWF0ZSB0aGVtLiAgVGhhdCBtaWdodA0KPiBiZQ0K PiA+IGENCj4gPiA+ID4gZHJvcA0KPiA+ID4gPiA+ID4gPj4gZG93biBsaXN0LCBhIHZvaWNlIHBy b21wdCAobm93IHByZXNzIG9uZSBmb3IgZmlyZSwgdHdvIGZvcg0KPiA+IHBvbGljZSwNCj4gPiA+ ID4gPiA+IHRocmVlDQo+ID4gPiA+ID4gPiA+PiBmb3IgbWVkaWNhbCBlbWVyZ2VuY2llcywgb3Ig c3RheSBvbiB0aGUgbGluZSkgb3Igc29tZXRoaW5nDQo+ID4gZWxzZS4NCj4gPiA+ID4gPiA+ID4g PiBJdCBtaWdodCBhbHNvIGFkZCB0aGUgc2VydmljZSBudW1iZXJzIHRvIGEgbGlzdCBvZiBwYXR0 ZXJucw0KPiBpbg0KPiA+ID4gPiBsb29rcw0KPiA+ID4gPiA+ID4gPj4gZm9yIGFzIGludm9jYXRp b25zIG9mIGVtZXJnZW5jeSBzZXJ2aWNlcyAoc2luY2UgYW4gaW52b2NhdGlvbg0KPiA+ID4gPiA+ ID4gPj4gcmVzdWx0cyBpbiB0aGUgc2FtZSBkZXZpY2UgYmVoYXZpb3Igd2hldGhlciAgdGhlIGlu dm9jYXRpb24NCj4gPiA+IHN0cmluZw0KPiA+ID4gPiA+ID4gPj4gbWF0Y2hlcyB0aGUgcmVzdWx0 aW5nIHNlcnZpY2UgbnVtYmVyIG9yIG5vdCwgdGhpcyBpcyBva2F5KS4NCj4gPiBCdXQNCj4gPiA+ IGlmDQo+ID4gPiA+ID4gaXQNCj4gPiA+ID4gPiA+ID4+IHByZS1sb2FkcyB0aGlzDQo+ID4gPiA+ ID4gPiA+PiBpbmZvcm1hdGlvbiBieSAqcmVwbGFjaW5nKiB0aGUgaW52b2NhdGlvbiBzdHJpbmcg OTExIHdpdGggMTEyDQo+ID4gPiA+IGJlY2F1c2UNCj4gPiA+ID4gPiA+IG9mDQo+ID4gPiA+ID4g PiA+PiBsb2NhbCBkYXRhIG9uIHRoZSBzZXJ2aWNlIG51bWJlciwgaXQgaGFzIG5vdCBkb25lIGFu eW9uZSBhbnkNCj4gPiA+ID4gZmF2b3JzLg0KPiA+ID4gPiA+ID4gPkFncmVlLCBidXQgdGhhdCdz IG5vdCB0aGUgcHJvYmxlbSBhdCBoYW5kLiAgVGhlIHByb2JsZW0gYXQgaGFuZA0KPiA+IGlzDQo+ ID4gPiA+ID4gaGF2aW5nDQo+ID4gPiA+ID4gPiA+OS0xLTEgbWFwIHRvIHVybjpzZXJ2aWNlOnNv cyBBTkQgaGF2aW5nIDktMS0xIG1hcCB0bw0KPiA+ID4gPiA+ID4gdXJuOnNlcnZpY2U6c29zLnBv bGljZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJZiA5LTEtMSBtYXBzIHRvIHVybjpzZXJ2 aWNlOnNvcyBhbmQgOS0xLTEgbWFwcyB0bw0KPiA+ID4gPiA+IHVybjpzZXJ2aWNlOnNvcy5wb2xp Y2UNCj4gPiA+ID4gPiA+IGFuZCB0aGUgY29udGFjdCBVUklzIHJldHVybmVkIGluIHRoZSBzZXQg YXJlIHRoZSBzYW1lLCB0aGVyZSBpcw0KPiBubw0KPiA+ID4gPiA+ID4gZnVuZGFtZW50YWwNCj4g PiA+ID4gPiA+IHByb2JsZW0uICBUaGUgY2FsbCBzdGlsbCBjb21wbGV0ZXMgYW5kIGdldHMgdG8g dGhlIHJpZ2h0IHBsYWNlLg0KPiA+IElmDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+IFVJDQo+ID4g PiA+ID4gPiBpbnZvY2F0aW9uIHVzZWQgdG8gbWFrZSB0aGUgY2FsbCB3YXMganVzdCB0aGUgZGlh bGVkIHN0cmluZywNCj4gdGhlbg0KPiA+IEkNCj4gPiA+ID4gPiB3b3VsZA0KPiA+ID4gPiA+ID4g c2F5IHRoYXQgdGhlIHRvcC1sZXZlbCBvZiB0aGUgaGllcmFyY2h5IHNob3VsZCBiZSB1c2VkDQo+ ID4gPiA+ICh1cm46c2VydmljZTpzb3MNCj4gPiA+ID4gPiA+IHJhdGhlciB0aGFuIHVybjpzZXJ2 aWNlOnNvcy5wb2xpY2UpIGFzIGFuIGluZGljYXRvci4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBJZiA5LTEtMSBtYXBzIHRvIHVybjpzZXJ2aWNlOnNvcyBhbmQgOS0xLTEgbWFwcyB0bw0KPiA+ ID4gPiA+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UNCj4gPiA+ID4gPiA+IGFuZCB0aGUgY29udGFj dCBVUklzIHJldHVybmVkIGluIHRoZSBzZXQgYXJlIG5vdCB0aGUgc2FtZSwgSQ0KPiA+IGJlbGll dmUNCj4gPiA+ID4gPiA+IHRoZSBzZW5zaWJsZSB0aGluZyB0byBkbyBmb3IgYSBVSSBpbnZvY2F0 aW9uIGJhc2VkIG9uIHRoZSBkaWFsDQo+ID4gPiA+ID4gPiBzdHJpbmcgb25seSBpcyB0byByb3V0 ZSB0byB1cm46c2VydmljZTpzb3M7IGl0J3MgdGhlIHRvcCBvZiB0aGUNCj4gPiA+ID4gPiBoaWVy YXJjaHkNCj4gPiA+ID4gPiA+IGFuZCBpZiB5b3UgaGF2ZSBubyBvdGhlciBpbnB1dCwgdGhhdCdz IHdoYXQgeW91IHVzZS4gIEJ1dCBpZg0KPiB0aGVyZQ0KPiA+ID4gPiA+ID4gaXMgYW5vdGhlciB3 YXkgdG8gbWFrZSB0aGUgc2VsZWN0aW9uIChkcm9wIGRvd24sIHZvaWNlIHByb21wdCwNCj4gPiA+ ID4gPiA+IGV0Yy4pLCB5b3UgbWlnaHQgYWxsb3cgdGhhdCB0byBtYWtlIGEgZGlyZWN0IHNlbGVj dGlvbiBvZiB0aGUNCj4gPiA+ID4gPiA+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UgY2hvaWNlLCBh bmQgdGhlbiByb3V0ZSBkaXJlY3RseSB0aGVyZS4NCj4gPiA+ID4gPiBGb3JiaWRkaW5nDQo+ID4g PiA+ID4gPiB0aGF0IGJlY2F1c2UgdGhlcmUgaXMgbm8gZGlhbHN0cmluZyBwb3NzaWJpbGl0eSBk b2Vzbid0IG1ha2UNCj4gc2Vuc2UNCj4gPiA+IHRvDQo+ID4gPiA+ID4gPiBtZS4gIFBlb3BsZSBt YXkgKm1vc3RseSogdXNlIGRpYWxzdHJpbmdzIG9uIHBob25lcywgYnV0IHRoZXJlDQo+IGFyZQ0K PiA+ID4gbW9yZQ0KPiA+ID4gPiA+ID4gY2FwYWJsZSBkZXZpY2VzIG91dCBhbmQgYWxsb3dpbmcg dGhlbSB0byBtYWtlIG1vcmUgcHJlY2lzZQ0KPiBjaG9pY2VzDQo+ID4gPiA+ID4gPiBzZWVtcyBy ZWFzb25hYmxlIHRvIG1lIGlmIGl0IGRvZXMgbm90IHByZXZlbnQgdGhlIGJhc2UgY2FzZSBmcm9t DQo+ID4gPiA+ID4gPiB3b3JraW5nLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IAkJCQlyZWdh cmRzLA0KPiA+ID4gPiA+ID4gCQkJCQlUZWQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID5JdCdzIG9rYXkgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIHNlcnZpY2UgbnVtYmVyIG1hcCB0 byB0aGUgc2FtZQ0KPiA+ID4gPiBzZXJ2aWNlDQo+ID4gPiA+ID4gPiBVUk4sDQo+ID4gPiA+ID4g PiA+aXQncyBhIHByb2JsZW0gdG8gaGF2ZSBtb3JlIHRoYW4gb25lIHNlcnZpY2UgVVJOIG1hcCB0 byB0aGUNCj4gc2FtZQ0KPiA+ID4gPiA+IHNlcnZpY2UNCj4gPiA+ID4gPiA+ID5udW1iZXIuDQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+QnJpYW4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ID4gPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBFY3JpdEBpZXRmLm9yZw0K PiA+ID4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ ID4gPiA+DQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4gLS0NCj4gPiA+IC0tDQo+ID4g PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gVGhpcyBtZXNzYWdlIGlzIGZvciB0 aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+ID4gPiA+IGNvbnRhaW4gcHJp dmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLg0K PiA+ID4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyDQo+ID4gPiA+IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAg QW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCj4gPiA+ID4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk Lg0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+IC0tDQo+ID4gPiAtLQ0KPiA+ID4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IFttZjJdDQo+ID4gPg0KPiA+DQo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFRoaXMg bWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPiA+ IGNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXINCj4gPiBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+ID4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk Lg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiBbbWYyXQ0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBt YXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRl IGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4g IEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============1278696710== 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 --===============1278696710==-- From ecrit-bounces@ietf.org Thu Jan 17 03:35:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQDS-0000jm-LN; Thu, 17 Jan 2008 03:35:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQDQ-0000jg-EZ for ecrit@ietf.org; Thu, 17 Jan 2008 03:35:12 -0500 Received: from fg-out-1718.google.com ([72.14.220.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFQDQ-0004MZ-2U for ecrit@ietf.org; Thu, 17 Jan 2008 03:35:12 -0500 Received: by fg-out-1718.google.com with SMTP id 16so619603fgg.41 for ; Thu, 17 Jan 2008 00:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OIdH0k34euGoAO0lcbrAnitVb/8j0CQdFjpRYnLosJI=; b=qe4heCzm+ENjMHdKPbxCfLI/UYF3KWaPA1vxUHJg11Uej/43iEJ75XgYUj0UpakS5G783IOdIip1VTYNwv/Wj0f3dggfAfyC6p/0FInyjUseYDI/hHaNDjtaEpjrrH1paA9SaXJb8xkUBGSoh51kmOapgy/sonfGsD4bwOI9hEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JeT8vsbgyHJjruR+YmaMjpNYQIZ70WfU+pSzJ+RxkjJRovgjuv9oRkASBK3Y+XkdagBka5Z80EbWhCogR2QXKmnjqeMJ8OpOHYALF7XvtapWpyQwLDiMmNfMeX+IQwLKm0YHoulhzehCml0BfRURVKU0CmwUy2a8/beZFY4ntcA= Received: by 10.82.149.8 with SMTP id w8mr3175961bud.24.1200558910857; Thu, 17 Jan 2008 00:35:10 -0800 (PST) Received: by 10.82.182.18 with HTTP; Thu, 17 Jan 2008 00:35:10 -0800 (PST) Message-ID: Date: Thu, 17 Jan 2008 09:35:10 +0100 From: "Karl Heinz Wolf" To: "James M. Polk" Subject: Re: [Ecrit] Services with same Service Number In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <150c01c8582c$e6854c80$6601a8c0@china.huawei.com> <030d01c85840$772d2e20$640fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com> <033f01c85855$46111c10$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org James, I'm glad my initial question is clear now. On Jan 16, 2008 7:05 PM, James M. Polk wrote: > Ultimately, if a SIP UA gets a single service number back (from LoST) > from a single service URN, it can only contact that single service > destination. If, in your example, LoST returns more than > one service with the *same* service number, this would lead to > confusion unless your SIP UA has some form of configuration and/or > priority of which to use first (if the user dials 911, from your > example, the first URI used is police). Determining the URI priority > of which to use (i.e., configuring the UA) has not been addressed > yet, and might not be within the IETF, as I personally believe this > is a local jurisdiction issue - which will have different outcomes At least there should somewhere be a note that it may happen to have the same service number for more than one service - if you allow that at all. Otherwise implementers won't consider this case. > > In your example, I don't think North Carolina would give back > separate URIs (one each for fire and police), but would give back a > single URI to an ESRP (at the border of the ESInet) or the PSAP > (which would direct the call to whomever they believe should be > contacted to best serve the UA's situation). This was also somehow my expectation. But the LoST Server implementation by Columbia university shows this data I provided in the initial example. So I thought this sample data would represent the way how LoST servers will be provisioned in the US. cheers, karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 17 04:27:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFR2O-0002bH-Eb; Thu, 17 Jan 2008 04:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFR2N-0002SF-5R for ecrit@ietf.org; Thu, 17 Jan 2008 04:27:51 -0500 Received: from fg-out-1718.google.com ([72.14.220.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFR2M-0005JA-QI for ecrit@ietf.org; Thu, 17 Jan 2008 04:27:51 -0500 Received: by fg-out-1718.google.com with SMTP id 16so635438fgg.41 for ; Thu, 17 Jan 2008 01:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SDsUJo3JbA5aMjpyMjPpsYkOVyCjTyfFeVdo0hX/sEc=; b=FkrZ5uTmAd1txhSmBO1qlzwLWnk4zpmo3cqypMpiJieCQ9548SILRzdTc4Qib7OIP6wnuNGtqavEUxzXfoRU5rfWYOLltT2HkKyqS41qNj/3iY8B9yhsYnXiWwEfwI5XiMjTfZ4Crv33LPjQCWR8uu5UfRCx86dtPJUcHCWb/q0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YjC6dSSUao4WMKLYaKoiNas1joRSHzkh6gPtr+28Al5lI5EXrM3I1EDxtNeNIhxM4FN4MeiZtYsFx+eWMdOCQaQTQqVOU/YOKCfN2fcgEaKb58G7eTgqNilfIrR2QyfAddBj836lmQfs9ttNbba5p3I53Bfg7Rc8ldL3qvnGS28= Received: by 10.82.167.5 with SMTP id p5mr3293750bue.2.1200562069587; Thu, 17 Jan 2008 01:27:49 -0800 (PST) Received: by 10.82.182.18 with HTTP; Thu, 17 Jan 2008 01:27:49 -0800 (PST) Message-ID: Date: Thu, 17 Jan 2008 10:27:49 +0100 From: "Karl Heinz Wolf" To: ECRIT In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ecrit] Re: Services with same Service Number 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: , Errors-To: ecrit-bounces@ietf.org Thank you all for your comments. I started this topic because I'm working on an implementation. A few days ago, I found the web page of the columbia university LoST server, and I was curios if my implementation would work with that server. I did not consider the case that there might be multiple services with the same service number before. So when I used the LoST server, and ask my implementation for the 911 mapping it always gives me the last mapping I performed with LoST findService. When the last query was for sos.police, I would be connected to the police. Was the last mapping done for sos.fire, it get the fire uri back. I'm afraid every implementation would do something different. So it believe it is necessary to say somewhere: - is it allowed to have multiple services with the same service number in the LoST database - does urn:service:sos always have to exist even though there are child services? I'm not sure that voice prompts or drop downs to choose a service are a good idea. What about analog telephone adapters and language problems even starting before connecting to a PSAP? And please do not forget my question about listServicesByLocation. cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 17 04:36:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRAg-0001r4-Gd; Thu, 17 Jan 2008 04:36:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRAf-0001qu-44 for ecrit@ietf.org; Thu, 17 Jan 2008 04:36:25 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFRAe-0007He-Pf for ecrit@ietf.org; Thu, 17 Jan 2008 04:36:25 -0500 Received: by fg-out-1718.google.com with SMTP id 16so637871fgg.41 for ; Thu, 17 Jan 2008 01:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=POqERfUoEkfh7EpWYVSJtE1l5ozUZj8GI+MjkYY3XyY=; b=NxvoXnZIo/6NtORe4tHZDVt4iyFzbgjJncGWBv6u8zO5n1dQWuj49BFr+rrzl7Cqrimqwadzv+mfj3/TUQgIu3lgnte+N1RNCCNsUBnxqcvV+rL/vlO1mECvwmRm3Bk+B8SnbLA/GwdZsQWqf5iJnTTZDlmAjaPU7OVk42Xi5iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m9A8zqsB/IfYvQ7baeez+q0BoJs0GvuBrx3Y1PuVzLlTb/Rs20+Gz6/Q6GB/0QRbkNXYNp8e6tolYVolMkYhA+V73n7Ej8wIvsmCGbctQMFxIcCdoy5syapynXCw+TWPo/wExTpQBbvjabyez6xxk8BS2jF+Zck47MntRQpqKaY= Received: by 10.82.167.5 with SMTP id p5mr3306587bue.2.1200562583547; Thu, 17 Jan 2008 01:36:23 -0800 (PST) Received: by 10.82.182.18 with HTTP; Thu, 17 Jan 2008 01:36:23 -0800 (PST) Message-ID: Date: Thu, 17 Jan 2008 10:36:23 +0100 From: "Karl Heinz Wolf" To: "Brian Rosen" Subject: Re: [Ecrit] Services with same Service Number In-Reply-To: <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <186601c85850$44a57060$6601a8c0@china.huawei.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT 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: , Errors-To: ecrit-bounces@ietf.org > It may well be the case that you can get two service numbers for one > service. This would be the case in, for example, the U.K, where both 9-9-9 > and 1-1-2 are acceptable. However, you get that from LoST, or you get it > from configuration and it still gives you service number to service URN. just one question on that: is it allowed to have more than one Element in LoST? It is defined as optional in the XML schema - so there may be zero or one servicenumber element. Is this correct? so, how do you get both numbers from LoST? cheers, karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 18 07:57:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFqmg-00066J-6t; Fri, 18 Jan 2008 07:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFqmf-00065r-CD for ecrit@ietf.org; Fri, 18 Jan 2008 07:57:21 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFqme-0006vB-Be for ecrit@ietf.org; Fri, 18 Jan 2008 07:57:21 -0500 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.193116674; Fri, 18 Jan 2008 07:57:07 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Jan 2008 07:57:07 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Jan 2008 07:57:07 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Services with same Service Number Date: Fri, 18 Jan 2008 07:57:05 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA070A455E@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Services with same Service Number thread-index: AchYd+2EvdWa7tlGQkuIlGH+tmIi6QAAsHkw References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$64 0fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Ted Hardie" , "Brian Rosen" , "Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 18 Jan 2008 12:57:07.0249 (UTC) FILETIME=[A17E1210:01C859D1] X-Spam-Score: 0.2 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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: , Errors-To: ecrit-bounces@ietf.org Ted, I believe I understand your point, now. It sounds like you're saying: If the device recognizes a dial string / service number as being associated with a service urn (either through LoST or configuration), but does not have a routing uri that is usable by a client on the device, then the device ... I can see several ways to come at the question of what "..." is. In phonebcp, there is a requirement that in the absence of a uri, the SIP client will go ahead and send a SIP INVITE with just the service urn. If there is no service urn, then the INVITE is sent with the dialed digits. If we see the case you describe as being a subset of cases where there is no SIP routing uri, then this requirement would apply. But it sounds like you want a different requirement. You seem to be saying that if there is no (usable) uri for the Route header, then a device needs to see if it has a uri that is usable by a different client (and use that if it does); and if it doesn't, but it has a non-IP interface that supports outbound calls, then it should send the call out that interface (using the dialed digits, unless there is some mapping unique to that outbound call interface that says "map these dialed digits or service urn to dial string "). I think that for a LoST server to be configured to know valid service urns and service numbers, and be able to validate a location, but not have SIP routing URIs would be a really bad thing. Since a LoST server cannot know whether or not the device requesting info also has another outbound calling interface, the data in the LoST server must always include SIP routing info. To do otherwise, would be severely negligent on the part of the LoST provider, IMO. Which means that our device requirements should be able to assume that a LoST server provides SIP URIs.=20 This means that the device of interest (one that got a LoST response without a usable uri) would be one which doesn't have a SIP client, but does have other clients and has an outbound non-IP calling interface. Phonebcp doesn't really address such a device. Since SIP can do voice, video, and text, it's not clear to me why we need to spend time on such a device. If we're looking for a way to make sure that emergency calls go over GSM/CDMA, when a cellular device is unable to get its location and/or emergency routing info, I think that such requirements need to rest with 3GPP/3GPP2. Barbara -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com]=20 Sent: Wednesday, January 16, 2008 2:41 PM To: Brian Rosen; Stark, Barbara; 'Spencer Dawkins'; 'ECRIT' Subject: RE: [Ecrit] Services with same Service Number At 1:50 PM -0500 1/16/08, Brian Rosen wrote: > > I think you have the mapping wrong. The 911 string dialed by the >> user is the UI invocation; it's the 3-button equivalent of the big >> red button that says "call for help" in jurisdictions that have a single >> response view of the world. If LoST had not been previously run, >> I would expect it to cause LoST to take the location of the device >> and a service urn of sos (unadorned, since 911 is general). It should >> then get back a set of URIs and a service number. Presuming >> that the device can use one of those URIs, it would then invoke the >> protocol processing associated with the URI scheme (SIP, in >> the examples we've been discussing). If it cannot, then it >> might use the service Number to create a circuit switched call. >> That circuit switched call might be to 112. >Huh? > >The numbers came from LoST. For the phone to recognize them, it has to have >them, and it gets them from LoST primarily. There ARE other ways: it can >get dial string to service mappings by configuration for example. First, I just went to look up "service number" in phonebcp, and found that the string isn't even found. It consistently uses "dial string" as you use it above. Some reference mapping "dial string" in phonebcp specifically to "service Number" in LoST seems like a good idea, probably here: ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST [I-D.ietf-ecrit-lost]. Second, if I understood Barbara right, she saying that what users will do on phone is mostly dial numbers; I agree with that, and I think phonebcp agrees with that when it talks about recognition of both local and home dial strings in Section 5. Those largely come out of the user's head as known UI invocations; since a user may or may not know the local dial string, both UI invocations have to work. I think we agree on that, and that the current phonebcp text says it here: ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device, then the service provider could recognize them. SP-2 Proxy servers SHOULD recognize emergency dial string if for some reason the endpoint does not recognize them. This cannot be relied upon by the device if the service provider cannot always determine the location of the device. ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE. ED-5/SP-4 Local dial strings MUST be recognized. ED-6/SP-5 Home dial strings MAY be recognized. Where I have been focused in this discussion is on what a device does if it gets back a service Number with a LoST response and cannot use the URIs in the set that is returned. I think the what it does if it *can* is clear: it uses those URIs. I think where we may disagree is what it does if it cannot: I think either the device or the user should be able to take the service Number and attempt to make a call (either on that phone or another) using just the service Number. The particular case in my head is the one where a device with a cellular data connection that would normally complete this using SIP finds it cannot and falls back to a circuit-switched call instead (e.g. 1xRTT). That , in essence, treats the service Number as both a dialstring and more-or-less as the source of a constructed Tel URI.=20 Possibly we disagree on this point, and I'd be interested to know whether we do or do not. > >> >> Again, this is the base case. If the phone pre-loads LoST information >> and gets mappings beyond those for which the user knows invocation >> UI methods, it might in some cases create them. That might be a drop >> down list, a voice prompt (now press one for fire, two for police, three >> for medical emergencies, or stay on the line) or something else. > > It might also add the service numbers to a list of patterns in looks >> for as invocations of emergency services (since an invocation >> results in the same device behavior whether the invocation string >> matches the resulting service number or not, this is okay). But if it >> pre-loads this >> information by *replacing* the invocation string 911 with 112 because of >> local data on the service number, it has not done anyone any favors. >Agree, but that's not the problem at hand. The problem at hand is having >9-1-1 map to urn:service:sos AND having 9-1-1 map to urn:service:sos.police. If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police and the contact URIs returned in the set are the same, there is no fundamental problem. The call still completes and gets to the right place. If the UI invocation used to make the call was just the dialed string, then I would say that the top-level of the hierarchy should be used (urn:service:sos rather than urn:service:sos.police) as an indicator.=20 If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police and the contact URIs returned in the set are not the same, I believe the sensible thing to do for a UI invocation based on the dial string only is to route to urn:service:sos; it's the top of the hierarchy and if you have no other input, that's what you use. But if there is another way to make the selection (drop down, voice prompt, etc.), you might allow that to make a direct selection of the urn:service:sos.police choice, and then route directly there. Forbidding that because there is no dialstring possibility doesn't make sense to me. People may *mostly* use dialstrings on phones, but there are more capable devices out and allowing them to make more precise choices seems reasonable to me if it does not prevent the base case from working. regards, Ted >It's okay to have more than one service number map to the same service URN, >it's a problem to have more than one service URN map to the same service >number. > >Brian ***** 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. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 18 11:59:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuYc-0008As-No; Fri, 18 Jan 2008 11:59:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuYb-00081y-4c for ecrit@ietf.org; Fri, 18 Jan 2008 11:59:05 -0500 Received: from wolverine01.qualcomm.com ([199.106.114.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFuYZ-0004Ug-7Q for ecrit@ietf.org; Fri, 18 Jan 2008 11:59:05 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:Date:To:From:Subject: Content-Type; b=rKPfGstHfBvBaFeRGuP3P1o/t9E6ctAM/ONa4sx0jqWRbddVmwivdoip pLNPmNsNapA542F2ieGxIcobK87nqLM3cIy1t4HfrjnTruA2Hfj740F2L Kjbu7gTKnXZLAOEZTgTCdPM8YX1ok2oiqRUplBmuMCc59dEFljVBCP9yp k=; X-IronPort-AV: E=McAfee;i="5100,188,5210"; a="605620" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jan 2008 08:58:50 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0IGwnIF005046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Jan 2008 08:58:50 -0800 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0IGwmnX020765; Fri, 18 Jan 2008 08:58:49 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA070A455E@crexc41p> References: < 150c01c8582c$e6854c80$6601a8c0@china.huawei.com><030d01c85840$772d2e20$640 fa8c0@cis.neustar.com> <186601c85850$44a57060$6601a8c0@china.huawei.com><033f01c85855$46111c10$64 0fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A4180@crexc41p> <03c401c85870$9f6fb9e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA070A455E@crexc41p> Date: Fri, 18 Jan 2008 08:58:47 -0800 To: "Stark, Barbara" , "Brian Rosen" , "Spencer Dawkins" , "ECRIT" From: Ted Hardie Subject: RE: [Ecrit] Services with same Service Number Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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: , Errors-To: ecrit-bounces@ietf.org At 7:57 AM -0500 1/18/08, Stark, Barbara wrote: >Ted, >I believe I understand your point, now. > >It sounds like you're saying: >If the device recognizes a dial string / service number as being >associated with a service urn (either through LoST or configuration), >but does not have a routing uri that is usable by a client on the >device, then the device ... It's important to recognize that this may "that is usable by a client on the device at that moment". There may be cases where the client has SIP but cannot make either a connection to a SIP proxy or directly to the SIP interface of the PSAP. That might be something as simple as a temporary error in a firewall config or something as deliberate as someone DDoSing the SIP interface of the PSAP. >I can see several ways to come at the question of what "..." is. >In phonebcp, there is a requirement that in the absence of a uri, the >SIP client will go ahead and send a SIP INVITE with just the service >urn. If there is no service urn, then the INVITE is sent with the dialed >digits. If we see the case you describe as being a subset of cases where >there is no SIP routing uri, then this requirement would apply. It's difficult for to understand the case where there is no service URN, but I think using the dialed digits here is very similar to saying that you can treat the "service number" returned as the source of a constructed Tel: URI. That means any interface you have (whether it be SIP or something else) might try that constructed Tel: URI. >But it sounds like you want a different requirement. You seem to be >saying that if there is no (usable) uri for the Route header, then a >device needs to see if it has a uri that is usable by a different client >(and use that if it does); and if it doesn't, but it has a non-IP >interface that supports outbound calls, then it should send the call out >that interface (using the dialed digits, unless there is some mapping >unique to that outbound call interface that says "map these dialed >digits or service urn to dial string "). Yes. This is obviously not a first choice, but if you've gotten back a service Number and you have other clients/non-IP interfaces, trying that number on those interfaces makes sense. >I think that for a LoST server to be configured to know valid service >urns and service numbers, and be able to validate a location, but not >have SIP routing URIs would be a really bad thing. Since a LoST server >cannot know whether or not the device requesting info also has another >outbound calling interface, the data in the LoST server must always >include SIP routing info. To do otherwise, would be severely negligent >on the part of the LoST provider, IMO. > >Which means that our device requirements should be able to assume that a >LoST server provides SIP URIs. See above. It's not about whether the LoST server provides SIP URIs; it's about whether the client can use them. A bad firewall config, a DoS attack, and client update/virus that munges the SIP client can all temporarily blank the usability of that URI. If we're providing additional data (the service Number), treating it as usable for more than a UI matching algorithm makes sense to me. >This means that the device of interest (one that got a LoST response >without a usable uri) would be one which doesn't have a SIP client, but >does have other clients and has an outbound non-IP calling interface. >Phonebcp doesn't really address such a device. Since SIP can do voice, >video, and text, it's not clear to me why we need to spend time on such >a device. > >If we're looking for a way to make sure that emergency calls go over >GSM/CDMA, when a cellular device is unable to get its location and/or >emergency routing info, I think that such requirements need to rest with >3GPP/3GPP2. >Barbara Devices that have more than one interface are now common, and they may get more common; folks that have more than one device are really, really common. Some of those devices and interfaces can make phone calls without SIP. Let's recognize that fact. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 21 02:58:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGrYM-0008Dt-1d; Mon, 21 Jan 2008 02:58:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGrYL-0008Dg-AI for ecrit@ietf.org; Mon, 21 Jan 2008 02:58:45 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JGrYK-0006Q7-NN for ecrit@ietf.org; Mon, 21 Jan 2008 02:58:45 -0500 Received: (qmail invoked by alias); 21 Jan 2008 07:52:03 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp032) with SMTP; 21 Jan 2008 08:52:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18UxUUlns8UUT3PGiCGM8xdI/5yGTrlxa68NEIaRp tEL3PN56wLCHQH Message-ID: <47944F22.1080901@gmx.net> Date: Mon, 21 Jan 2008 09:52:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: keyprov@ietf.org, dime@ietf.org, ECRIT , "nsis@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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Ecrit] FW: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA 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: , Errors-To: ecrit-bounces@ietf.org Please keep the deadlines in mind. Ciao Hannes -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org] Sent: Friday, January 18, 2008 12:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA There are two (2) Internet-Draft cutoff dates for the 71st IETF Meeting in Philadelphia, PA, USA: February 18th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 11th at 9:00 AM ET (14:00 UTC/GMT). February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 10th at 9:00 AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to internet-drafts@ietf.org. If you are submitting a version -00 WG draft that replaces non-WG draft, then you must submit it manually as the current IDST cannot handle replacements. Please be sure to state that one draft replaces another in the cover note that accompanies your submission. Also, please note that the IDST will not accept drafts submitted after their respective cutoff dates. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 71st IETF Meeting can be found at http://www.ietf.org/meetings/71-cutoff_dates.html. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 03:28:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUn0-0008J6-4N; Thu, 31 Jan 2008 03:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUmy-0008Ip-Cg for ecrit@ietf.org; Thu, 31 Jan 2008 03:28:52 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKUmx-0005pU-U0 for ecrit@ietf.org; Thu, 31 Jan 2008 03:28:52 -0500 Received: (qmail invoked by alias); 31 Jan 2008 08:28:50 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp044) with SMTP; 31 Jan 2008 09:28:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/oxxsuCefotyWAlVcNLyYD3xsfZ8S2DDpYfydTxu dtmH48XNfgrt44 Message-ID: <47A186C1.7080004@gmx.net> Date: Thu, 31 Jan 2008 10:28:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: speermint@ietf.org, ECRIT 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ecrit] Emergency Calls & VoIP Peering 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: , Errors-To: ecrit-bounces@ietf.org Hi all, I wanted to ask you for your opinion since the following issue has been brought forward to me many times already. One deployment mode for the emergency services architecture is to route calls through the user's VoIP provider (VSP) and then towards the PSAP. Since the VSP is typically not in the visited network there is obviously the problem that the emergency SIP call (not the RTP, which would travel directly -- hopefully) needs to be handled properly when it leaves the VSP, potentially traverses some other peering networks, and then finally hits the PSAP. Some folks, particularly those with an IMS background, argue that "everything" should be done locally at the visited network rather than routing the call through the user's VSP where things could potentially go wrong along the path between the PSAP and the VSP. Thoughts about this aspect? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 07:34:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYcM-0000rs-Hn; Thu, 31 Jan 2008 07:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYcK-0000rf-LV; Thu, 31 Jan 2008 07:34:08 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKYcI-0002VJ-EJ; Thu, 31 Jan 2008 07:34:08 -0500 X-SEF-Processed: 5_0_0_910__2008_01_31_06_46_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 31 Jan 2008 06:46:07 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 06:34:06 -0600 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] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 06:34:03 -0600 Message-ID: In-Reply-To: <47A186C1.7080004@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQg References: <47A186C1.7080004@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 31 Jan 2008 12:34:06.0070 (UTC) FILETIME=[919DA160:01C86405] X-Spam-Score: 1.8 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: ecrit-bounces@ietf.org Good question! And one I tried to have discussed late last year.=0D=0A=0D=0A= I don't see any benefit in involving the VSP - for the caller, the VSP,=0D=0A= or the emergency service.=0D=0A=0D=0AIt's been said that the emergency serv= ice wants the subscriber details=0D=0Afrom the VSP. A caller can have subsc= riptions to lots of Internet=0D=0Aservices that also don't need to be invol= ved in the call. Should we also=0D=0Amake emergency calling dependent on th= em=3F=0D=0A=0D=0AI don't think it has to be the same as IMS. IMS requires a= co-operative=0D=0AE-CSCF that is actually part of the access network. With= LoST and a=0D=0Asuitable emergency proxy, there doesn't have to be any dep= endency on the=0D=0Aaccess network to also provide call processing.=0D=0A=0D= =0ANot involving the VSP in the call does not mean that the caller cannot=0D= =0Aprovide callback details (in principle, they could provide multiple=0D=0A= callback options). I'd also be interested in a discussion around=0D=0Aprovi= ding an automatic presence subscription from the emergency network=0D=0Aits= elf - with a temporary callback number. As long as the emergency=0D=0Acalli= ng device is attached to the Internet, it should be able to stay=0D=0Aregis= tered with that temporary subscription and also do regular location=0D=0Aup= dates to it.=0D=0A=0D=0AMany of the most convoluted issues that have arisen= in this forum have=0D=0Abeen around the challenges that having the VSP inv= olved in call routing=0D=0Aintroduces (the need for forest guides etc). Sin= ce direct-calling is a=0D=0Avalid option, I know I'd prefer an emergency ca= lling client that always=0D=0Aworked that way.=0D=0A=0D=0ACheers,=0D=0AMart= in=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Hannes Tschofenig [mail= to:Hannes.Tschofenig@gmx.net]=20=0D=0ASent: Thursday, 31 January 2008 7:29 = PM=0D=0ATo: speermint@ietf.org; ECRIT=0D=0ASubject: [Ecrit] Emergency Calls= & VoIP Peering=0D=0A=0D=0AHi all,=0D=0A=0D=0AI wanted to ask you for your = opinion since the following issue has been=20=0D=0Abrought forward to me ma= ny times already.=0D=0A=0D=0AOne deployment mode for the emergency services= architecture is to route=20=0D=0Acalls through the user's VoIP provider (V= SP) and then towards the PSAP.=20=0D=0ASince the VSP is typically not in th= e visited network there is obviously=0D=0A=0D=0Athe problem that the emerge= ncy SIP call (not the RTP, which would travel=0D=0A=0D=0Adirectly -- hopefu= lly) needs to be handled properly when it leaves the=20=0D=0AVSP, potential= ly traverses some other peering networks, and then finally=0D=0A=0D=0Ahits = the PSAP.=0D=0A=0D=0ASome folks, particularly those with an IMS background,= argue that=20=0D=0A"everything" should be done locally at the visited netw= ork rather than=20=0D=0Arouting the call through the user's VSP where thing= s could potentially=20=0D=0Ago wrong along the path between the PSAP and th= e VSP.=0D=0A=0D=0AThoughts about this aspect=3F=0D=0A=0D=0ACiao=0D=0AHannes=0D= =0A=0D=0A=0D=0A_______________________________________________=0D=0AEcrit m= ailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo= /ecrit=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 07:52:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYu8-0003bg-HE; Thu, 31 Jan 2008 07:52:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYu7-0003bC-7j for ecrit@ietf.org; Thu, 31 Jan 2008 07:52:31 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKYu5-0003XW-8E for ecrit@ietf.org; Thu, 31 Jan 2008 07:52:31 -0500 Received: (qmail invoked by alias); 31 Jan 2008 12:52:27 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp032) with SMTP; 31 Jan 2008 13:52:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZnF0EJjKZkA7zvgquyV4ZEMd+PbA9e8OpfifHHk IcE50btI99vj8d Message-ID: <47A1C47B.7040800@gmx.net> Date: Thu, 31 Jan 2008 14:52:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Ecrit] Emergency Calls & VoIP Peering References: <47A186C1.7080004@gmx.net> 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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: speermint@ietf.org, ECRIT 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: , Errors-To: ecrit-bounces@ietf.org Hi Martin, thanks for the quick feedback. Dawson, Martin wrote: > Good question! And one I tried to have discussed late last year. > > Really. I must have missed it. > I don't see any benefit in involving the VSP - for the caller, the VSP, > or the emergency service. > > It's been said that the emergency service wants the subscriber details > from the VSP. A caller can have subscriptions to lots of Internet > services that also don't need to be involved in the call. Should we also > make emergency calling dependent on them? > The idea was that the emergency call works in the same fashion as any other call. Normal calls just go via your VSP. The fact that you could attach identity information is quite useful as well (for security reasons). > I don't think it has to be the same as IMS. IMS requires a co-operative > E-CSCF that is actually part of the access network. With LoST and a > suitable emergency proxy, there doesn't have to be any dependency on the > access network to also provide call processing. > What do you mean by "suitable emergency proxy"? Who would operate it? > Not involving the VSP in the call does not mean that the caller cannot > provide callback details (in principle, they could provide multiple > callback options). I'd also be interested in a discussion around > providing an automatic presence subscription from the emergency network > itself - with a temporary callback number. As long as the emergency > calling device is attached to the Internet, it should be able to stay > registered with that temporary subscription and also do regular location > updates to it. > I agree that there are different ways todo the call back. > Many of the most convoluted issues that have arisen in this forum have > been around the challenges that having the VSP involved in call routing > introduces (the need for forest guides etc). Since direct-calling is a > valid option, I know I'd prefer an emergency calling client that always > worked that way. > You aren't worried about the lack of identity information. Right? Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, 31 January 2008 7:29 PM > To: speermint@ietf.org; ECRIT > Subject: [Ecrit] Emergency Calls & VoIP Peering > > Hi all, > > I wanted to ask you for your opinion since the following issue has been > brought forward to me many times already. > > One deployment mode for the emergency services architecture is to route > calls through the user's VoIP provider (VSP) and then towards the PSAP. > Since the VSP is typically not in the visited network there is obviously > > the problem that the emergency SIP call (not the RTP, which would travel > > directly -- hopefully) needs to be handled properly when it leaves the > VSP, potentially traverses some other peering networks, and then finally > > hits the PSAP. > > Some folks, particularly those with an IMS background, argue that > "everything" should be done locally at the visited network rather than > routing the call through the user's VSP where things could potentially > go wrong along the path between the PSAP and the VSP. > > Thoughts about this aspect? > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > 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 Thu Jan 31 08:11:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKZCA-00057G-HB; Thu, 31 Jan 2008 08:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKZC9-000573-65; Thu, 31 Jan 2008 08:11:09 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKZC8-0004sn-EU; Thu, 31 Jan 2008 08:11:09 -0500 X-SEF-Processed: 5_0_0_910__2008_01_31_07_23_09 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 31 Jan 2008 07:23:09 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 07:11:07 -0600 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] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 07:11:03 -0600 Message-ID: In-Reply-To: <47A1C47B.7040800@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-Index: AchkCCRhV6m2eoF5RGyn0uqk45CZ1gAAK9uA References: <47A186C1.7080004@gmx.net> <47A1C47B.7040800@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" X-OriginalArrivalTime: 31 Jan 2008 13:11:07.0941 (UTC) FILETIME=[BDF43D50:01C8640A] X-Spam-Score: 1.8 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: speermint@ietf.org, ECRIT 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: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AResponses below. And bed time for me :)=0D=0A=0D=0ACh= eers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Hannes T= schofenig [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0ASent: Thursday, 31 Jan= uary 2008 11:52 PM=0D=0ATo: Dawson, Martin=0D=0ACc: speermint@ietf.org; ECR= IT=0D=0ASubject: Re: [Ecrit] Emergency Calls & VoIP Peering=0D=0A=0D=0AHi M= artin,=0D=0A=0D=0Athanks for the quick feedback.=0D=0A=0D=0ADawson, Martin = wrote:=0D=0A> Good question! And one I tried to have discussed late last ye= ar.=0D=0A>=0D=0A> =20=0D=0AReally. I must have missed it.=0D=0A=0D=0A> I d= on't see any benefit in involving the VSP - for the caller, the=0D=0AVSP,=0D= =0A> or the emergency service.=0D=0A>=0D=0A> It's been said that the emerge= ncy service wants the subscriber details=0D=0A> from the VSP. A caller can = have subscriptions to lots of Internet=0D=0A> services that also don't need= to be involved in the call. Should we=0D=0Aalso=0D=0A> make emergency call= ing dependent on them=3F=0D=0A> =20=0D=0AThe idea was that the emergency c= all works in the same fashion as any=20=0D=0Aother call. Normal calls just = go via your VSP.=0D=0A[[MCD]] Yes - I've heard that too. I haven't seen why= that is considered=0D=0Ato be an inherent virtue. I think emergency callin= g would be more=0D=0Areliable if the emergency client were somewhat decoupl= ed from the=0D=0A"normal" VoIP client. A reference implementation of an eme= rgency client=0D=0Athat didn't try to be "interoperable" with VSPs, I am ce= rtain, would be=0D=0Amuch more robust.=0D=0A=0D=0AThe fact that you could a= ttach identity information is quite useful as=20=0D=0Awell (for security re= asons).=0D=0A[[MCD]] Since there's no guarantee of VSP subscriber informati= on meaning=0D=0Aanything at all and since a VSP *doesn't have to be used* a= nyway. I=0D=0Adon't think that any security is provided.=0D=0A=0D=0A> I don= 't think it has to be the same as IMS. IMS requires a=0D=0Aco-operative=0D=0A= > E-CSCF that is actually part of the access network. With LoST and a=0D=0A= > suitable emergency proxy, there doesn't have to be any dependency on=0D=0A= the=0D=0A> access network to also provide call processing.=0D=0A> =20=0D=0A= What do you mean by "suitable emergency proxy"=3F Who would operate it=3F=0D= =0A[[MCD]] The emergency network has to provide a route into the emergency=0D= =0Anetwork. Emergency calling can't rely on a VSP being there. Going direct=0D= =0Ato the PSAP-URI is a valid scenario. Just as emergency call centres=0D=0A= currently provide an access point on the PSTN, so too would emergency=0D=0A= call centres need to provide the access point for IP telephony.=0D=0AExclud= ing VSPs from the call procedure doesn't introduce anything new in=0D=0Atha= t respect.=0D=0A=0D=0A> Not involving the VSP in the call does not mean tha= t the caller cannot=0D=0A> provide callback details (in principle, they cou= ld provide multiple=0D=0A> callback options). I'd also be interested in a d= iscussion around=0D=0A> providing an automatic presence subscription from t= he emergency=0D=0Anetwork=0D=0A> itself - with a temporary callback number.= As long as the emergency=0D=0A> calling device is attached to the Internet= , it should be able to stay=0D=0A> registered with that temporary subscript= ion and also do regular=0D=0Alocation=0D=0A> updates to it.=0D=0A> =20=0D=0A= I agree that there are different ways todo the call back.=0D=0A=0D=0A> Many= of the most convoluted issues that have arisen in this forum have=0D=0A> b= een around the challenges that having the VSP involved in call=0D=0Arouting=0D= =0A> introduces (the need for forest guides etc). Since direct-calling is a=0D= =0A> valid option, I know I'd prefer an emergency calling client that=0D=0A= always=0D=0A> worked that way.=0D=0A> =20=0D=0AYou aren't worried about th= e lack of identity information. Right=3F=0D=0A[[MCD]] That's right. First, = there's no reliable source of identify=0D=0Ainformation from VSPs anyway. S= econdly, the equivalent of PSTN identity=0D=0Ainformation is actually the I= nternet access identity information. We'd=0D=0Abe better off getting that i= nformation included (via the PIDF-LO or=0D=0Asimilar mechanism). If someone= is on a free access point then, well,=0D=0Athat's the same as someone maki= ng an emergency call from a public=0D=0Atelephone. It can be related back t= o the access provider but the=0D=0Aindividual remains anonymous.=0D=0A=0D=0A=0D= =0ACiao=0D=0AHannes=0D=0A=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A> -----O= riginal Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofen= ig@gmx.net]=20=0D=0A> Sent: Thursday, 31 January 2008 7:29 PM=0D=0A> To: sp= eermint@ietf.org; ECRIT=0D=0A> Subject: [Ecrit] Emergency Calls & VoIP Peer= ing=0D=0A>=0D=0A> Hi all,=0D=0A>=0D=0A> I wanted to ask you for your opinio= n since the following issue has=0D=0Abeen=20=0D=0A> brought forward to me m= any times already.=0D=0A>=0D=0A> One deployment mode for the emergency serv= ices architecture is to=0D=0Aroute=20=0D=0A> calls through the user's VoIP = provider (VSP) and then towards the=0D=0APSAP.=20=0D=0A> Since the VSP is t= ypically not in the visited network there is=0D=0Aobviously=0D=0A>=0D=0A> t= he problem that the emergency SIP call (not the RTP, which would=0D=0Atrave= l=0D=0A>=0D=0A> directly -- hopefully) needs to be handled properly when it= leaves the=0D=0A=0D=0A> VSP, potentially traverses some other peering netw= orks, and then=0D=0Afinally=0D=0A>=0D=0A> hits the PSAP.=0D=0A>=0D=0A> Some= folks, particularly those with an IMS background, argue that=20=0D=0A> "ev= erything" should be done locally at the visited network rather than=0D=0A=0D= =0A> routing the call through the user's VSP where things could potentially=0D= =0A=0D=0A> go wrong along the path between the PSAP and the VSP.=0D=0A>=0D=0A= > Thoughts about this aspect=3F=0D=0A>=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=0D=0A= >=0D=0A> _______________________________________________=0D=0A> Ecrit maili= ng list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo= /ecrit=0D=0A>=0D=0A>=0D=0A-------------------------------------------------= -----------------------=0D=0A------------------------=0D=0A> This message i= s for the designated recipient only and may=0D=0A> contain privileged, prop= rietary, or otherwise private information. =20=0D=0A> If you have received = it in error, please notify the sender=0D=0A> immediately and delete the ori= ginal. Any unauthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A------------------------=0D=0A> [mf2]=0D=0A>=0D=0A> =20=0D=0A=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 10:30:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbMY-00040A-M5; Thu, 31 Jan 2008 10:30:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbMX-0003zj-9L; Thu, 31 Jan 2008 10:30:01 -0500 Received: from tcmail12.telekom.de ([217.5.214.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKbMW-0006wf-8P; Thu, 31 Jan 2008 10:30:01 -0500 Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 31 Jan 2008 16:29:54 +0100 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 16:29:11 +0100 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: AW: [Ecrit] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 16:29:10 +0100 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B038E1BF5@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-Index: AchkCCRhV6m2eoF5RGyn0uqk45CZ1gAAK9uAAAHsp4A= References: <47A186C1.7080004@gmx.net><47A1C47B.7040800@gmx.net> From: "Liess, Laura" To: , X-OriginalArrivalTime: 31 Jan 2008 15:29:11.0716 (UTC) FILETIME=[0777FE40:01C8641E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: speermint@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: , Errors-To: ecrit-bounces@ietf.org The proposal has its benefits but I think it also has its drawbacks.=20 In principle, I have no problem with it as long as the there is no = obligation for the access network/ISP to provide an emergency proxy or a = P-CSCF which must accept emergency calls from unknown clients and make = sure that these calls work. We have now some experience with a life VoIP service at DT, with adding = new clients, with interoperability and NAT traversal problems. We = definitively don't want to deal with unknown clients and all these = problems for emergency calls. I think PSAPs will not want to deal = directly with clients, either. But maybe I am wrong.=20 The 3GPP people have their architecture with the P-CSCF in the visited = network/access network. But I would like to know how many VoIP/IMS = providers already operate or plan to operate P-CSCF in the visited = network. DT does not. And without a P-CSCF in the visited network IMS = has the same problems as IETF with emergency calls. =20 Laura =20 =20 =20 -----Urspr=FCngliche Nachricht----- Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Gesendet: Donnerstag, 31. Januar 2008 14:11 An: Hannes Tschofenig Cc: speermint@ietf.org; ECRIT Betreff: RE: [Ecrit] Emergency Calls & VoIP Peering Hi Hannes, Responses below. And bed time for me :) Cheers, Martin -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, 31 January 2008 11:52 PM To: Dawson, Martin Cc: speermint@ietf.org; ECRIT Subject: Re: [Ecrit] Emergency Calls & VoIP Peering Hi Martin, thanks for the quick feedback. Dawson, Martin wrote: > Good question! And one I tried to have discussed late last year. > > =20 Really. I must have missed it. > I don't see any benefit in involving the VSP - for the caller, the VSP, > or the emergency service. > > It's been said that the emergency service wants the subscriber details > from the VSP. A caller can have subscriptions to lots of Internet > services that also don't need to be involved in the call. Should we also > make emergency calling dependent on them? > =20 The idea was that the emergency call works in the same fashion as any=20 other call. Normal calls just go via your VSP. [[MCD]] Yes - I've heard that too. I haven't seen why that is considered to be an inherent virtue. I think emergency calling would be more reliable if the emergency client were somewhat decoupled from the "normal" VoIP client. A reference implementation of an emergency client that didn't try to be "interoperable" with VSPs, I am certain, would be much more robust. The fact that you could attach identity information is quite useful as=20 well (for security reasons). [[MCD]] Since there's no guarantee of VSP subscriber information meaning anything at all and since a VSP *doesn't have to be used* anyway. I don't think that any security is provided. > I don't think it has to be the same as IMS. IMS requires a co-operative > E-CSCF that is actually part of the access network. With LoST and a > suitable emergency proxy, there doesn't have to be any dependency on the > access network to also provide call processing. > =20 What do you mean by "suitable emergency proxy"? Who would operate it? [[MCD]] The emergency network has to provide a route into the emergency network. Emergency calling can't rely on a VSP being there. Going direct to the PSAP-URI is a valid scenario. Just as emergency call centres currently provide an access point on the PSTN, so too would emergency call centres need to provide the access point for IP telephony. Excluding VSPs from the call procedure doesn't introduce anything new in that respect. > Not involving the VSP in the call does not mean that the caller cannot > provide callback details (in principle, they could provide multiple > callback options). I'd also be interested in a discussion around > providing an automatic presence subscription from the emergency network > itself - with a temporary callback number. As long as the emergency > calling device is attached to the Internet, it should be able to stay > registered with that temporary subscription and also do regular location > updates to it. > =20 I agree that there are different ways todo the call back. > Many of the most convoluted issues that have arisen in this forum have > been around the challenges that having the VSP involved in call routing > introduces (the need for forest guides etc). Since direct-calling is a > valid option, I know I'd prefer an emergency calling client that always > worked that way. > =20 You aren't worried about the lack of identity information. Right? [[MCD]] That's right. First, there's no reliable source of identify information from VSPs anyway. Secondly, the equivalent of PSTN identity information is actually the Internet access identity information. We'd be better off getting that information included (via the PIDF-LO or similar mechanism). If someone is on a free access point then, well, that's the same as someone making an emergency call from a public telephone. It can be related back to the access provider but the individual remains anonymous. Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, 31 January 2008 7:29 PM > To: speermint@ietf.org; ECRIT > Subject: [Ecrit] Emergency Calls & VoIP Peering > > Hi all, > > I wanted to ask you for your opinion since the following issue has been=20 > brought forward to me many times already. > > One deployment mode for the emergency services architecture is to route=20 > calls through the user's VoIP provider (VSP) and then towards the PSAP.=20 > Since the VSP is typically not in the visited network there is obviously > > the problem that the emergency SIP call (not the RTP, which would travel > > directly -- hopefully) needs to be handled properly when it leaves the > VSP, potentially traverses some other peering networks, and then finally > > hits the PSAP. > > Some folks, particularly those with an IMS background, argue that=20 > "everything" should be done locally at the visited network rather than > routing the call through the user's VSP where things could potentially > go wrong along the path between the PSAP and the VSP. > > Thoughts about this aspect? > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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] > > =20 -------------------------------------------------------------------------= ----------------------- 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 11:23:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcC6-0000ox-3R; Thu, 31 Jan 2008 11:23:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcC4-0000oq-RT for ecrit@ietf.org; Thu, 31 Jan 2008 11:23:16 -0500 Received: from fg-out-1718.google.com ([72.14.220.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKcC3-00016A-VH for ecrit@ietf.org; Thu, 31 Jan 2008 11:23:16 -0500 Received: by fg-out-1718.google.com with SMTP id 16so693950fgg.41 for ; Thu, 31 Jan 2008 08:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=hm9u0LbmGCB7sTUOkbRlO0RdRo0mFi0DzNLsTA/18XY=; b=P7xSFvLQo9T8A8mwJSgJQYJakm+oCvXIYOd0QhLqXBP/Q8k5i+iZH0XRt5dGNrl0Ouzxr/EQJ1mIwYoJWf+pYaNiIl+t1n16M+0rNqjV74PVTi76oRVZwRqw0KTh2JhKKDpD/i39L6oFcD6BKUhp8WkcNL8sSODjfi1ydNO2TkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aHDZyZyBjQVGr7WxIP2gLwFHG2NItec6+Bbfww8DmHv79gTu9gMr6upHhzJ85NvQCv4ZHTcC1kAb6YAFZ7QjWOBPMXcF0i+dVti+GrJXWE2VUCmeoCVWH5RMHcSSp/EX0TJGB7vrhfwMU46ioW1toY3TeFdfzw9+Au1tOWeSz/8= Received: by 10.86.28.5 with SMTP id b5mr2048258fgb.47.1201796594908; Thu, 31 Jan 2008 08:23:14 -0800 (PST) Received: by 10.86.23.13 with HTTP; Thu, 31 Jan 2008 08:23:14 -0800 (PST) Message-ID: <181f29c0801310823l21e5b856ra20041414e1770cd@mail.gmail.com> Date: Thu, 31 Jan 2008 11:23:14 -0500 From: "Nate Wilcox" To: "Hannes Tschofenig" Subject: Re: [Ecrit] Emergency Calls & VoIP Peering In-Reply-To: <47A186C1.7080004@gmx.net> MIME-Version: 1.0 References: <47A186C1.7080004@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: speermint@ietf.org, ECRIT 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="===============1992538601==" Errors-To: ecrit-bounces@ietf.org --===============1992538601== Content-Type: multipart/alternative; boundary="----=_Part_1750_3926561.1201796594880" ------=_Part_1750_3926561.1201796594880 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The originating SIP UA needs to understand how to route a call to the correct PSAP regardless of their VSP. The proposal within a couple different PSAP oriented organizations is that it is done by querying an ECRF (LoST server) using the URN of the service you are requesting (sos in this case) in conjunction with the PIDF-LO to determine the correct next hop routing proxy and this repeats itself as many times as it takes to get to the correct PSAP. This implies, of course, that the PSAP can accept a SIP call (and currently only about a dozen do in North America). As far as the RTP terminating direct at the PSAP call takers UA, that is a matter of some dicsssion that would probably better be couched by the folks who are providing the PSAP facing routing and network services. Although their is considerable merit in using 3PCC for this purpose..... Nate On Thu, Jan 31, 2008 at 3:28 AM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > Hi all, > > I wanted to ask you for your opinion since the following issue has been > brought forward to me many times already. > > One deployment mode for the emergency services architecture is to route > calls through the user's VoIP provider (VSP) and then towards the PSAP. > Since the VSP is typically not in the visited network there is obviously > the problem that the emergency SIP call (not the RTP, which would travel > directly -- hopefully) needs to be handled properly when it leaves the > VSP, potentially traverses some other peering networks, and then finally > hits the PSAP. > > Some folks, particularly those with an IMS background, argue that > "everything" should be done locally at the visited network rather than > routing the call through the user's VSP where things could potentially > go wrong along the path between the PSAP and the VSP. > > Thoughts about this aspect? > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > ------=_Part_1750_3926561.1201796594880 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
The originating SIP UA needs to understand how to route a call to the correct PSAP regardless of their VSP. The proposal within a couple different PSAP oriented organizations is that it is done by querying an ECRF (LoST server) using the URN of the service you are requesting (sos in this case)  in conjunction with the PIDF-LO to determine the correct next hop routing proxy and this repeats itself as many times as it takes to get to the correct PSAP. This implies, of course, that the PSAP can accept a SIP call (and currently only about a dozen do in North America). 
 
As far as the RTP terminating direct at the PSAP call takers UA, that is a matter of some dicsssion that would probably better be couched by the folks who are providing the PSAP facing routing and network services. Although their is considerable merit in using 3PCC for this purpose.....
 
Nate 
On Thu, Jan 31, 2008 at 3:28 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Hi all,

I wanted to ask you for your opinion since the following issue has been
brought forward to me many times already.

One deployment mode for the emergency services architecture is to route
calls through the user's VoIP provider (VSP) and then towards the PSAP.
Since the VSP is typically not in the visited network there is obviously
the problem that the emergency SIP call (not the RTP, which would travel
directly -- hopefully) needs to be handled properly when it leaves the
VSP, potentially traverses some other peering networks, and then finally
hits the PSAP.

Some folks, particularly those with an IMS background, argue that
"everything" should be done locally at the visited network rather than
routing the call through the user's VSP where things could potentially
go wrong along the path between the PSAP and the VSP.

Thoughts about this aspect?

Ciao
Hannes


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------=_Part_1750_3926561.1201796594880-- --===============1992538601== 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 --===============1992538601==-- From ecrit-bounces@ietf.org Thu Jan 31 11:50:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKccV-00073n-8R; Thu, 31 Jan 2008 11:50:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKccU-00073f-CK; Thu, 31 Jan 2008 11:50:34 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKccT-0000ZZ-Nv; Thu, 31 Jan 2008 11:50:34 -0500 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.194122924; Thu, 31 Jan 2008 11:50:18 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 11:50:18 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 11:50:18 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 11:50:17 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0741ED9F@crexc41p> In-Reply-To: <47A186C1.7080004@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering thread-index: Achj42sHknNgaUs0TLyojFzWxMMoXwAQDdfw References: <47A186C1.7080004@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 31 Jan 2008 16:50:18.0461 (UTC) FILETIME=[5C4658D0:01C86429] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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: , Errors-To: ecrit-bounces@ietf.org I believe that the solutions created by IETF ecrit need to work in any of the 3 potential scenarios: 1) end device directly routes emergency calls to emergency network 2) access network detects emergency call and routes directly to emergency network 3) call goes to regular outbound proxy / SIP proxy (as configured in the device), which ultimately routes the call to the emergency network; this proxy is most likely provided by a VSP, although it could be an Asterisk server in my basement. All 3 are valid, and I expect all 3 to exist in various places in the world.=20 I see nothing that precludes any of these from occurring. In reading phonebcp, I believe it is expecting a device to send emergency calls to its regular proxy, as it would for all calls. I think this is an appropriate behavior. For uninitialized devices (no successful SIP registration, but they are on the Internet), I would prefer if the device did try to route directly, rather than go through some VSP who can't authenticate them anyway. Since the existence of devices that can route directly can't really be prevented, I think it is up to the emergency network to determine what treatment to give such calls. Honestly, I don't see a whole lot of difference between end devices that can route directly vs. go through the basement Asterisk server, from a trust perspective. If a device has logic that directly routes all emergency calls, I see nothing wrong with this. But I don't think phonebcp should encourage this. Since phonebcp is still just a BCP, there's nothing that precludes this behavior, if that's what's wanted. Access networks that detect, intercept, and directly route emergency calls will exist. I don't see how that fact changes any of the ecrit work. I don't think phonebcp should be changed to accommodate this scenario, since 3GPP does an excellent job of describing how it can work. I wouldn't expect a 3GPP access network to necessarily abide by phonebcp -- rather, I would expect it to abide by whatever rules 3GPP sets forth. IETF shouldn't try to take this over from 3GPP. Under no circumstances, however, should there be any attempt to mandate that all access networks abide by 3GPP rules. Access networks will exist that do not detect emergency calls. We shouldn't be trying to say if this is good or bad. It simply is and will continue to be. Both types of access networks will exist, and I would prefer for ecrit to work under the assumption that an access network cannot detect emergency calls. If it can, that's fine, and I don't think anything breaks. Barbara -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, January 31, 2008 3:29 AM To: speermint@ietf.org; ECRIT Subject: [Ecrit] Emergency Calls & VoIP Peering Hi all, I wanted to ask you for your opinion since the following issue has been=20 brought forward to me many times already. One deployment mode for the emergency services architecture is to route=20 calls through the user's VoIP provider (VSP) and then towards the PSAP.=20 Since the VSP is typically not in the visited network there is obviously the problem that the emergency SIP call (not the RTP, which would travel directly -- hopefully) needs to be handled properly when it leaves the=20 VSP, potentially traverses some other peering networks, and then finally hits the PSAP. Some folks, particularly those with an IMS background, argue that=20 "everything" should be done locally at the visited network rather than=20 routing the call through the user's VSP where things could potentially=20 go wrong along the path between the PSAP and the VSP. Thoughts about this aspect? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** 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. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 11:55:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKchS-0006d0-PB; Thu, 31 Jan 2008 11:55:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKchR-0006V2-9T; Thu, 31 Jan 2008 11:55:41 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKchQ-0000g6-Nz; Thu, 31 Jan 2008 11:55:41 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKchK-0006L5-FD; Thu, 31 Jan 2008 10:55:34 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 11:55:36 -0500 Message-ID: <005b01c8642a$1bd4bcf0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: ecrit-bounces@ietf.org First my response to the original question: IMS is special because the visited network is in the call path. When the visited network has active elements in the call path, it makes sense to have the visited network handle emergency calls. Note that there are lots and lots of complications with this. Take for example, call back. What you want is to have both a Contact URI that will route back to the device that placed the call, and you need a real AoR you can use to reach the caller later on. The visited network would have to provide both. When the visited network is not in the call path, you have to use the VSP. Then my response to Martin: > It's been said that the emergency service wants the subscriber details > from the VSP. A caller can have subscriptions to lots of Internet > services that also don't need to be involved in the call. Should we also > make emergency calling dependent on them? No. However, involving the actual carrier that provides the service that is placing the call is essential. Bypassing the carrier that provides the service that places the call is pretty tough, except in unusual circumstances. IMS is an example of an unusual circumstance because they put the visited network in the call path. Very few other systems do that. I'm very conscious of what we must ask the access network to provide. This has lots of implications on engineering as well as cost and liability. Unless the device itself can locate itself without assistance of the access network, we ask the access network to provide location (or at least location assistance). We ask them to provide access to a LoST server. I want to stop there. That's all they have to do. > > I don't think it has to be the same as IMS. IMS requires a co-operative > E-CSCF that is actually part of the access network. With LoST and a > suitable emergency proxy, there doesn't have to be any dependency on the > access network to also provide call processing. IMS is different as discussed above. > > Not involving the VSP in the call does not mean that the caller cannot > provide callback details (in principle, they could provide multiple > callback options). I'd also be interested in a discussion around > providing an automatic presence subscription from the emergency network > itself - with a temporary callback number. As long as the emergency > calling device is attached to the Internet, it should be able to stay > registered with that temporary subscription and also do regular location > updates to it. I think the notion that we can define the characteristics of an emergency proxy that works for all devices is not feasible. Let me cite a few examples: Emergency call from AOL/MSN/Yahoo. We would have to require the device to implement SIP/SIMPLE. Emergency call from OnStar. Who is the emergency proxy provider? Emergency call from "Help I've fallen and I can't get up" buttons with two way audio. They would have to meet all of the phonebcp requirements. Call backs are an issue. You can get a contact URI, but you can't get an AoR you have any trust in for any call. But the biggest problem is that I think any attempt to give the access network the obligation and the liability to totally handle emergency calls will not fly. > > Many of the most convoluted issues that have arisen in this forum have > been around the challenges that having the VSP involved in call routing > introduces (the need for forest guides etc). Since direct-calling is a > valid option, I know I'd prefer an emergency calling client that always > worked that way. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 12:05:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcqY-000772-Hc; Thu, 31 Jan 2008 12:05:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcqW-00071D-Sq; Thu, 31 Jan 2008 12:05:04 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKcqW-0001Ha-Fr; Thu, 31 Jan 2008 12:05:04 -0500 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.39589609; Thu, 31 Jan 2008 12:04:47 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 12:04:47 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 12:04:47 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 12:04:46 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering thread-index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbA= References: <47A186C1.7080004@gmx.net> From: "Stark, Barbara" To: "Dawson, Martin" , "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 31 Jan 2008 17:04:47.0229 (UTC) FILETIME=[6219D2D0:01C8642B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: ecrit-bounces@ietf.org snip... > IMS requires a co-operative > E-CSCF that is actually part of the access network. This is not true. Please don't confuse "IMS" with "3GPP Access Network" and early 3GPP IMS definitions. They aren't the same. It's absolutely possible to have an IMS core that exists only on the Internet, and that makes no assumptions about access networks. Barbara=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. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 31 12:10:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcvZ-0000ns-TD; Thu, 31 Jan 2008 12:10:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcvZ-0000nb-0f; Thu, 31 Jan 2008 12:10:17 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKcvX-000273-Io; Thu, 31 Jan 2008 12:10:16 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKcvR-0007qv-6T; Thu, 31 Jan 2008 11:10:09 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 12:10:11 -0500 Message-ID: <006601c8642c$25402ac0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: ecrit-bounces@ietf.org I made the same assumption, which I know to be wrong. Thank you for correcting us. Is "3GPP Access Network" the right terminology for the kind of network where the visited network provides the E-CSCF? Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, January 31, 2008 12:05 PM > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > snip... > > IMS requires a co-operative > > E-CSCF that is actually part of the access network. > > This is not true. Please don't confuse "IMS" with "3GPP Access Network" > and early 3GPP IMS definitions. They aren't the same. It's absolutely > possible to have an IMS core that exists only on the Internet, and that > makes no assumptions about access networks. > 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. GA622 > > > > _______________________________________________ > 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 31 17:07:01 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B86C28C20A; Thu, 31 Jan 2008 17:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2x4Rhv4WR+9; Thu, 31 Jan 2008 17:07:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED15828C20D; Thu, 31 Jan 2008 17:05:44 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627E328C208; Thu, 31 Jan 2008 17:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DgNP59UBluv; Thu, 31 Jan 2008 17:05:42 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9CB8528C213; Thu, 31 Jan 2008 17:04:45 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKg1C-0000Ji-Ow; Thu, 31 Jan 2008 14:28:19 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <47A21B7B.2060903@cisco.com> Date: Thu, 31 Jan 2008 15:28:24 -0500 Message-ID: <00c801c86447$d613da20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47A21B7B.2060903@cisco.com> Thread-Index: AchkO/4oTX33jnGsSqW0LskPiFL4FwACqEfw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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 Cc: "'Dawson, Martin'" , 'ECRIT' , speermint@ietf.org Subject: Re: [Ecrit] [Speermint] RE: Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not really true. In your last example, suppose 9-1-1 was directory assistance in the U.K. (it's not). If a call with sip:911@acme.co.uk is placed from a U.S. location, then usually it's an emergency call. The local (visited) dial string MUST be honored. The home dial string MAY be honored. It is indeed problematic for the UK proxy to do dial plan interpretation because it doesn't have location unless the phone already knows it's an emergency call, but never-the-less, 9-1-1 when dialed in the U.S. is always an emergency call, regardless of the domain. As a practical matter, some enterprise dial plans change this. You sometimes have to dial 9-9-1-1, and that's an emergency call. I don't think Martin's ASP proxy could handle that. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, January 31, 2008 2:03 PM > To: Brian Rosen > Cc: 'Dawson, Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering > > > > Brian Rosen wrote: > > First my response to the original question: > > > > IMS is special because the visited network is in the call path. When > the > > visited network has active elements in the call path, it makes sense to > have > > the visited network handle emergency calls. > > I think that is acceptable *if* the access network has a well defined, > unambiguous way to discern whether a call is an emergency call or not. > > If the R-URI is then there is no problem at all. If the > R-URI is then again there is no problem. But > if the R-URI is then it is very problematic if a > visited network in the US decides this is an emergency call because of > the "911". OTOH the owner of the domain *can* decide this is an > emergency call based on its understanding of its numbering plan. > > Paul > > > Note that there are lots and > > lots of complications with this. Take for example, call back. What you > > want is to have both a Contact URI that will route back to the device > that > > placed the call, and you need a real AoR you can use to reach the caller > > later on. The visited network would have to provide both. > > > > When the visited network is not in the call path, you have to use the > VSP. > > > > > > Then my response to Martin: > >> It's been said that the emergency service wants the subscriber details > >> from the VSP. A caller can have subscriptions to lots of Internet > >> services that also don't need to be involved in the call. Should we > also > >> make emergency calling dependent on them? > > No. However, involving the actual carrier that provides the service > that is > > placing the call is essential. Bypassing the carrier that provides the > > service that places the call is pretty tough, except in unusual > > circumstances. IMS is an example of an unusual circumstance because > they > > put the visited network in the call path. Very few other systems do > that. > > > > I'm very conscious of what we must ask the access network to provide. > This > > has lots of implications on engineering as well as cost and liability. > > Unless the device itself can locate itself without assistance of the > access > > network, we ask the access network to provide location (or at least > location > > assistance). We ask them to provide access to a LoST server. I want to > > stop there. That's all they have to do. > > > >> I don't think it has to be the same as IMS. IMS requires a co-operative > >> E-CSCF that is actually part of the access network. With LoST and a > >> suitable emergency proxy, there doesn't have to be any dependency on > the > >> access network to also provide call processing. > > IMS is different as discussed above. > > > >> Not involving the VSP in the call does not mean that the caller cannot > >> provide callback details (in principle, they could provide multiple > >> callback options). I'd also be interested in a discussion around > >> providing an automatic presence subscription from the emergency network > >> itself - with a temporary callback number. As long as the emergency > >> calling device is attached to the Internet, it should be able to stay > >> registered with that temporary subscription and also do regular > location > >> updates to it. > > I think the notion that we can define the characteristics of an > emergency > > proxy that works for all devices is not feasible. Let me cite a few > > examples: > > > > Emergency call from AOL/MSN/Yahoo. We would have to require the device > to > > implement SIP/SIMPLE. > > > > Emergency call from OnStar. Who is the emergency proxy provider? > > > > Emergency call from "Help I've fallen and I can't get up" buttons with > two > > way audio. They would have to meet all of the phonebcp requirements. > > > > Call backs are an issue. You can get a contact URI, but you can't get > an > > AoR you have any trust in for any call. > > > > But the biggest problem is that I think any attempt to give the access > > network the obligation and the liability to totally handle emergency > calls > > will not fly. > > > > > >> Many of the most convoluted issues that have arisen in this forum have > >> been around the challenges that having the VSP involved in call routing > >> introduces (the need for forest guides etc). Since direct-calling is a > >> valid option, I know I'd prefer an emergency calling client that always > >> worked that way. > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit