From mailnull@www1.ietf.org Sat May 3 05:44:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26544 for ; Sat, 3 May 2003 05:44:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h439o8C25335 for sipping-emergency-archive@odin.ietf.org; Sat, 3 May 2003 05:50:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h439o8825332 for ; Sat, 3 May 2003 05:50:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26508 for ; Sat, 3 May 2003 05:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BtZZ-0003Nu-00 for sipping-emergency-web-archive@ietf.org; Sat, 03 May 2003 05:44:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BtZY-0003Nn-00 for sipping-emergency-web-archive@ietf.org; Sat, 03 May 2003 05:44:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h439o1825318 for ; Sat, 3 May 2003 05:50:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h439nE825275 for ; Sat, 3 May 2003 05:49:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26483 for ; Sat, 3 May 2003 05:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BtYT-0003NY-00 for sipping-emergency@ietf.org; Sat, 03 May 2003 05:43:41 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19BtYN-0003NF-00 for sipping-emergency@ietf.org; Sat, 03 May 2003 05:43:35 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h439hmDW019702; Sat, 3 May 2003 11:43:48 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 3 May 2003 11:43:46 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "Emergency (E-mail)" Cc: "'PMcCalmont@intrado.com'" Date: Sat, 3 May 2003 11:43:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sipping-emergency] FW: SIP Emergency IETF Group Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, I have just added Patti to the mailing list. Regards, Gonzalo -----Original Message----- From: McCalmont, Patti [mailto:PMcCalmont@intrado.com] Sent: Friday, May 02, 2003 4:02 PM To: Gonzalo Camarillo Gonzalez (LMF) Subject: RE: SIP Emergency IETF Group Gonzalo, I would very much like to participate in the design team. Where I might help the team is in my in depth knowledge of current capabilities of the 9-1-1 network and interfaces. Please do include me. Thanks, Patti McCalmont System Engineer Intrado Inc. 3030 Warenville Rd Lisle, IL 60532 direct: 630.300.2839 mobile 630.880.6399 fax: 720.494.6600 email: pmccalmont@intrado.com Intrado. Informed Response.TM www.intrado.com ATTENTION: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify Intrado Inc. immediately at (303) 581-5600 and destroy all copies of this message and any attachments. -----Original Message----- From: Gonzalo Camarillo Gonzalez (LMF) [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, April 30, 2003 3:13 AM To: McCalmont, Patti Subject: RE: SIP Emergency IETF Group Patti, if you are willing to provide ideas and have mailing list discussions, I will add you to the design team. If you are only interested in monitoring, you should follow the updates that should be sent periodically to the SIPPING mailing list or presented in the IETF meetings. Let me know what you had in mind, Thanks, Gonzalo -----Original Message----- From: McCalmont, Patti [mailto:PMcCalmont@intrado.com] Sent: Thursday, April 24, 2003 4:35 PM To: Gonzalo.Camarillo@ericsson.com Subject: SIP Emergency IETF Group Camarillo, You are listed as the chair for the newly formed SIP Emergency Call group in IETF? Has there been any activity within the group on this topic? Minimally I would like to be included on any email list servers. Our company provides a majority of the data bases that support US 9-1-1 service and are also very involved with National Emergency Number Association (NENA) organizations. Patti McCalmont System Engineer Intrado Inc. 3030 Warenville Rd Lisle, IL 60532 direct: 630.300.2839 mobile 630.880.6399 fax: 720.494.6600 email: pmccalmont@intrado.com Intrado. Informed Response.TM www.intrado.com ATTENTION: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify Intrado Inc. immediately at (303) 581-5600 and destroy all copies of this message and any attachments. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Thu May 8 01:20:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00972 for ; Thu, 8 May 2003 01:20:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h485U2c28764 for sipping-emergency-archive@odin.ietf.org; Thu, 8 May 2003 01:30:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h485U2828761 for ; Thu, 8 May 2003 01:30:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00966 for ; Thu, 8 May 2003 01:20:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DdrF-00000i-00 for sipping-emergency-web-archive@ietf.org; Thu, 08 May 2003 01:22:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DdrF-00000c-00 for sipping-emergency-web-archive@ietf.org; Thu, 08 May 2003 01:22:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h485U1828741 for ; Thu, 8 May 2003 01:30:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h485Sr828652 for ; Thu, 8 May 2003 01:28:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00939 for ; Thu, 8 May 2003 01:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ddq8-0007no-00 for sipping-emergency@ietf.org; Thu, 08 May 2003 01:21:08 -0400 Received: from [217.78.73.177] (helo=2mails1599.com) by ietf-mx with smtp (Exim 4.12) id 19Ddpq-0007n2-00 for sipping-emergency@ietf.org; Thu, 08 May 2003 01:21:02 -0400 From: "MR.KOLA AWOSIKA" Reply-To: kolaawoo@mail.com To: sipping-emergency@ietf.org Date: Thu, 8 May 2003 06:21:57 +0100 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h485Sr828653 Subject: [Sipping-emergency] REQUEST FOR YOUR URGENT ASSISTANCE Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit From: Mr.Kola Awosika NIGERIAN NATIONAL PETROLEUM CORPORATION( N.N.P.C) PLOT 775, MCPHERSON CLOSE, VICTORIA ISLAND, LAGOS, NIGERIA. Tel:234-802-3230248 DEAR SIR, I AM MR.KOLA AWOSIKA AN ACCOUNTANT IN THE NIGERIAN NATIONAL PETROLEUM CORPORATION (N.N.P.C.).I HEAD A SEVEN-MAN TENDERS BOARD IN CHARGE OF CONTRACT AWARDS AND PAYMENT APPROVALS.I CAME TO KNOW OF YOU IN MY SEARCH FOR A RELIABLE AND REPUTABLE PERSON TO HANDLE A VERY CONFIDENTIAL TRANSACTION WHICH INVOLVES THE TRANSFER OF A HUGE SUM OF MONEY TO A FOREIGN ACCOUNT. THERE WERE SERIES OF CONTRACTS EXECUTED BY A CONSORTIUM OF MULTI- NATIONALS IN THE OIL INDUSTRY IN FAVOUR OF N.N.P.C. THE ORIGINAL VALUE OF THIS CONTRACTS WERE DELIBERATELY OVER INVOICED TO THE SUM OF USD$35,000,000.00 (THIRTY FIVE MILLION UNITED STATES DOLLARS). THIS AMOUNT HAS NOW BEEN APPROVED AND IS NOW READY TO BE TRANSFERRED, BEING THAT THE COMPANIES THAT ACTUALLY EXECUTED THESE CONTRACTS HAVE BEEN FULLY PAID AND THE PROJECTS OFFICIALLY COMMISSIONED. CONSEQUENTLY,MY COLLEAGUES AND I ARE WILLING TO TRANSFER THE TOTAL AMOUNT TO YOUR ACCOUNT FOR SUBSEQUENT DISBURSEMENT, SINCE WE CIVIL SERVANTS ARE PROHIBITED BY THE CODE OF CONDUCT BUREAU (CIVIL SERVICE LAW) FROM OPERATING AND/OR OPENING FOREIGN ACCOUNTS IN OUR NAMES. NEEDLESS TO SAY,THE TRUST REPOSED ON YOU AT THIS JUNCTURE IS ENORMOUS. IN RETURN,WE HAVE AGREED TO OFFER YOU 25% OF THE TRANSFERRED SUM, WHILE 10% SHALL BE SET ASIDE FOR INCIDENTAL EXPENSES (INTERNAL AND EXTERNAL) BETWEEN PARTIES IN THE COURSE OF THE TRANSACTION.YOU WILL BEMANDATED TO REMIT THE BALANCE TO OTHER ACCOUNTS IN DUE COURSE. MODALITIES HAVE BEEN WORKED OUT AT THE HIGHEST LEVEL OF THE MINISTRY OF FINANCE AND THE CENTRAL BANK OF NIGERIA (C.B.N.) FOR THE IMMEDIATE TRANSFER OF THE FUNDS WITHIN 13 WORKING DAYS SUBJECT TO YOUR SATISFACTION OF THE ABOVE STATED TERMS. OUR ASSURANCE IS THAT YOUR ROLE IS RISK FREE. TO ACCORD THIS TRANSACTION THE LEGALITY IT DESERVES AND FOR MUTUAL SECURITY OF THE FUNDS THE WHOLE APPROVAL PROCEDURES WILL BE OFFICIALLY AND LEGALLY PROCESSED WITH YOUR NAME OR THE NAME OF ANY COMPANY YOU MAY NOMINATE AS THE BONAFIDE BENEFICIARY. ONCE MORE,I WANT YOU TO UNDERSTAND THAT HAVING PUT IN OVER TEN YEARS IN THE CIVIL SERVICE OF MY COUNTRY,I AM AVERSE TO HAVING MY IMAGE AND CAREER DENTED.THIS MATTER SHOULD THEREFORE BE TREATED WITH THE UTMOST SECRECY AND URGENCY IT DESERVES. KINDLY EXPEDITE ACTION AS WE ARE BEHIND SCHEDULE TO ENABLE US INCLUDE THIS TRANSFER IN THE FIRST BATCH WHICH WOULD CONSTITUTE THE SECOND QUARTER PAYMENTS FOR THE 2003 FINANCIAL YEAR. CONTACT ME THROUGH E-MAIL ADDRESSES BELOW AS SOON AS POSSIBLE. YOURS SINCERELY, Mr.Kola Awosika Email:kolaawoo@mail.com _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue May 13 09:51:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12103 for ; Tue, 13 May 2003 09:51:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DDHIV23711 for sipping-emergency-archive@odin.ietf.org; Tue, 13 May 2003 09:17:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDHIB23708 for ; Tue, 13 May 2003 09:17:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12091 for ; Tue, 13 May 2003 09:50:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FaCw-00046w-00 for sipping-emergency-web-archive@ietf.org; Tue, 13 May 2003 09:52:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FaCv-00046s-00 for sipping-emergency-web-archive@ietf.org; Tue, 13 May 2003 09:52:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDHHB23686 for ; Tue, 13 May 2003 09:17:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DCqSB21407 for ; Tue, 13 May 2003 08:52:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11257 for ; Tue, 13 May 2003 09:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FZou-0003u4-00 for sipping-emergency@ietf.org; Tue, 13 May 2003 09:27:52 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19FZot-0003u0-00 for sipping-emergency@ietf.org; Tue, 13 May 2003 09:27:51 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4DDStDW025828 for ; Tue, 13 May 2003 15:28:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 13 May 2003 15:29:09 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "Emergency (E-mail)" Date: Tue, 13 May 2003 15:28:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping-emergency] members-only Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, the only two messages in this mailing list in the last ten days were both SPAM...FYI: I have just configured this mailing list to be post_members_only. This will only mean that I will have to discard a couple of SPAM messages every now and then. Gonzalo _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue May 13 10:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13520 for ; Tue, 13 May 2003 10:10:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DDa8f24973 for sipping-emergency-archive@odin.ietf.org; Tue, 13 May 2003 09:36:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDa8B24970 for ; Tue, 13 May 2003 09:36:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13400 for ; Tue, 13 May 2003 10:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FaV9-0004IA-00 for sipping-emergency-web-archive@ietf.org; Tue, 13 May 2003 10:11:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FaV8-0004I6-00 for sipping-emergency-web-archive@ietf.org; Tue, 13 May 2003 10:11:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDa6B24917 for ; Tue, 13 May 2003 09:36:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDYJB24648 for ; Tue, 13 May 2003 09:34:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13145 for ; Tue, 13 May 2003 10:07:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FaTO-0004G8-00 for sipping-emergency@ietf.org; Tue, 13 May 2003 10:09:42 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19FaTN-0004Fv-00 for sipping-emergency@ietf.org; Tue, 13 May 2003 10:09:41 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DEA9D27024 for ; Tue, 13 May 2003 10:10:09 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRL14QCG; Tue, 13 May 2003 10:10:10 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA02DA; Tue, 13 May 2003 10:10:09 -0400 Message-ID: <3EC0FCC0.4000003@nortelnetworks.com> Date: Tue, 13 May 2003 10:10:08 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 CC: "Emergency (E-mail)" Subject: Re: [Sipping-emergency] members-only References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In case you're wondering: I drafted a scenarios document before I went into hospital, but it went to colleagues to see what they could add. Today I'm back in action, and I'll have to see what my colleagues have been up to so I can get it out to you. Gonzalo Camarillo Gonzalez (LMF) wrote: > Folks, > > the only two messages in this mailing list in the last ten days were both SPAM...FYI: I have just configured this mailing list to be post_members_only. This will only mean that I will have to discard a couple of SPAM messages every now and then. > > Gonzalo > _______________________________________________ > Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue May 20 22:44:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09185 for ; Tue, 20 May 2003 22:44:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L2BBH26245 for sipping-emergency-archive@odin.ietf.org; Tue, 20 May 2003 22:11:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L2B8B26242 for ; Tue, 20 May 2003 22:11:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09164 for ; Tue, 20 May 2003 22:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IJYw-0002Zc-00 for sipping-emergency-web-archive@ietf.org; Tue, 20 May 2003 22:42:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IJYr-0002ZY-00 for sipping-emergency-web-archive@ietf.org; Tue, 20 May 2003 22:42:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L2B2B26234 for ; Tue, 20 May 2003 22:11:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KKbMB02050 for ; Tue, 20 May 2003 16:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00524 for ; Tue, 20 May 2003 17:10:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IEM3-0000kH-00 for sipping-emergency@ietf.org; Tue, 20 May 2003 17:09:03 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19IEM1-0000k7-00 for sipping-emergency@ietf.org; Tue, 20 May 2003 17:09:02 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KL9hw13900; Tue, 20 May 2003 17:09:43 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFK82S; Tue, 20 May 2003 17:09:43 -0400 Received: from nortelnetworks.com (acart1cb.ca.nortel.com [47.129.129.54]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0KQX; Tue, 20 May 2003 17:09:40 -0400 Message-ID: <3ECA9992.9030002@nortelnetworks.com> Date: Tue, 20 May 2003 17:09:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au, dick.rr.knight@bt.com CC: Barnes Mary , James McEachern , steve.norreys@bt.com Content-Type: multipart/mixed; boundary="------------040304080704010305070803" Subject: [Sipping-emergency] Emergency Scenarios Document Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040304080704010305070803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Well, I'm recovered from my surgery and back in action, and here at last is the deployment scenarios document for SIP phones working into legacy emergency call centres. Let me know if you see desirable changes before I submit it for publication as an Internet Draft. Tom Taylor +1 613 736 0961 --------------040304080704010305070803 Content-Type: text/plain; name="draft-taylor-sipping-emerg-scen-00.txt" Content-Disposition: inline; filename="draft-taylor-sipping-emerg-scen-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id h4KL9hw13900 Content-Transfer-Encoding: quoted-printable Session Initiation Protocol Investigations = =20 Internet Draft Tom Taylo= r=20 Document: draft-taylor-sipping-emerg-scen-00.txt Nortel Network= s=20 Expires: November 2003 May 200= 3=20 =20 =20 SIP Emergency Assistance Scenarios=20 =20 Status of this Memo=20 This document is an Internet-Draft and is subject to all provisions= =20 of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six mont= hs=20 and may be updated, replaced, or obsoleted by other documents at an= y=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 =20 Abstract=20 This document examines the scenarios within which SIP phones may be= =20 used to contact emergency call centres. Beginning with an overview= =20 of the high level system requirements for contacting emergency call= =20 centresin the PSTN, the scenarios involving stationary or nomadic S= IP=20 phones are described and then alternative strategies for supporting= =20 the information flows for the scenarios needed to meet these=20 requirements are examined. The analysis presented here is a=20 necessary step in defining the SIP specific requirements for invoki= ng=20 emergency assistance and understanding the level of functionality=20 that can be provided by existing SIP devices and network elements a= nd=20 that which requires further development.=20 =20 =20 Taylor Expires - November 2003 [Page 1]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 Conventions used in this document=20 This document has no normative intent, hence the usual invocation o= f=20 interpretation according to RFC 2119 does not apply.=20 =20 Table of Contents=20 1 Introduction..........................................3= =20 2 Definitions and Abbreviations.........................4= =20 3 Existing Emergency Call System Description............5= =20 3.3 Legacy System Operation...............................7= =20 4 SIP Phones and Emergency Services.....................9= =20 4.1 A General Look At The Problem.........................9= =20 4.2 SIP Phone Deployment Scenarios........................9= =20 4.2.1 The Local Scenario (1)................................9= =20 4.2.2 The Regional Operator Scenario (2)...................10= =20 4.2.3 The National Operator Scenario (3)...................11= =20 4.2.4 The Visiting Phone Scenario (4)......................13= =20 4.2.5 The VPN Scenario (5).................................14= =20 4.3 System Requirements applied to SIP Phones............15= =20 4.3.1 Identifying Emergency Calls..........................16= =20 4.3.2 Call Processing Recognition and Routing Of Emergency=20 Calls.............................................17= =20 4.3.3 Calling Party Number As Key To The Location Database.18= =20 4.3.4 Determining Caller Location..........................19= =20 4.3.5 Retaining Access To The Caller.......................21= =20 4.3.6 Minimum Delay In Call Setup..........................21= =20 4.3.7 Caller Accountability................................22= =20 4.4 Supportability of SIP Phone Deployment Scenarios.....22= =20 4.4.1 The Local Scenario...................................22= =20 4.4.2 The Regional Operator Scenario.......................22= =20 4.4.3 The National Operator Scenario.......................23= =20 4.4.4 The Visiting Phone Scenario..........................23= =20 4.4.5 The VPN Scenario.....................................23= =20 6 Security Considerations..............................24= =20 7 References...........................................24= =20 8 Acknowledgments......................................25= =20 9 Contributors.........................................25= =20 10 Author's Address.....................................26= =20 =20 1 Introduction=20 This draft is concerned with the use of SIP phones to obtain=20 emergency police, fire, or medical assistance through emergency cal= l=20 centres (ECCs) reached through the PSTN. From a legacy telephone=20 set, these centres are typically reached by dialling a reserved=20 number such as 911 in North America, 999 historically in the UK, 11= 2=20 =20 =20 Taylor Expires - November 2003 [Page 2]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 in the European Market in general, or 000 in Australia. (Globally=20 there are about 60 different emergency services numbers in use [4].= ) =20 The existing system is designed with a number of operating=20 assumptions which fail to hold in the SIP context. This document=20 explores alternatives for allowing the emergency system to continue= =20 to be effective under various scenarios involving the use of a SIP=20 phone. It identifies the major issues and discusses some of the=20 mechanisms that might be used to address these issues.=20 This document uses the term SIP phone to denote a device which plug= s=20 into a wired network. This can be a either a physical phone device= =20 or a PC running a software based SIP client (often referred to as a= =20 SIP softphone). These devices can be stationary or nomadic.=20 Scenarios involving cellular phones using SIP signalling are not=20 necessarily considered, because the current expectation is that the= y=20 use the emergency service solutions devised for cellular phones in=20 general. However, it is anticipated that many aspects of a general=20 SIP signaling solution could apply to those scenarios. The=20 requirements for Wi-Fi enabled devices (e.g. a SIP softphone with W= i- Fi access, a Wi-Fi phone etc.) using SIP signalling are considered=20 from the perspective that these devices can be represented as nomad= ic=20 SIP users and thus addressed by several of the scenarios described = in=20 this document.=20 As a final point, this document is limited to cases where the ECC i= s=20 part of the legacy network. Two related documents deal with cases=20 that have some aspects in common with the scenarios discussed in th= is=20 document. For considerations of requirements when the ECC is=20 connected directly to the IP network, see Schulzrinne [6]. For a=20 description of a global, SIP-based mechanism for identifying=20 emergency calls, see Schulzrinne [4]. The following diagram=20 summarizes the relationship between the scenarios addressed by this= =20 document and the other documents:=20 ECC IECC=20 ----------------------------------------------=20 Legacy PSTN N/A [6]=20 phones=20 =20 SIP (existing) This document. [6]=20 =20 SIP (enhanced) [4] [4],[6]=20 =20 =20 2 Definitions and Abbreviations =20 PSTN=20 Public Switched Telephone Network: the legacy circuit network.=20 =20 =20 Taylor Expires - November 2003 [Page 3]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 ECC=20 Emergency Call Centre -- a collection of operators and supporting=20 equipment connected to the PSTN, whose primary purpose is to dispat= ch=20 emergency services (police, fire department, medical aid) in respon= se=20 to incoming calls.=20 ECC in jurisdiction=20 For a particular call, an Emergency Call Centre capable of=20 dispatching emergency service to the caller's location. ECCs=20 typically serve specific geographic regions and must hand off calls= =20 where the emergency is outside that region.=20 IECC=20 Internet Protocol ECC -- an ECC that uses Internet protocols, such = as=20 SIP for call signaling, RTP for media delivery, to receive emergenc= y=20 calls. Note: requirements related to IECC access are out of scope=20 for this document, but are considered in [6].=20 PBX=20 Private Branch Exchange -- a call processing system serving a priva= te=20 telephone network.=20 DID=20 Direct-Inward-Dialing, a PSTN service allowing callers from the PST= N=20 to dial individual extensions sitting behind a PBX using PSTN=20 telephone numbers.=20 ISDN=20 Integrated Services Digital Network=20 =20 3 Existing Emergency Call System Description=20 This section provides a description of the legacy emergency call=20 services system, the high level requirements for this system, a=20 discussion of how this system operates, and the challenges that mus= t=20 be dealt with. This provides a starting point for the discussion o= f=20 how this system might deal with emergency calls initiated from a SI= P=20 phone.=20 3.1 System Components=20 The legacy PSTN emergency assistance system typically consists of t= he=20 following components. (Note: in terms of North America, the term=20 "legacy" is used to refer to "Enhanced 911" functionality.)=20 - the telephone set used by the caller=20 - the circuit connecting the telephone set to the telephone networ= k=20 - the telephone network, consisting of switches and trunk circuits= =20 =20 =20 Taylor Expires - November 2003 [Page 4]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 - the circuits connecting the ECC to the telephone network=20 - a mapping database, providing geographical location keyed on=20 calling number information supplied by the telephone network=20 - the ECC itself, staffed by operators who take incoming calls,=20 dispatch them to the appropriate emergency services, and remain=20 in touch with the caller as required to coordinate the provision= =20 of these services and provide immediate advice=20 - circuits leading to the emergency service organizations (police,= =20 fire, etc.)=20 =20 In addition to the components just listed, the legacy system=20 typically also provides a text-based emergency call service to serv= e=20 the deaf and those with a hearing or speech impediment. From the=20 point of view of this analysis, the system requirements and operati= on=20 are similar to those for voice-based emergency calling, except for=20 the difference in medium and the fact that a different number may b= e=20 dialed to initiate the call. =20 =20 3.2 System Requirements=20 The full requirements for emergency call services are country=20 specific, and include extensive technical detail. It is not the=20 intent to replicate those detailed requirements here. Rather, this= =20 section is intended to identify the key principles that underlie mo= st=20 emergency call services to provide the context for evaluating the=20 provision of these services from SIP phones. =20 The emergency services system is generally built around the followi= ng=20 requirements:=20 (1) The caller requires an easily-remembered, location-independent=20 means of identifying an emergency call. Moreover, it must be=20 possible to indicate whether this is a voice call or one to be=20 directed to a text ECC.=20 (2) Call processing entities must recognize emergency calls and=20 route them to the appropriate ECC. The ECC so reached must be=20 one which can dispatch emergency service resources to the=20 caller's location. (Note that the system also needs to be able= =20 to handle the case where a caller is reporting an emergency=20 located elsewhere, but this can be assumed to be the ECC's=20 task.)=20 (3) The telephone network can supply a calling party number that ca= n=20 serve as a key to the mapping database.=20 (4) The caller's location can be supplied to the mapping database.=20 Typically this is done in advance of the emergency call, but in= =20 some cases it can be provided when the call is made. In this=20 =20 =20 Taylor Expires - November 2003 [Page 5]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 case it must be provided at most a few tens of seconds after th= e=20 emergency call has started.=20 (5) The ECC operator can stay in touch with the caller, even though= =20 the telephone set goes on hook for an intervening period. An=20 example of when this is useful is if the caller, feeling unwell= ,=20 accidentally drops the telephone back onto its cradle, but then= =20 is able to retrieve it.=20 (6) Emergency calls are given priority handling in call processing=20 and high quality media connections. (The quality of media=20 connections is outside the scope of this document.)=20 (7) The caller can be held accountable for the call, to dissuade=20 callers from misuse of the system.=20 3.3 Legacy System Operation=20 In the legacy network, the public telephone system operator is=20 responsible for maintaining the mapping database. =20 For residential, business line, and centrex service, the main issue= =20 is reassignment of telephone numbers to new circuits and new=20 locations due to subscriber movement. =20 For PBX operation, an additional issue is that telephone number=20 assignments are under control of the private network operator. PBX= s=20 without direct-inward-dialing (DID) introduce an additional=20 challenge. Typically, the calling number is used as a unique=20 reference to identify the caller's location. However, in the case = of=20 a PBX without DID, each phone does not have a globally unique=20 telephone number that can provide this function, thus the default=20 behaviour would be to use the external number for the PBX to identi= fy=20 the location. Alternatively, various locations can be identified=20 within the business and assigned a pseudo directory number (DN),=20 which is a valid, unique E.164 number. When an emergency call is=20 initiated, the PBX uses a pseudo-DN reflective of the calling party= 's=20 location to the ECC. For either PBX scenario, administrative=20 arrangements are required to pass location data from the private=20 network to the public network operator.=20 A similar consideration governs calls from one public operator whic= h=20 must be passed to another because the latter is responsible for=20 operation of the mapping database and ECC. For the fixed line PSTN= =20 network, location data acquisition occurs at configuration time,=20 rather than on a per-call basis. =20 An emergency call in the legacy system begins when the caller dials= =20 the local emergency services number. The switch serving the caller= 's=20 =20 =20 Taylor Expires - November 2003 [Page 6]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 line receives the dialed digits, identifies the call as an emergenc= y=20 call, and determines the route to the ECC in jurisdiction through=20 configuration of telephony routing data. Configuration also=20 associates a calling number with the caller's line. The switch and= =20 succeeding telephone network route the call and pass the calling=20 number to the ECC. In the ECC, the calling number is presented to=20 the mapping database, which returns the caller's location. This is= =20 presented to the emergency operator, who may need it if the caller = is=20 unable to provide the information. =20 A special arrangement at the switch serving the ECC allows the=20 emergency operator to hold open the voice path back to the caller a= s=20 long as necessary, even if the caller goes on-hook. It should be=20 noted that this functionality is not supported for ISDN. Thus, the=20 operator can also ring the caller's line in this situation or other= s=20 where it might be necessary. =20 =20 4 SIP Phones and Emergency Services=20 4.1 A General Look At The Problem=20 SIP phones introduce a number of new elements into the system and=20 change many of the underlying assumptions. =20 =20 A primary consideration is that the SIP phone is configurable by th= e=20 user, has intelligence, and typically registers itself with element= s=20 of the local network (DHCP server, SIP registrar) which can pass it= =20 configuration data when it first comes into operation. Call=20 signalling passes through other intelligent elements -- SIP proxies= =20 and a gateway -- before reaching the telephone network. The SIP=20 phone may or may not be associated with a telephone number persisti= ng=20 beyond the duration of a single call.=20 At the transport level, the SIP phone's physical point of attachmen= t=20 is to an IP subnetwork rather than a telephone line. This introduc= es=20 additional complexity for emergency call systems. A telephone line= =20 has only a single physical appearance, but it is possible to connec= t=20 to an IP subnetwork from many different locations. A management=20 system may be able to detect activation of the SIP device, either=20 directly or through LAN equipment, but it is difficult for the=20 management system to unambiguously detect that the device is a SIP=20 device unless it is informed of this either by the SIP device or by= =20 the SIP registrar.=20 Both signalling and media may be subject to routing delays,=20 congestion, and the actions of middleboxes or encryption as they pa= ss=20 through the IP network.=20 =20 =20 Taylor Expires - November 2003 [Page 7]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 4.2 SIP Phone Deployment Scenarios=20 This section identifies the SIP phone deployment scenarios to be=20 considered with regards to the fundamental requirements identified = in=20 3.2. The numbers in parenthesis associated with each scenario are=20 used to reference the scenarios during the detailed analysis=20 presented in section 4.3. =20 4.2.1 The Local Scenario (1)=20 This scenario features stationary SIP phones with known locations a= nd=20 operating with a gateway local to the caller. This is the simplest=20 case, likely to be one that would be encountered in a corporate=20 network. The following diagram highlights the fundamental=20 configuration and elements involved for this scenario: =20 +-------+ =20 | SIP | *Known Location =20 | Phone | =20 +-------+ = =20 | = =20 | =20 | = =20 +-------+ +------+ +-----+ +------+=20 | SIP | | PSTN | / \ | ECC |=20 | Proxy |--------| G/W |-----/ PSTN \-------| |=20 +-------+ +------+ \ / +------+=20 * Known G/W \ / |=20 to reach ECC +----+ |=20 |=20 +-----+=20 | Loc | =20 | DB |=20 +-----+ =20 =20 4.2.2 The Regional Operator Scenario (2)=20 This case differs from the previous one only in that the SIP networ= k=20 is more elaborate, with multiple gateways serving multiple emergenc= y=20 service jurisdictions. It is assumed that at least one gateway can= =20 reach each ECC in the region. The following diagram highlights the= =20 fundamental configuration and elements involved for this scenario: = =20 +-------+ =20 | SIP | *Known Location (in DB1 or DB2) = =20 | Phone | =20 +-------+ = =20 | = =20 =20 =20 Taylor Expires - November 2003 [Page 8]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 | =20 | = =20 +-------+ +------+ +-----+ +------+=20 | SIP | | PSTN | / \ | ECC 1|=20 | Proxy |--------| G/W1 |-----/ PSTN \-------| |=20 + +---+ +------+ \ / +------+=20 +-------+ | \ / |=20 | | +----+ |=20 | | |=20 +-----+ | +-----+=20 | Loc | | | Loc | =20 | DB | | | DB1 |=20 +-----+ | +-----+ =20 *User's +--------+ =20 location maps | =20 to GW | =20 +------+ +-----+ +------+=20 | PSTN | / \ | ECC 2|=20 | G/W2 |-----/ PSTN \-------| |=20 +------+ \ / +------+=20 \ / |=20 +----+ |=20 +-----+=20 | Loc | =20 | DB2 |=20 +-----+=20 =20 4.2.3 The National Operator Scenario (3)=20 This scenario features stationary or low-mobility phones sparsely=20 distributed across a relatively large geographical area and operati= ng=20 with dynamically selected gateways from a single operator or=20 coalition of operators. This scenario introduces two key new factor= s:=20 . There is not necessarily an association between a user's=20 geographic location and the gateway associated with their PSTN= =20 reach-ability. Thus, the E.164 number assigned to the user for= =20 PSTN calls does not need to reflect their geographic location=20 and cannot be used for routing to an ECC or by the ECC to=20 determine the user's geographic location. =20 . It is possible that some users have no gateway local to them,=20 thus even if there were a mechanism whereby the user could=20 provide their location, the network may have no means of routi= ng=20 to the appropriate ECC. =20 The following diagram highlights the fundamental configuration and=20 elements involved for this scenario: =20 =20 =20 Taylor Expires - November 2003 [Page 9]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 +-------+ =20 | SIP | *Unknown Location (X) = =20 | Phone | =20 +-------+ = =20 | = =20 | =20 | = =20 +-------+ +------+ +-----+ +------+=20 | SIP | | PSTN | / \ | ECC 1|=20 | Proxy |--------| G/W1 |-----/ PSTN \-------| |=20 + +---+ +------+ \ / +------+=20 +-------+ | \ / |=20 | | +----+ |=20 | | |=20 +-----+ | +-----+=20 | Loc | | | Loc | =20 | DB | | | DB1 |=20 +-----+ | +-----+ =20 *Can't map +--------+ =20 to G/W related | =20 to phones geoloc | =20 +------+ +-----+ +------+=20 | PSTN | / \ | ECC 2|=20 | G/W2 |-----/ PSTN \-------| |=20 +------+ \ / +------+=20 \ / |=20 +----+ |=20 +-----+=20 | Loc | =20 | DB2 |=20 +-----+=20 +------+=20 | ECC X| =20 | |=20 +------+=20 =20 4.2.4 The Visiting Phone Scenario (4)=20 This scenario focuses on SIP phones which move about in a "friendly= "=20 network, meaning that the user is known to that network and that th= e=20 network is able to route to a geographically significant ECC for al= l=20 its users. The new element introduced by this scenario is that=20 although the user is not typically geographically located with the=20 local entities, the user is known to that network and there are=20 gateways which route to the appropriate ECC. Thus, the primary=20 difference between this scenario and Scenario 2 is that the=20 subscriber's location is dynamic, impacting both the mapping to the= =20 =20 =20 Taylor Expires - November 2003 [Page 10]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 Gateway by the SIP Proxy and potentially the mapping at the databas= e=20 used by the ECC. =20 The following diagram highlights the fundamental configuration and=20 elements involved for this scenario: =20 +-------+ =20 | SIP | *Known Location (either in DB1 or DB2) = =20 | Phone | =20 +-------+ = =20 | = =20 | =20 | = =20 +-------+ +------+ +-----+ +------+=20 | SIP | | PSTN | / \ | ECC 1|=20 | Proxy |--------| G/W1 |-----/ PSTN \-------| |=20 + +---+ +------+ \ / +------+=20 +-------+ | \ / |=20 | | +----+ |=20 | | |=20 +-----+ | +-----+=20 | Loc | | | Loc | =20 | DB | | | DB1 |=20 +-----+ | +-----+ =20 *User's +--------+ =20 location maps | =20 to GW for | =20 current location +------+ +-----+ +------+=20 | PSTN | / \ | ECC 2|=20 | G/W2 |-----/ PSTN \-------| |=20 +------+ \ / +------+=20 \ / |=20 +----+ |=20 +-----+=20 | Loc | =20 | DB2 |=20 +-----+=20 4.2.5 The VPN Scenario (5)=20 The final scenario deals with a nomadic SIP phone which attaches to= =20 an IP sub-network remote from the SIP network where it is recognize= d.=20 This scenario would be typical of a remote office, such as=20 telecommuters or a satellite office. =20 Thus, this scenario introduces factors very similar to those in the= =20 Regional Scenario (3):=20 =20 =20 Taylor Expires - November 2003 [Page 11]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 . Even if the user has an E.164 number assigned for PSTN=20 reachability, it likely does not reflect their geographic=20 location and cannot be used for routing to an ECC or by the EC= C=20 to determine the user's geographic location. =20 . Users likely have no gateway local to them, thus even if there=20 were a mechanism whereby the user could provide their location= ,=20 the network may have no means of routing to the appropriate EC= C. =20 The primary difference between this and the Regional Scenario (3) i= s=20 that no local support can be expected for calling number assignment= =20 or for recognition of location, since the need for such would be=20 transparent and not the responsibility of the local network. =20 The following diagram highlights the fundamental configuration and=20 elements involved for this scenario: =20 +-------+ =20 | SIP | *Unknown Location (X) = =20 | Phone | =20 +-------+ = =20 | = =20 | =20 | = =20 +-------+ +------+ +-----+ +------+=20 | SIP | | PSTN | / \ | ECC 1|=20 | Proxy |--------| G/W1 |-----/ PSTN \-------| |=20 + +---+ +------+ \ / +------+=20 +-------+ | \ / |=20 | | +----+ |=20 | | |=20 +-----+ | +-----+=20 | Loc | | | Loc | =20 | DB | | | DB1 |=20 +-----+ | +-----+ =20 *Can=92t map +--------+ =20 to G/W related | =20 to phones geoloc | =20 +------+ +-----+ +------+=20 | PSTN | / \ | ECC 2|=20 | G/W2 |-----/ PSTN \-------| |=20 +------+ \ / +------+=20 \ / |=20 +----+ |=20 +-----+=20 | Loc | =20 | DB2 |=20 +-----+=20 =20 =20 Taylor Expires - November 2003 [Page 12]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 +------+=20 | ECC X| =20 | |=20 +------+=20 =20 4.3 System Requirements applied to SIP Phones =20 The mechanisms required for the SIP phone and the supporting IP=20 network to meet the system requirements may vary with the=20 circumstances under which the SIP phone is deployed. This section=20 takes a general look at the system requirements first identified in= =20 section 3.2, discusses these requirements as they apply to the five= =20 deployment scenarios described in section 4.2, and identifies=20 potential ways of meeting these requirements.=20 =20 4.3.1 Identifying Emergency Calls=20 The problem of how SIP phones could make emergency calls has been=20 described in [4]. The basic problem in SIP terms is how to formula= te=20 the Request-URI. The solution to this requirement should be the sa= me=20 for all the scenarios. =20 One has to bear in mind that the process always starts with the use= r. =20 Depending on the user interface provided by the SIP phone the user=20 selects a directory entry, presses a special key, or dials the loca= l=20 emergency number. In this last case, the ready made solution is to= =20 form the Request-URI directly from the user input. =20 Where the user does not enter the emergency number directly, possib= le=20 sources of the information needed to form an appropriate Request-UR= I=20 appear to be as follows:=20 - the user at configuration time=20 - the DHCP server, using a SIP-specific option=20 - the SIP registrar, using an appropriate header field in its repl= y=20 to carry the information.=20 Because SIP phones can be taken from country to country, [4] sought= a=20 solution that would operate globally, relieving the user of the nee= d=20 to learn the local emergency number. [4] offers another possibilit= y=20 beyond DHCP or registrar configuration: use the reserved user=20 identifier "sos" in the Request-URI. This allows the outgoing prox= y=20 or even the gateway if there is no intervening proxy to recognize=20 that this is an emergency call, modify the signalling accordingly,=20 and route it to its proper destination.=20 There is still the problem of distinguishing between voice and text= =20 emergency calls. If the user enters an actual emergency number, th= at=20 =20 =20 Taylor Expires - November 2003 [Page 13]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 can be the one that serves the user's needs. If the configuration = is=20 by DHCP or SIP registrar, it may be that selection of the appropria= te=20 number is based on pre-configuration of the SIP phone as voice or=20 text based. =20 Pre-configuration also applies if the "sos" solution in [4] is used= ,=20 and consideration must be given to how the protocol will indicate a= =20 routing to the text rather than voice emergency service. This coul= d=20 be done based on the session description in the request body, but=20 that implies that the correct routing is done at the gateway rather= =20 than at a proxy. One alternative is to provide the indication=20 somewhere in the SIP header, but this is probably wrong on principl= e.=20 Another alternative is to reserve a specific "sos" subaddress for=20 text services (e.g. sos.text) in the same way that subaddresses are= =20 reserved for fire, police and other specific services. =20 4.3.2 Call Processing Recognition and Routing Of Emergency Calls=20 The previous sub-section has suggested that emergency calls will be= =20 identifiable by the content of the Request-URI. The user part of=20 this URI will consist either of the appropriate telephone number or= =20 of a global emergency identifier, "sos". In either case, to minimi= ze=20 call processing delay, any SIP proxy handling the call and also the= =20 gateway must probably be configured to recognize the emergency=20 indication.=20 Routing the call may present difficulties, because of the requireme= nt=20 to route to the ECC in jurisdiction. To achieve this, the routing=20 entity must generally have some notion of the caller's location. =20 Caller location is a separate requirement, discussed below, so for=20 purposes of the present discussion it is simply assumed that the=20 caller's location is available to any proxies and gateways handling= =20 the call. [This assumption may have to be revisited.]=20 There are two basic possibilities to consider. In some countries, = it=20 may be possible for a gateway to route an emergency call to a non- local ECC. (At least one commercial service to enable this is=20 available in the USA.) In these cases the selection of the gateway= =20 is not critical, although it would be desirable to have one as clos= e=20 as possible to the ECC in jurisdiction. The gateway must have acce= ss=20 to a database relating caller locations to ECCs and providing=20 telephone-network-routable telephone numbers for the latter.=20 The second case, applicable to Scenarios 2 and 4, is one where it i= s=20 not possible for the gateway to route a call to any but the ECC loc= al=20 to the gateway itself. In this case, the burden lies on SIP proxie= s=20 along the call path to choose the right gateway. The proxies must=20 have access to the database mapping caller locations to gateways fo= r=20 emergency access. If the "sos" URI scheme is used, the proxies als= o=20 =20 =20 Taylor Expires - November 2003 [Page 14]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 need to map "sos" to the applicable emergency number at the gateway= . =20 (Alternatively, this mapping step could be left to the gateway.)=20 A third case is one where the gateway has circuits connecting to=20 telephone switches in multiple jurisdictions, and can determine fro= m=20 caller location which outgoing circuit to use. This is probably be= st=20 analyzed as a variation on the case presented in the previous=20 paragraph, since routing through the telephone network is still=20 essentially local to the gateway.=20 A fourth case is one where the telephone network itself is able to=20 process the calling party number to determine the ECC in=20 jurisdiction. This reduces the criticality of gateway selection, b= ut=20 is subject to the limitations of the telephone network (e.g.=20 limitations in geographic scope). The procedure relies on the=20 association of an appropriate calling party number with the SIP=20 phone. This is a requirement in any event, as discussed in the nex= t=20 section. This is really a variant of Scenario 1, since the basic=20 routing happens in the PSTN, independent of the SIP phone, Proxy an= d=20 Gateways. =20 The final case is the simple one where everything is local, and no=20 database is needed to determine the right gateway or the right ECC.= =20 This applies to Scenario 1.=20 4.3.3 Calling Party Number As Key To The Location Database=20 A SIP phone may or may not be configured with a telephone number=20 which is usable as a key to the location database at the ECC in=20 jurisdiction. This configuration may come at registration time or=20 possibly before that.=20 If the phone is configured with the required number, then it has to= =20 pass this number in call signalling, presumably in the From header=20 field. Correlation at the far end with location data is a separate= =20 discussion, dealt with in the next section.=20 If the phone is not configured with a telephone number, it has to b= e=20 assigned one at the time of the call. The assignment will be made = at=20 a proxy or the gateway. The assigning entity will have to retain t= he=20 mapping between the call and the assigned number for a suitable=20 period of time. The assignment is made on the basis of the caller'= s=20 location, since that is why the number is being assigned. The=20 mapping is retained to facilitate "call back" by the ECC if require= d=20 as discussed in section 4.3.5. Determination of caller location is= =20 discussed in the next section.=20 This requirement and potential solutions should apply equally to al= l=20 the scenarios. =20 =20 =20 Taylor Expires - November 2003 [Page 15]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 4.3.4 Determining Caller Location=20 Determining the caller=92s location is one of the central problems = for=20 emergency calls in a SIP environment. The core problem is that IP=20 allows services to be accessed from anywhere, and it is therefore n= ot=20 possible, in advance, to associate a given user with a specific=20 device, nor to associate either with a specific location. =20 How the caller's location is determined and the challenges faced is= =20 very much a function of the scenario being considered. Where the S= IP=20 phone's location is stable and "managed" (Scenarios 1, 2 and 3),=20 everything can be configured in advance: the calling number in the=20 phone, and the calling number and location in the ECC's mapping=20 database. =20 When the SIP phone is not in a stable location (as in Scenarios 4 a= nd=20 5), or is not "managed" (variations on Scenarios 1, 2 and 3, e.g.=20 based on WiFi access), the problem is more complicated, and simple=20 configuration is no longer adequate. It is at this point that one=20 must consider the possible sources of information.=20 One possibility is that the SIP phone remains unaware of its=20 location. Instead, the location information is linked with the SIP= =20 phone's address of record (the one it will use in From header field= s=20 when making emergency calls) in a local database. For example, the= =20 management system overseeing the LAN can determine when a port is=20 activated and what IP address is being used at that port. A locall= y=20 configured mapping of LAN port to location can be correlated with t= he=20 SIP phone's IP address. On the other side, if the registrar captur= es=20 the SIP phone's IP address as well as its address of record and=20 supplies this to the local database, the mapping between address of= =20 record and location can be completed. =20 Another possibility is that the SIP phone itself is aware somehow o= f=20 its location and provides that information at registration time or = in=20 call signalling. The appropriate SIP entity would pass the locatio= n=20 information to the ECC's mapping database after the SIP phone has=20 been assigned a calling number. The SIP phone could potentially kn= ow=20 its location because the user has configured it, because it contain= s=20 a Global Positioning System, or because DHCP (or some other externa= l=20 system) has told it what its location is (for example, based on the= =20 LAN port). For fixed scenarios 1, 2 and 3, this option would be=20 reasonable. However, for scenarios 4, 5 and many variations of 1, 2= =20 and 3 involving phones with non-fixed access, this would require a=20 real-time interface to update the ECC's mapping database, and=20 protocol additions would likely be required to pass this location=20 information.=20 =20 =20 =20 Taylor Expires - November 2003 [Page 16]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 4.3.5 Retaining Access To The Caller=20 In the PSTN, it is an optional feature for the emergency services=20 operator to keep the caller's line open even if the caller goes on- hook temporarily. However, this requirement doesn=92t necessarily=20 translate to the SIP environment since the reachability and identit= y=20 of the user are not restricted to a single physical line. =20 For the existing system, another optional requirement for scenarios= =20 where keeping the line open is desired, but not possible, is to=20 require the emergency services operator to initiate a new call back= =20 to the caller. =20 [4] recommends that the SIP phone itself take responsibility for ca= ll=20 maintenance, by providing special alerting to the user until the=20 latter re-establishes the call.=20 This requirement and potential solutions should apply equally to al= l=20 the scenarios, albeit it is perhaps easier to enforce and implement= =20 in the fixed scenarios (1, 2 and 3). =20 =20 4.3.6 Minimum Delay In Call Setup=20 This requirement is tied to the requirement that the SIP entities=20 along the call path be able to recognize an emergency call. If the= y=20 can do so, they can give priority to handling of the call.=20 This requirement should be achievable for the majority of Scenarios= =20 (1, 2, 3 and 4), whereby the network and the user connectivity are=20 managed and more fixed. Scenario 5 introduces the element of the=20 local network, which has no way to be aware of the need for this=20 support. From one point of view, since there are no SIP elements=20 involved, there is no requirement on the local network. This=20 requirement does, however, highlight the need for some guaranteed=20 level of service (in terms of call setup delay) from the SIP phone = to=20 the first SIP proxy that recognizes this as an emergency call. =20 4.3.7 Caller Accountability=20 Caller accountability requires in the first instance that the mappi= ng=20 between calling number as presented at the ECC and the address of=20 record of the SIP phone be preserved for audit, an administrative=20 issue. Beyond this, depending on the scenario, caller identity can= =20 be vouched for by trusted entities (RFC 3325) or determined by othe= r=20 means (RFC 3323). Either way requires that the telephone network=20 trust the gateway. Without this element of trust, the chain of=20 accountability stops at the gateway itself.=20 =20 =20 Taylor Expires - November 2003 [Page 17]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 4.4 Supportability of SIP Phone Deployment Scenarios=20 Based upon the analysis in section 4.3, this section summarizes the= =20 supportability of the various SIP phone scenarios as identified in=20 section 4.2. =20 4.4.1 The Local Scenario=20 =20 The various requirements for this scenario can all be met without=20 protocol enhancements. They would be met primarily by configuration= :=20 configuration of the emergency Request-URI where the caller does no= t=20 dial the emergency number, configuration of emergency call routing = in=20 the GW as applicable, permanent assignment of a telephone number to= =20 the SIP phone, and pre-configuration of the location associated wit= h=20 that number in the mapping database. =20 4.4.2 The Regional Operator Scenario=20 This scenario assumes that at least one gateway can reach each ECC = in=20 the region. Configuration still provides an adequate solution to a= ll=20 of the requirements, but this has to include configuration of any S= IP=20 proxies in the network to ensure that they route emergency calls to= =20 the right gateways. One possibility is that the SIP telephones are= =20 assigned to outgoing proxies based on their location, with the resu= lt=20 that onward routing from the proxy is straightforward.=20 =20 4.4.3 The National Operator Scenario=20 This scenario introduces the need to be able to route to an ECC bas= ed=20 upon the geographic location of the user, which may have no relatio= n=20 to the E.164 number assigned to that user for PSTN reach-ability.=20 Even with an accurate geographic location determined as described i= n=20 4.3.4, this scenario introduces the possibility that some users hav= e=20 no gateway local to them, so it is necessary for the gateway that=20 does receive the call to route it through the PSTN to the ECC in=20 jurisdiction based upon the geographic location of the user. This = is=20 one of the possibilities considered in section 4.3.2, and may not=20 work in all countries. =20 4.4.4 The Visiting Phone Scenario=20 As with scenario 2, this scenario assumes that at least one gateway= =20 can reach each ECC in the region. The primary additional=20 functionality required beyond that identified for scenario 2 is a=20 mechanism for determining the subscriber's location, with=20 possibilities discussed in section 4.3.4. Assigning SIP telephones= =20 to outgoing proxies based on their location would thus serve in thi= s=20 scenario to ensure that the call is routed to the appropriate=20 gateway. =20 =20 =20 Taylor Expires - November 2003 [Page 18]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 4.4.5 The VPN Scenario=20 This scenario imposes strict limits on the possible outcomes. In=20 particular, it is extremely difficult in this scenario to determine= =20 the user's location without the help of the user or phone. If the=20 user can configure his/her current location in the phone, or if the= =20 phone has built-in GPS capability, and if a protocol solution exist= s=20 for carrying that location to the SIP network, it may be possible t= o=20 route the call appropriately as in the "national operator" scenario= =20 3. Otherwise, without imposing additional requirements and=20 functionality on the local network, all that can be done is to=20 connect the caller to an emergency call centre local to the SIP=20 network and hope that the person handling the call can determine=20 where to route it. =20 6 Security Considerations=20 Security requirements have been identified in the requirements=20 discussion throughout this document. In particular, the need to=20 ensure the caller identity can be vouched for by trusted identities= =20 has been identified. This is to ensure the caller can be held=20 accountable for any misuse of the system.=20 =20 In addition, in those scenarios where an external entity (e.g. DHCP= )=20 communicates location information to the SIP phone, it must be=20 possible to ensure the confidentiality, integrity and authenticatio= n=20 of this information.=20 =20 [Probably need further considerations re DOS, etc.]=20 =20 7 References=20 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP= =20 9, RFC 2026, October 1996.=20 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997.=20 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.=20 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session=20 Initiation Protocol", RFC 3261, June 2002.=20 4. H. Schulzrinne, "Emergency Services for Internet Telephony based= =20 on the Session Initiation Protocol (SIP)", draft-schulzrinne- sipping-sos-04.txt, Work in Progress, January 2003.=20 5. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk, "Use= r=20 Requirements for the Session Initiation Protocol (SIP) in Suppor= t=20 =20 =20 Taylor Expires - November 2003 [Page 19]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC=20 3351, August 2002.=20 6. H. Schulzrinne, "Requirements for Session Initiation Protocol=20 (SIP)-based Emergency Calls", draft-schulzrinne-sipping-emergency= - req-00.txt, Work in Progress, February 2003.=20 7. J Polk, John Schnizlein, Marc Linsner, "DHC Location Object with= in=20 GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00.txt, Work in=20 Progress, January 2003. =20 =20 =20 8 Acknowledgments=20 Mary Barnes and Jim McEachern=20 helped to shape the text of the initial=20 issue of this document. Steve Norreys and=20 Patrick Emery helpfully contributed=20 descriptions of emergency services operation in the UK and Australi= a,=20 respectively. And of course, Henning Schulzrinne has been trying t= o=20 get people to look at this problem for many years, and has led the=20 way with his drafts [4], [6], and others before them.=20 9 Contributors=20 Mary Barnes=20 Nortel Networks =20 2380 Performance Drive =20 Richardson, Texas 75082 =20 Tel: +1 972 684 5432=20 Email: mbarnes@nortelnetworks.com=20 =20 James McEachern=20 Nortel Networks=20 Ottawa, Ontario=20 Tel: +1 613 765 2206=20 Email: jmce@nortelnetworks.com=20 =20 10 Author's Address=20 Tom Taylor=20 Nortel Networks=20 1852 Lorraine Ave.=20 Ottawa, Ontario=20 Canada K1H 6Z8=20 Tel: +1 613 736 0961=20 Email: taylor@nortelnetworks.com=20 =20 =20 Taylor Expires - November 2003 [Page 20]=20 =0C SIP Emergency Assistance Scenarios May 2= 003=20 =20 =20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to= =20 others, and derivative works that comment on or otherwise explain i= t=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph a= re=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing= =20 the copyright notice or references to the Internet Society or other= =20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English. The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its successors or=20 assigns. This document and the information contained herein is=20 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE=20 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,EXPRESS OR= =20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."= =20 =20 =20 =20 =20 Taylor Expires - November 2003 [Page 21]=20 =0C --------------040304080704010305070803-- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Wed May 21 10:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21536 for ; Wed, 21 May 2003 10:02:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LDT3G19961 for sipping-emergency-archive@odin.ietf.org; Wed, 21 May 2003 09:29:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LDT3B19958 for ; Wed, 21 May 2003 09:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21509 for ; Wed, 21 May 2003 10:01:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IU8k-0006wt-00 for sipping-emergency-web-archive@ietf.org; Wed, 21 May 2003 10:00:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IU8k-0006wq-00 for sipping-emergency-web-archive@ietf.org; Wed, 21 May 2003 10:00:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LDT2B19948 for ; Wed, 21 May 2003 09:29:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LDS1B19883 for ; Wed, 21 May 2003 09:28:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21441 for ; Wed, 21 May 2003 10:00:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IU7l-0006vr-00 for sipping-emergency@ietf.org; Wed, 21 May 2003 09:59:21 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19IU7k-0006vY-00 for sipping-emergency@ietf.org; Wed, 21 May 2003 09:59:20 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LDxsM23507; Wed, 21 May 2003 09:59:54 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLFM71P; Wed, 21 May 2003 09:59:54 -0400 Received: from nortelnetworks.com (acart1ck.ca.nortel.com [47.129.129.62]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0KXH; Wed, 21 May 2003 09:59:53 -0400 Message-ID: <3ECB8658.4020707@nortelnetworks.com> Date: Wed, 21 May 2003 09:59:52 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: sipping-emergency@ietf.org CC: dick.rr.knight@bt.com Content-Type: multipart/mixed; boundary="------------010407080802090801090209" Subject: [Sipping-emergency] [Fwd: RE: Emergency Scenarios Document] Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------010407080802090801090209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit British Telecom have provided some useful detailed information on the operation of emergency services in the UK and have inferred some requirements on the SIP side based on this service description. I think I have covered the requirements in my draft, but I await further comments. I received some good material from Australia last month. I think I sent it on to the list, but maybe it didn't get there. If not and you would like a copy, let me know. Tom -------- Original Message -------- Subject: RE: Emergency Scenarios Document Date: Wed, 21 May 2003 13:50:00 +0100 From: dick.rr.knight@bt.com To: Taylor, Tom-PT [CAR:5N00:EXCH] ... I have attached a text file containing the work that we have done to define the service and some suggested requirements for a packet network implementation. We may have crossed on the scope so some would not be appropriate. Please do come back to me if you have any queries or would like some clarification. Dick --------------010407080802090801090209 Content-Type: text/plain; name="UK999service.txt" Content-Disposition: inline; filename="UK999service.txt" Content-Transfer-Encoding: 7bit This information is provided to assist the IETF SIPPING Working Group in developing requirements for Emergency Call Centres using the Session Initiation Protocol. 1. Overview of the UK Service. The Emergency Calling Service enables members of the general public to initiate emergency calls, using the fixed calling numbers of 112 and 999 (alternative numbers, with equal treatment), to an emergency service or to other agencies that are treated as emergency services. These calls would not normally require payment by the caller or the emergency service at the time of the call and consist of two main stages. Calls to either of the emergency numbers receive special treatment at all switches and are priority routed to an emergency operator (answering) service, which may be geographically located anywhere. The emergency operator automatically receives location information on the call origination to enable some level of detail (dependant on the type of the originating network - mobile or fixed) as to the geographic location of the caller. This information may be verified by human interaction at the emergency answering service who also establish whether the call is likely to be genuine and the service required. If it is established that this is likely to be a genuine emergency call, the second stage takes place - the caller and emergency operator are connected to the appropriate emergency service centre perceived to be local to the caller - police (who also despatch cave & mountain rescue services), fire, ambulance or coastguard. If more than one service is requested, they are connected sequentially in the order requested. Geographic location information is available automatically at the start of the call to the emergency service centre to assist in the prompt despatch of emergency assistance. The emergency operator remains on standby in the call during the initial part of the interaction between the caller and the emergency services to check that caller is responding and to provide further assistance if required. Call termination is only achieved once the last party in the call (caller, emergency operator and emergency service centre operator) has concluded. 2. Call Handling UK Service This section provides information on the special call handling granted by the signalling and switch data settings in the current UK PSTN/ISDN switched circuit network. - Fixed line calls to 112 are automatically rejected, in BT's network, if additional digits are detected 4 seconds after the digit "2" has been dialled. Although this introduces a small delay on delivering the call to the emergency operator, it prevents erroneous calls (caused by spurious '1s' and '2s' from line or equipment faults, or by repeated tapping of handset switches on lines with loop-disconnect signalling). Currently this feature auto-rejects 80% of calls to 112 in the BT network. Of the remaining 20% most are still erroneous calls that have passed the network filter (only 112 tapped-out) with only about 1% considered genuine. - All 999 calls and those 112s that pass through the network filter are marked with a protection bit. - Initially priority is granted by trunk reservation. Any route which has the potential to carry an emergency call is considered congested to ordinary calls when all but the last 2 to 6 trunks are busy (dependent on the size of routes from the switch). Only emergency calls can use these last trunks in cases of congestion. - Automatic alternative routing and Automatic Re-routing is applied to all emergency calls to improve successful call delivery under congestion conditions. - Emergency calls are exempted from call gapping and exchange overload restrictions, based on the protection bit. - If all of these advantages fail to deliver the call to an emergency operator, continuous retry over all alternative routes is applied from the originating switch. - Emergency calls are placed in a separate, priority queue at the Call Centre switches of the emergency operator (answering) service - which may also handle other non-emergency calls (such as operator assistance, etc.). - Once an emergency call reaches the emergency operator and is answered, it is subject to last party clear. - The emergency operator initiates the connection of the appropriate emergency service centre using the public PSTN (but there is no dial tone for the second stage of the call). - The full CLI of the original caller is passed to the emergency service centre in either the signalling messages that set-up the call or verbally (to enable a return call to be made if necessary). - The protection bit is also applied to the call segment that delivers the emergency call from the emergency operator service to the selected emergency service call centre (e.g. telecommunications network operator to police call centre). Alternative routing for this part of the call is under control of the operator who has alternative numbers for the required emergency service or its back-up. - The emergency operator remains active in the call (effectively as a third party) after successful contact with the emergency service centre has been established - All emergency calls are recorded as part of the call record and audit trail. 3. Geographic Location Information The geographic location information is used extensively in the Emergency Calling Service. It enables delivery to the correct emergency service centre, rapid deployment of any response to correct incident location and is also a tool in the validation of the call. The essential information used is defined below. - The service is specific to the UK and is only accessible from terminals attached (subscribed) to networks licensed in the UK. - The emergency operator centre receives the full CLI (not the CLIP supplementary service) and it is used to automatically access a database giving geographical location for fixed lines. The database entries are provided by all network operators (automatically) and can identify the building address originating a fixed line call. - Calls from mobile terminals carry information on the individual cell that the call originates from. - The emergency operator uses the address or cell information to deliver the call to the local emergency services centre identified as local to the caller for the required emergency service . - The fixed line address and cell coverage area is generally sufficient to identify which emergency service vehicle to send. Caller verification by voice that the fixed line address is also incident location, and additional caller details to narrow-down incident location within cell coverage area, is sufficient to direct vehicle to incident location. - Currently a growing one third of all emergency services centres in the UK are able to access location information automatically at the start of the call delivered by the emergency operator service. This location information is provided (within 2 seconds of call arrival) through a separate IP data link to the extended voice channel, which does however deliver the caller's CLI then used to rapidly retrieve location over the data link. 4. Call Validation - The emergency operator performs initial validation of the call using standard questions, ensuring that there is someone at the originating terminal and they do want to contact the emergency services. - This call validation by the emergency operator filters out around 40% of fixed lines calls and 75% of mobile calls. The reasons for rejection vary greatly - genuine mis-dialling, young children playing with the phone, accidental pressing of keys from mobiles in pockets/handbags, etc. The emergency operator does not reject the call based on the nature of the incident. - The emergency service centre uses the approximate location delivered automatically to help eliminate hoax calls to see if incident described is likely to be at location claimed. 5. Requirements for the Service using Packet-switched Technology The following requirements are based on the information provided above and also the Tiphon document (TS 101-878 v.1.1.1 [2]). - Emergency calls from end-users must provide a voice link and be recognised by the use of a nationally specified called user identity (i.e. service code) or by sending special indications. - It should be noted that to prevent both accidental and malicious misuse, there is no requirement for exceptional handling by-passing of validation of non-registered users. For the same reasons careful consideration needs to be given to whether users registered on one SIP server can make emergency calls on another SIP server if that is the only one available. - Emergency calls must receive priority treatment once discerned by the service code or through explicit signalling. Priority treatment must be applied to both the signalling and the user stream, if appropriate. - Emergency calls must not be subject to restrictive network management practices such as call gapping and overload restrictions. - Emergency calls from other network domains must be recognised by the service code or through explicit signalling. - Emergency calls must be subject to normal call recording, charging and accounting, etc. by serving entities in the call path (either the signalling or the user stream), if appropriate, even though billing and settlement may not result in any charge. - Originating location must be provided to geographically determine: - the correct national or regional operator centre to route the call to; - the emergency service centre appropriate to the nature and location of the emergency; - the location to accurately despatch emergency assistance. - Emergency calls must be automatically routed accurately to the location of the appropriate emergency service, recognising that emergency services are provided on a local basis but are often reached through a non-geographic intermediate call-handling centre. - The geographic location where the emergency call is originating from must be automatically determined as accurately as possible to ensure that emergency services can be directed to the precise location where the emergency has occurred. - Accurate geographic location information must be automatically available at the emergency operator centre and the local emergency service centre. - An indication of which type of emergency service is required should optionally be provided by an automatic means, but to do so is not an essential feature of an emergency calling service capability. - Emergency calls shall be routed in accordance with the nationally agreed plan for this service capability. - Emergency calls shall be completed in preference to any normal calls that may compete for resources. - Emergency calls shall be completed as soon as possible if all resources are busy. - Emergency calls shall be exempted from any restrictive management routing controls. - Emergency calls must be migrated to multi-party calls under the control of the emergency operator. - Emergency calls shall be subject to "last party clear" for successful termination. - The emergency service must be able to place a call back to the calling party in the event that they need to make a subsequent call to the caller after the initial emergency call has terminated. - Emergency calls shall be restored with priority over normal calls as an exceptional behaviour of fault restoration. Additional Requirements: - The transmission path from originator to operator must be maintained throughout the call, including during extended periods of apparent silence, for extended questioning/checking,. - All available pertinent information about the origination of the emergency call must be automatically available to the emergency operator and the emergency service centre. - An indication of an answered emergency call shall be displayed on the originating user equipment if feasible. - 6. References [1] http://www.oftel.gov.uk/publications/ind_guidelines/emer1002.htm [2] ETSI Tiphon TS 101-878 v.1.1.1 (section 6.7) - available from http://docbox.etsi.org/TIPHON/TIPHON/07-drafts/wg1/_Published/ --------------010407080802090801090209-- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri May 23 13:20:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14766 for ; Fri, 23 May 2003 13:20:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHKSx05098 for sipping-emergency-archive@odin.ietf.org; Fri, 23 May 2003 13:20:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHKRB05095 for ; Fri, 23 May 2003 13:20:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14652 for ; Fri, 23 May 2003 13:20:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGC2-0007Iq-00 for sipping-emergency-web-archive@ietf.org; Fri, 23 May 2003 13:18:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JGC1-0007IQ-00 for sipping-emergency-web-archive@ietf.org; Fri, 23 May 2003 13:18:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHKMB05041 for ; Fri, 23 May 2003 13:20:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N1fUB27515 for ; Thu, 22 May 2003 21:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08613 for ; Thu, 22 May 2003 22:13:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J22O-0007fC-00 for sipping-emergency@ietf.org; Thu, 22 May 2003 22:12:04 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19J22N-0007f8-00 for sipping-emergency@ietf.org; Thu, 22 May 2003 22:12:03 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h4N25nqZ022544 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 May 2003 22:05:49 -0400 (EDT) Message-ID: <3ECD816D.4080608@cs.columbia.edu> Date: Thu, 22 May 2003 22:03:25 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au, dick.rr.knight@bt.com, Barnes Mary , James McEachern , steve.norreys@bt.com Subject: Re: [Sipping-emergency] Emergency Scenarios Document References: <3ECA9992.9030002@nortelnetworks.com> In-Reply-To: <3ECA9992.9030002@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > centresin the PSTN, the scenarios involving stationary or nomadic SIP spelling > phones are described and then alternative strategies for supporting > the information flows for the scenarios needed to meet these > requirements are examined. The analysis presented here is a > necessary step in defining the SIP specific requirements for invoking > emergency assistance and understanding the level of functionality > that can be provided by existing SIP devices and network elements and > that which requires further development. > in the European Market in general, or 000 in Australia. (Globally I thought it was European Community? > there are about 60 different emergency services numbers in use [4].) > This document uses the term SIP phone to denote a device which plugs > into a wired network. This can be a either a physical phone device > or a PC running a software based SIP client (often referred to as a > SIP softphone). These devices can be stationary or nomadic. Why a wired network? I think the issues for a PDA or laptop or even a phone (via an Ethernet-to-802.11 bridge) that connects via an 802.11 hotspot are fairly similar. > > Scenarios involving cellular phones using SIP signalling are not > necessarily considered, because the current expectation is that they > use the emergency service solutions devised for cellular phones in > general. However, it is anticipated that many aspects of a general > SIP signaling solution could apply to those scenarios. The > requirements for Wi-Fi enabled devices (e.g. a SIP softphone with Wi- > Fi access, a Wi-Fi phone etc.) using SIP signalling are considered > from the perspective that these devices can be represented as nomadic > SIP users and thus addressed by several of the scenarios described in > this document. I would not make the distinction up front. > "legacy" is used to refer to "Enhanced 911" functionality.) You mean 'basic 911'? > the difference in medium and the fact that a different number may be > dialed to initiate the call. I think all single-number systems support TDD on the same number; that's at least true for 911, as far as I know. > (1) The caller requires an easily-remembered, location-independent > means of identifying an emergency call. Moreover, it must be > possible to indicate whether this is a voice call or one to be > directed to a text ECC. I don't think so. I think the 911 destination listens for the TDD modem tone and then switches to a TDD. This is not by number. > > (5) The ECC operator can stay in touch with the caller, even though > the telephone set goes on hook for an intervening period. An > example of when this is useful is if the caller, feeling unwell, > accidentally drops the telephone back onto its cradle, but then > is able to retrieve it. As discussed previously, this is not a universal feature. This is more of an urban legend at this point :-) > > (6) Emergency calls are given priority handling in call processing > and high quality media connections. (The quality of media > connections is outside the scope of this document.) Again, I don't think this is generally true, at least in the US. > > (7) The caller can be held accountable for the call, to dissuade > callers from misuse of the system. If you ignore pay phones :-) > > 3.3 Legacy System Operation > > In the legacy network, the public telephone system operator is > responsible for maintaining the mapping database. This is imprecise - at least in the US, there is no 'the' telephone system operator. It is generally the ILEC, but I think it would be unhelpful to imply that we live in pre-1984/pre-1996 land. > the location. Alternatively, various locations can be identified > within the business and assigned a pseudo directory number (DN), Even for phones with DID, extensions are usually not visible to the outside. (I've tried it - all of our extensions show up as 7000. We have DID in 7000 to 7199.) > A special arrangement at the switch serving the ECC allows the > emergency operator to hold open the voice path back to the caller as > long as necessary, even if the caller goes on-hook. It should be > noted that this functionality is not supported for ISDN. Thus, the > operator can also ring the caller's line in this situation or others > where it might be necessary. I would qualify this as "In analog switches, ....". Most switches today are effectively ISDN (or equivalent), so this feature is likely only available to a tiny fraction of end systems. > 4.1 A General Look At The Problem at the > signalling passes through other intelligent elements -- SIP proxies > and a gateway -- before reaching the telephone network. The SIP A SIP proxy isn't mandatory. [More in next message.] _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri May 23 14:10:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14775 for ; Fri, 23 May 2003 13:20:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHKWT05218 for sipping-emergency-archive@odin.ietf.org; Fri, 23 May 2003 13:20:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHKWB05211 for ; Fri, 23 May 2003 13:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14668 for ; Fri, 23 May 2003 13:20:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGC7-0007JF-00 for sipping-emergency-web-archive@ietf.org; Fri, 23 May 2003 13:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JGC6-0007JB-00 for sipping-emergency-web-archive@ietf.org; Fri, 23 May 2003 13:19:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHKVB05151 for ; Fri, 23 May 2003 13:20:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N2CNB29291 for ; Thu, 22 May 2003 22:12:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09275 for ; Thu, 22 May 2003 22:44:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J2WG-00006h-00 for sipping-emergency@ietf.org; Thu, 22 May 2003 22:42:56 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19J2WF-00006d-00 for sipping-emergency@ietf.org; Thu, 22 May 2003 22:42:55 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h4N2afIS025931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 May 2003 22:36:42 -0400 (EDT) Message-ID: <3ECD88AA.6010709@cs.columbia.edu> Date: Thu, 22 May 2003 22:34:18 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au, dick.rr.knight@bt.com, Barnes Mary , James McEachern , steve.norreys@bt.com Subject: Re: [Sipping-emergency] Emergency Scenarios Document References: <3ECA9992.9030002@nortelnetworks.com> In-Reply-To: <3ECA9992.9030002@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 4.2 SIP Phone Deployment Scenarios > > This section identifies the SIP phone deployment scenarios to be > considered with regards to the fundamental requirements identified in > 3.2. The numbers in parenthesis associated with each scenario are Section 3.2 > used to reference the scenarios during the detailed analysis > presented in section 4.3. Section 4.3 > network. The following diagram highlights the fundamental without VPNs and dial-in > +-------+ > | SIP | *Known Location > | Phone | > +-------+ Not just known, but fixed location. The location of lots of things are known to the user... > The final scenario deals with a nomadic SIP phone which attaches to > an IP sub-network remote from the SIP network where it is recognized. geographically remote > This scenario would be typical of a remote office, such as > telecommuters or a satellite office. Or somebody traveling and connecting via VPN to the home office - that's probably the most difficult scenario. After all, satellite offices are probably fairly stationary (unless they are true earth-orbiting satellites...) and I could just assign a block of IP addresses to that office. > emergency number. In this last case, the ready made solution is to > form the Request-URI directly from the user input. How? This always requires a dialplan since you can't just do INVITE 911 SIP/2.0 > - the user at configuration time > - the DHCP server, using a SIP-specific option > - the SIP registrar, using an appropriate header field in its reply > to carry the information. Or other SIP configuration information. > There is still the problem of distinguishing between voice and text > emergency calls. If the user enters an actual emergency number, that > can be the one that serves the user's needs. If the configuration is > by DHCP or SIP registrar, it may be that selection of the appropriate > number is based on pre-configuration of the SIP phone as voice or > text based. Unless I'm really off my rocker, the number is the same for TDD calls. See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence. > > Pre-configuration also applies if the "sos" solution in [4] is used, > and consideration must be given to how the protocol will indicate a > routing to the text rather than voice emergency service. This could > be done based on the session description in the request body, but > that implies that the correct routing is done at the gateway rather > than at a proxy. One alternative is to provide the indication > somewhere in the SIP header, but this is probably wrong on principle. > Another alternative is to reserve a specific "sos" subaddress for > text services (e.g. sos.text) in the same way that subaddresses are > reserved for fire, police and other specific services. Caller preferences is the right solution here. It fits the application perfectly, as it allows media selection. Since the routing (terminating gateway) is always exactly the same, there is no need for a distinction. Now, there is the problem that the gateway has to either be able to transparently convey 300 baud TTY (I think that survives even G.729...) or translate some text chat into TTY. I think this topic requires far more attention, since both solutions are viable: - Old-style TTY connected via analog line interface (Cisco ATA 186, say) to gateway. Result: in-band 'tone' signaling (maybe even 2833...). No difference as far as the gateway is concerned. - SIMPLE text chat. > Routing the call may present difficulties, because of the requirement > to route to the ECC in jurisdiction. To achieve this, the routing > entity must generally have some notion of the caller's location. > Caller location is a separate requirement, discussed below, so for > purposes of the present discussion it is simply assumed that the > caller's location is available to any proxies and gateways handling > the call. [This assumption may have to be revisited.] A more precise formulation is needed here. For routing, only rather crude location information is needed - in some cases, county or large-chunk-of-state will get you to the right place. (In New Jersey, every town is its own fiefdom, but NJ is not typical - I hope). For the call taker, knowing the county isn't particularly helpful in dispatching service. > > There are two basic possibilities to consider. In some countries, it > may be possible for a gateway to route an emergency call to a non- > local ECC. (At least one commercial service to enable this is > available in the USA.) In these cases the selection of the gateway > is not critical, although it would be desirable to have one as close > as possible to the ECC in jurisdiction. The gateway must have access Why? Is there an advantage to having the correct state or county? (I think so, but this should be stated. My reasoning is that somebody in the same county or state is probably familiar with the general geography and less likely to confuse Lexington, MA and Lexington, KY.) > A fourth case is one where the telephone network itself is able to > process the calling party number to determine the ECC in > jurisdiction. This reduces the criticality of gateway selection, but > is subject to the limitations of the telephone network (e.g. e.g. is always followed by a comma. See http://www.cs.columbia.edu/~hgs/etc/writing-bugs.html > If the phone is configured with the required number, then it has to > pass this number in call signalling, presumably in the From header > field. Correlation at the far end with location data is a separate > discussion, dealt with in the next section. Not necessarily. Phones might use a SIP URI like alice@example.com. Should they be required to use the phone number when dialing an emergency number? (This assumes that they can always recognize such a number.) > a Global Positioning System, or because DHCP (or some other external > system) has told it what its location is (for example, based on the Cite James Polk and my DHCP drafts here. > This requirement should be achievable for the majority of Scenarios > (1, 2, 3 and 4), whereby the network and the user connectivity are > managed and more fixed. Scenario 5 introduces the element of the > local network, which has no way to be aware of the need for this > support. From one point of view, since there are no SIP elements > involved, there is no requirement on the local network. This > requirement does, however, highlight the need for some guaranteed > level of service (in terms of call setup delay) from the SIP phone to > the first SIP proxy that recognizes this as an emergency call. You could cite the R-P work :-) > configuration of the emergency Request-URI where the caller does not > dial the emergency number, configuration of emergency call routing in See above. Numbers always have to be translated somehow - there is no 'raw' number to SIP translation. Among other things, you need to choose whether dialing 911 becomes tel:911;phone-context=... or sip:911@somewhere;user=phone, and provide either the context or the 'somewhere'. > the right gateways. One possibility is that the SIP telephones are > assigned to outgoing proxies based on their location, with the result > that onward routing from the proxy is straightforward. How assigned? > 6 Security Considerations > > Security requirements have been identified in the requirements > discussion throughout this document. In particular, the need to > ensure the caller identity can be vouched for by trusted identities > has been identified. This is to ensure the caller can be held > accountable for any misuse of the system. The converse is: How can the user be sure that they have been connected to an ECC number instead of having the proxy translate tel:911 to the local number run by the friendly call taker impersonator from the Sopranos? (I think if somebody wanted to prevent me from placing an emergency call and has access to the signaling or media path, there are more effective and less likely to be discovered ways of doing this, but this issue has come up repeatedly.) > > In addition, in those scenarios where an external entity (e.g. DHCP) e.g., > communicates location information to the SIP phone, it must be > possible to ensure the confidentiality, integrity and authentication > of this information. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue May 27 11:56:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17990 for ; Tue, 27 May 2003 11:56:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RFu3X30403 for sipping-emergency-archive@odin.ietf.org; Tue, 27 May 2003 11:56:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFu2B30400 for ; Tue, 27 May 2003 11:56:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17977 for ; Tue, 27 May 2003 11:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgmQ-0005hb-00 for sipping-emergency-web-archive@ietf.org; Tue, 27 May 2003 11:54:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KgmP-0005hV-00 for sipping-emergency-web-archive@ietf.org; Tue, 27 May 2003 11:54:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFu1B30384 for ; Tue, 27 May 2003 11:56:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFt5B30345 for ; Tue, 27 May 2003 11:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17959 for ; Tue, 27 May 2003 11:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KglV-0005hD-00 for sipping-emergency@ietf.org; Tue, 27 May 2003 11:53:29 -0400 Received: from [12.147.68.162] (helo=ns2.sccx.com) by ietf-mx with esmtp (Exim 4.12) id 19KglU-0005h1-00 for sipping-emergency@ietf.org; Tue, 27 May 2003 11:53:28 -0400 Received: from puma.lgmt.trdo (puma.scc911.com [10.100.5.15]) by ns2.sccx.com with ESMTP id h4RFoHRd016040 for ; Tue, 27 May 2003 09:50:17 -0600 (MDT) Received: from PANTHER.lgmt.trdo (panther.lgmt.trdo) by puma.lgmt.trdo (Content Technologies SMTPRS 4.3.1) with ESMTP id ; Tue, 27 May 2003 09:54:30 -0600 Received: from JAGUAR.lgmt.trdo ([172.20.150.65]) by PANTHER.lgmt.trdo with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 May 2003 09:54:30 -0600 Content-Class: urn:content-classes:message Subject: RE: [Sipping-emergency] Emergency Scenarios Document MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 27 May 2003 10:54:29 -0500 Message-ID: <19B3D8818B23554581D1E8C65C2964392DB8B2@jaguar.scc911.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sipping-emergency] Emergency Scenarios Document Thread-Index: AcMhT8Beu7iKP+VNSVCw0L7MpK9jigDE0Qgg From: "McCalmont, Patti" To: Cc: , , "Barnes Mary" , "James McEachern" , X-OriginalArrivalTime: 27 May 2003 15:54:30.0610 (UTC) FILETIME=[426C5320:01C32468] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RFt6B30347 Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Section 3.3 > In the legacy network ....mapping database. The term "mapping database is used a few times within the document. Is mapping database trying to refer to a selective routing database that is used to determine how to route the call based on the location of the caller to the PSAP? If so, a better term would be location database or selective routing database (term used in US/Canada. Or, is it trying to refer to the phone number to location information, Automatic Location Identification (ALI) database, or both? Some clarification is needed. For PBX operation, an additional issue is that telephone number assignments are under control of the private network operator. PBXs without direct-inward-dialing (DID) introduce an additional challenge. Typically, the calling number is used as a unique reference to identify the caller's location. Without CAMA or PRI connections for emergency calls, those PBX locations cannot convey the caller's identity (even with DID). What is typically used is the Billing Number or Main Directory number for the PBX when they don't have the CAMA/PRI. There may need some clarification as connections required in order to provide the DID stations or is that what was trying to be said with "administrative arrangements"? A special arrangement at the switch serving the ECC allows the emergency operator to hold open the voice path back to the caller as long as necessary, even if the caller goes on-hook. It should be noted that this functionality is not supported for ISDN. Thus, the operator can also ring the caller's line in this situation or others where it might be necessary. Call Hold applies globally to Basic 911 and is an option for Enhanced 9-1-1 so which type of "legacy network" is described in this section. If Enhanced 9-1-1, then Call Hold (as stated later) is an optional feature. Henning wrote: I would qualify this as "In analog switches, ....". Most switches today are effectively ISDN (or equivalent), so this feature is likely only available to a tiny fraction of end systems. Most switches today are digital so I don't like the term "analog switches". It would be better to talk about the interfaces into the switch as being analog or digital (ISDN). Section 4.3.1 > There is still the problem of distinguishing between voice and text > emergency calls. If the user enters an actual emergency number, that > can be the one that serves the user's needs. If the configuration is > by DHCP or SIP registrar, it may be that selection of the appropriate > number is based on pre-configuration of the SIP phone as voice or > text bas Henning wrote: Unless I'm really off my rocker, the number is the same for TDD calls. See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence. He is correct. It's the equipment at the PSAP that detects the call as TDD nothing in how the user dials. Patti McCalmont _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue May 27 12:48:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19355 for ; Tue, 27 May 2003 12:48:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RGmK102476 for sipping-emergency-archive@odin.ietf.org; Tue, 27 May 2003 12:48:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RGmKB02473 for ; Tue, 27 May 2003 12:48:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19332 for ; Tue, 27 May 2003 12:48:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Khb1-00065Y-00 for sipping-emergency-web-archive@ietf.org; Tue, 27 May 2003 12:46:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Khb0-00065V-00 for sipping-emergency-web-archive@ietf.org; Tue, 27 May 2003 12:46:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RGmJB02465 for ; Tue, 27 May 2003 12:48:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RGluB02433 for ; Tue, 27 May 2003 12:47:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19318 for ; Tue, 27 May 2003 12:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Khad-00065G-00 for sipping-emergency@ietf.org; Tue, 27 May 2003 12:46:19 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19Khac-00065C-00 for sipping-emergency@ietf.org; Tue, 27 May 2003 12:46:18 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RGlHc24208; Tue, 27 May 2003 12:47:17 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF6T21; Tue, 27 May 2003 12:47:17 -0400 Received: from nortelnetworks.com (acart1ct.ca.nortel.com [47.129.129.69]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0M0D; Tue, 27 May 2003 12:47:17 -0400 Message-ID: <3ED3968C.9060601@nortelnetworks.com> Date: Tue, 27 May 2003 12:47:08 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "McCalmont, Patti" CC: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au, dick.rr.knight@bt.com, "Mary Barnes" , "James McEachern" , steve.norreys@bt.com Subject: Re: [Sipping-emergency] Emergency Scenarios Document References: <19B3D8818B23554581D1E8C65C2964392DB8B2@jaguar.scc911.com> In-Reply-To: <19B3D8818B23554581D1E8C65C2964392DB8B2@jaguar.scc911.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'll be replying to Henning's comments, but since this note is relatively short I'll address it first. McCalmont, Patti wrote: > Section 3.3 > > >> In the legacy network ....mapping database. > > > The term "mapping database is used a few times within the document. Is mapping > database trying to refer to a selective routing database that is used to > determine how to route the call based on the location of the caller to the PSAP? > If so, a better term would be location database or selective routing database > (term used in US/Canada. Or, is it trying to refer to the phone number to > location information, Automatic Location Identification (ALI) database, or both? > Some clarification is needed. [PTT] I'll clarify. In North American terms I'm referring to the ALI database. > > For PBX operation, an additional issue is that telephone number assignments are > under control of the private network operator. PBXs without > direct-inward-dialing (DID) introduce an additional challenge. Typically, the > calling number is used as a unique reference to identify the caller's location. > > Without CAMA or PRI connections for emergency calls, those PBX locations cannot > convey the caller's identity (even with DID). What is typically used is the > Billing Number or Main Directory number for the PBX when they don't have the > CAMA/PRI. There may need some clarification as connections required in order to > provide the DID stations or is that what was trying to be said with > "administrative arrangements"? [PTT] I seem to have gotten this wrong, as you and Henning point out. I'll have to extend the discussion. > > > A special arrangement at the switch serving the ECC allows the emergency operator > to hold open the voice path back to the caller as long as necessary, even if the > caller goes on-hook. It should be noted that this functionality is not supported > for ISDN. Thus, the operator can also ring the caller's line in this situation or > others where it might be necessary. > > Call Hold applies globally to Basic 911 and is an option for Enhanced 9-1-1 so > which type of "legacy network" is described in this section. If Enhanced 9-1-1, > then Call Hold (as stated later) is an optional feature. > > Henning wrote: I would qualify this as "In analog switches, ....". Most switches > today are effectively ISDN (or equivalent), so this feature is likely only > available to a tiny fraction of end systems. > > Most switches today are digital so I don't like the term "analog switches". It > would be better to talk about the interfaces into the switch as being analog or > digital (ISDN). [PTT] Yes, that's right. In North America, there aren't many ISDN lines, but in Europe there are. In both places, most switches are digital. > > > Section 4.3.1 > >> There is still the problem of distinguishing between voice and text emergency >> calls. If the user enters an actual emergency number, that can be the one that >> serves the user's needs. If the configuration is by DHCP or SIP registrar, it >> may be that selection of the appropriate number is based on pre-configuration >> of the SIP phone as voice or text bas > > > Henning wrote: Unless I'm really off my rocker, the number is the same for TDD > calls. See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence. > > He is correct. It's the equipment at the PSAP that detects the call as TDD > nothing in how the user dials. [PTT] That's in North America. It's different in Australia. I suppose I should modify the discussion to make it clear that the requirement is only present in some countries. > > Patti McCalmont > > _______________________________________________ Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Wed May 28 05:10:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22628 for ; Wed, 28 May 2003 05:10:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4S9A2a19462 for sipping-emergency-archive@odin.ietf.org; Wed, 28 May 2003 05:10:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S9A2B19459 for ; Wed, 28 May 2003 05:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22617 for ; Wed, 28 May 2003 05:09:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kwv1-0000GF-00 for sipping-emergency-web-archive@ietf.org; Wed, 28 May 2003 05:08:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Kwv0-0000GB-00 for sipping-emergency-web-archive@ietf.org; Wed, 28 May 2003 05:08:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S9A1B19430 for ; Wed, 28 May 2003 05:10:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S8PJB14719 for ; Wed, 28 May 2003 04:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21132 for ; Wed, 28 May 2003 04:25:16 -0400 (EDT) From: dick.rr.knight@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KwDk-0007ht-00 for sipping-emergency@ietf.org; Wed, 28 May 2003 04:23:40 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt03.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19KwDk-0007hc-00 for sipping-emergency@ietf.org; Wed, 28 May 2003 04:23:40 -0400 Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 28 May 2003 09:24:51 +0100 Message-ID: To: taylor@nortelnetworks.com, PMcCalmont@intrado.com Cc: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au, mbarnes@nortelnetworks.com, jmce@nortelnetworks.com, steve.norreys@bt.com Subject: RE: [Sipping-emergency] Emergency Scenarios Document Date: Wed, 28 May 2003 09:24:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , With respect to the discussion on call hold, please note that there are digital switches that support "last party clear" for certain applications, including emergency calls (911, 112, 999 etc.). It is true that this MAY not be supported by ISUP, but it is supported with other SS7 user parts - notably TUP and a UK variant NUP. Regards, Dick Knight British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: 27 May 2003 17:47 To: McCalmont, Patti Cc: sipping-emergency@ietf.org; Patrick.Emery@aca.gov.au; Knight,RR,Dick,XGH4 KNIGHTRR R; Mary Barnes; James McEachern; Norreys,SE,Steve,XGH4 R Subject: Re: [Sipping-emergency] Emergency Scenarios Document I'll be replying to Henning's comments, but since this note is relatively short I'll address it first. McCalmont, Patti wrote: > Section 3.3 > > >> In the legacy network ....mapping database. > > > The term "mapping database is used a few times within the document. Is mapping > database trying to refer to a selective routing database that is used to > determine how to route the call based on the location of the caller to the PSAP? > If so, a better term would be location database or selective routing database > (term used in US/Canada. Or, is it trying to refer to the phone number to > location information, Automatic Location Identification (ALI) database, or both? > Some clarification is needed. [PTT] I'll clarify. In North American terms I'm referring to the ALI database. > > For PBX operation, an additional issue is that telephone number assignments are > under control of the private network operator. PBXs without > direct-inward-dialing (DID) introduce an additional challenge. Typically, the > calling number is used as a unique reference to identify the caller's location. > > Without CAMA or PRI connections for emergency calls, those PBX locations cannot > convey the caller's identity (even with DID). What is typically used is the > Billing Number or Main Directory number for the PBX when they don't have the > CAMA/PRI. There may need some clarification as connections required in order to > provide the DID stations or is that what was trying to be said with > "administrative arrangements"? [PTT] I seem to have gotten this wrong, as you and Henning point out. I'll have to extend the discussion. > > > A special arrangement at the switch serving the ECC allows the emergency operator > to hold open the voice path back to the caller as long as necessary, even if the > caller goes on-hook. It should be noted that this functionality is not supported > for ISDN. Thus, the operator can also ring the caller's line in this situation or > others where it might be necessary. > > Call Hold applies globally to Basic 911 and is an option for Enhanced 9-1-1 so > which type of "legacy network" is described in this section. If Enhanced 9-1-1, > then Call Hold (as stated later) is an optional feature. > > Henning wrote: I would qualify this as "In analog switches, ....". Most switches > today are effectively ISDN (or equivalent), so this feature is likely only > available to a tiny fraction of end systems. > > Most switches today are digital so I don't like the term "analog switches". It > would be better to talk about the interfaces into the switch as being analog or > digital (ISDN). [PTT] Yes, that's right. In North America, there aren't many ISDN lines, but in Europe there are. In both places, most switches are digital. > > > Section 4.3.1 > >> There is still the problem of distinguishing between voice and text emergency >> calls. If the user enters an actual emergency number, that can be the one that >> serves the user's needs. If the configuration is by DHCP or SIP registrar, it >> may be that selection of the appropriate number is based on pre-configuration >> of the SIP phone as voice or text bas > > > Henning wrote: Unless I'm really off my rocker, the number is the same for TDD > calls. See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence. > > He is correct. It's the equipment at the PSAP that detects the call as TDD > nothing in how the user dials. [PTT] That's in North America. It's different in Australia. I suppose I should modify the discussion to make it clear that the requirement is only present in some countries. > > Patti McCalmont > > _______________________________________________ Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency