From mailnull@www1.ietf.org Mon Feb 10 16:24:12 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 QAA26475 for ; Mon, 10 Feb 2003 16:24:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ALWkG13334 for sipping-emergency-archive@odin.ietf.org; Mon, 10 Feb 2003 16:32:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ALWkp13331 for ; Mon, 10 Feb 2003 16:32:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26451 for ; Mon, 10 Feb 2003 16:23:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ALWjp13323 for ; Mon, 10 Feb 2003 16:32:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ALVYp12900 for ; Mon, 10 Feb 2003 16:31:34 -0500 Received: from cnri.reston.va.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26384 for ; Mon, 10 Feb 2003 16:22:29 -0500 (EST) Received: from action2.cnri.reston.va.us (cnri-7-160.cnri.reston.va.us [132.151.7.160]) by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h1ALQBN07558 for ; Mon, 10 Feb 2003 16:26:11 -0500 (EST) Message-Id: <5.0.0.25.2.20030210162550.00b0fe40@mailbox.cnri.reston.va.us> X-Sender: gcunning@mailbox.cnri.reston.va.us X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 10 Feb 2003 16:26:08 -0500 To: sipping-emergency@ietf.org From: Greg Cunningham Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping-emergency] test 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: , test 1 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 11 02:40: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 CAA22516 for ; Tue, 11 Feb 2003 02:40:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B7n1u26473 for sipping-emergency-archive@odin.ietf.org; Tue, 11 Feb 2003 02:49:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B7n1p26468 for ; Tue, 11 Feb 2003 02:49:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22507 for ; Tue, 11 Feb 2003 02:39:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B7n0p26460 for ; Tue, 11 Feb 2003 02:49:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B7mIp26442 for ; Tue, 11 Feb 2003 02:48:18 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22502 for ; Tue, 11 Feb 2003 02:39:01 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1B7ggKV029762 for ; Tue, 11 Feb 2003 08:42:42 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5KY7KV; Tue, 11 Feb 2003 08:42:41 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1B7gfmT003087 for ; Tue, 11 Feb 2003 09:42:41 +0200 (EET) Message-ID: <3E48A970.481C7DCA@lmf.ericsson.se> Date: Tue, 11 Feb 2003 09:42:40 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Emergency Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Emergency Calls Team 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: Emergency Calls SIPPING Design Team List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I have already set up the mailing list and the web page for the Emergency Call design team. sipping-emergency@ietf.org http://www.softarmor.com/sipping/teams/emergency/ This message is also a TEST for the mailing list. Please, let me know if you have received this message. Thanks, Gonzalo _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Thu Feb 13 09:35:07 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 JAA12965 for ; Thu, 13 Feb 2003 09:35:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DEj2j24799 for sipping-emergency-archive@odin.ietf.org; Thu, 13 Feb 2003 09:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DEj2p24796 for ; Thu, 13 Feb 2003 09:45:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12955 for ; Thu, 13 Feb 2003 09:34:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DEj1p24788 for ; Thu, 13 Feb 2003 09:45:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DEiMp24752 for ; Thu, 13 Feb 2003 09:44:22 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12946 for ; Thu, 13 Feb 2003 09:33:56 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DEbeAv021675; Thu, 13 Feb 2003 15:37:40 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 1XQV63P9; Thu, 13 Feb 2003 15:37:40 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1DEbemT026628; Thu, 13 Feb 2003 16:37:40 +0200 (EET) Message-ID: <3E4BADB2.FF5B37BE@lmf.ericsson.se> Date: Thu, 13 Feb 2003 16:37:38 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "James M. Polk" CC: Emergency References: <4.3.2.7.2.20030212124703.04686530@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Re: SIPPING and Emergency calls 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 James, I have just subscribed you to the mailing list of the design team and added your name to the web page. http://www.softarmor.com/sipping/teams/emergency/ Thanks for your interest, Gonzalo "James M. Polk" wrote: > > Guys > > Jon Peterson just mentioned to me that there was a call last Friday > regarding setting up a SIPPING design team for Emergency calls. Glad he > did, because I have an ID partially written that is a framework ID for > 911-like services into SIPPING. This leverages Henning's sos@ ID and > related work regarding location from recent Geopriv efforts (I recently > submitted an ID on the requirements for a SIP Coordinate Location Header). > I was going to float this Emergency ID to a few people (including Henning) > later this week/weekend for comments and/or contributions. It is not ready > to submit by any means, currently. > > Please don't take this as preemptive (meaning I want to be the center of > this) - I am just mentioning this area of focus of mine (as I did to > Henning in Atlanta) to inform the chairs of my work. > > Jon did mention a SIPPING Emergency Design team - and I want to be part of > this team if possible. > > comments > > cheers, > James > > ************************************* > "People generally demand more respect for their own rights than > they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Feb 17 08:20:55 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 IAA21737 for ; Mon, 17 Feb 2003 08:20:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HDQ2F25808 for sipping-emergency-archive@odin.ietf.org; Mon, 17 Feb 2003 08:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HDQ2p25805 for ; Mon, 17 Feb 2003 08:26:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21731 for ; Mon, 17 Feb 2003 08:20:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HDQ1p25797 for ; Mon, 17 Feb 2003 08:26:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HDPQp25766 for ; Mon, 17 Feb 2003 08:25:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21719 for ; Mon, 17 Feb 2003 08:19:47 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1HDNYKV013529; Mon, 17 Feb 2003 14:23:35 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4FG78T; Mon, 17 Feb 2003 14:23:34 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1HDNYll018607; Mon, 17 Feb 2003 15:23:34 +0200 (EET) Message-ID: <3E50E254.5D5F7D18@lmf.ericsson.se> Date: Mon, 17 Feb 2003 15:23:32 +0200 X-Sybari-Trust: fd7bc568 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Emergency CC: kimberly.s.king@saic.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Limberly joins the team 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 Folks, I have just added Kimberly King to this mailing list. For a list of current members of the design team see: http://www.softarmor.com/sipping/teams/emergency/ Regards, Gonzalo _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Feb 17 16:43:46 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 QAA02151 for ; Mon, 17 Feb 2003 16:43:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HLn2v25641 for sipping-emergency-archive@odin.ietf.org; Mon, 17 Feb 2003 16:49:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HLn2p25638 for ; Mon, 17 Feb 2003 16:49:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02135 for ; Mon, 17 Feb 2003 16:43:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HLn1p25630 for ; Mon, 17 Feb 2003 16:49:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HLmxp25615 for ; Mon, 17 Feb 2003 16:48:59 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02132 for ; Mon, 17 Feb 2003 16:43:12 -0500 (EST) 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.3/8.12.3) with ESMTP id h1HLkwDc001754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 17 Feb 2003 16:46:59 -0500 (EST) Message-ID: <3E51586C.7090101@cs.columbia.edu> Date: Mon, 17 Feb 2003 16:47:24 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] First rough draft on emergency call requirements 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 http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-00.pdf I'm sure it's missing a lot, but it's at least a target to shoot at. I plan to wait with submission until at least the initial flood of comments has come in... Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Feb 17 17:27: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 RAA02882 for ; Mon, 17 Feb 2003 17:27:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HMX2d28618 for sipping-emergency-archive@odin.ietf.org; Mon, 17 Feb 2003 17:33:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HMX2p28615 for ; Mon, 17 Feb 2003 17:33:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02865 for ; Mon, 17 Feb 2003 17:27:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HMX1p28607 for ; Mon, 17 Feb 2003 17:33:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HMWMp28575 for ; Mon, 17 Feb 2003 17:32:22 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02843 for ; Mon, 17 Feb 2003 17:26:34 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 17 Feb 2003 14:30:40 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA14032 for ; Mon, 17 Feb 2003 14:30:21 -0800 (PST) Message-Id: <4.3.2.7.2.20030217161831.047e6110@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 16:29:07 -0600 To: sipping-emergency@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping-emergency] General Question about Scope of this list 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: , All Since I wasn't in the initial concall for this list's creation, can I ask what the general scope is of this design team? Is it SIP for e911/112 (sos@)? Is it SIP for all Emergency Services (GETS, IEPREP, GTPS, FEMA, etc)? Is it SIP for Gov/Military Preferential Emergency Communications (MLPP)? Any combination of the 3 listed above? The first 3 of the above qualify as "emergency", but in reading Henning's draft, that ID seems much skewed towards only the 1st case above, yet it is similar to this new list's name. I'm just looking for guidance and boundaries, folks cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Feb 17 18:01:43 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 SAA03456 for ; Mon, 17 Feb 2003 18:01:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HN71J30500 for sipping-emergency-archive@odin.ietf.org; Mon, 17 Feb 2003 18:07:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HN71p30497 for ; Mon, 17 Feb 2003 18:07:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03440 for ; Mon, 17 Feb 2003 18:01:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HN70p30445 for ; Mon, 17 Feb 2003 18:07:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HN6Zp30390 for ; Mon, 17 Feb 2003 18:06:35 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03424 for ; Mon, 17 Feb 2003 18:00:46 -0500 (EST) 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.3/8.12.3) with ESMTP id h1HN4GDc011920 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Feb 2003 18:04:18 -0500 (EST) Message-ID: <3E516A89.90901@cs.columbia.edu> Date: Mon, 17 Feb 2003 18:04:41 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] General Question about Scope of this list References: <4.3.2.7.2.20030217161831.047e6110@localhost> In-Reply-To: <4.3.2.7.2.20030217161831.047e6110@localhost> 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 answer the easy ones... James M. Polk wrote: > All > > Is it SIP for e911/112 (sos@)? Yes. > > Is it SIP for all Emergency Services (GETS, IEPREP, GTPS, FEMA, etc)? No. Despite the common word 'emergency', these two have very little to do with each other, in my opinion. > > Is it SIP for Gov/Military Preferential Emergency Communications (MLPP)? No. > > Any combination of the 3 listed above? I really don't want to replicate IEPREP. That already is a highly effective working group. > > The first 3 of the above qualify as "emergency", but in reading > Henning's draft, that ID seems much skewed towards only the 1st case > above, yet it is similar to this new list's name. > > I'm just looking for guidance and boundaries, folks Given that this confusion seems to be perennial, Gonzalo might want to update the web page. > > cheers, > James > > ************************************* > "People generally demand more respect for their own rights than > they are willing to allow for others" > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Feb 17 18:24:43 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 SAA03828 for ; Mon, 17 Feb 2003 18:24:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HNU1d32023 for sipping-emergency-archive@odin.ietf.org; Mon, 17 Feb 2003 18:30:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HNU1p32020 for ; Mon, 17 Feb 2003 18:30:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03822 for ; Mon, 17 Feb 2003 18:24:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HNU0p32008 for ; Mon, 17 Feb 2003 18:30:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HNThp31973 for ; Mon, 17 Feb 2003 18:29:43 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03806 for ; Mon, 17 Feb 2003 18:23:53 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 17 Feb 2003 15:28:01 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA02909; Mon, 17 Feb 2003 15:27:40 -0800 (PST) Message-Id: <4.3.2.7.2.20030217172553.02131130@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 17:27:45 -0600 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sipping-emergency] General Question about Scope of this list Cc: sipping-emergency@ietf.org In-Reply-To: <3E516A89.90901@cs.columbia.edu> References: <4.3.2.7.2.20030217161831.047e6110@localhost> <4.3.2.7.2.20030217161831.047e6110@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 06:04 PM 2/17/2003 -0500, Henning Schulzrinne wrote: >Given that this confusion seems to be perennial, Gonzalo might want to >update the web page. Might not be a bad idea to have a piece of text explaining what this design team is working on - and what is considered out of scope. >>cheers, >>James >> ************************************* >>"People generally demand more respect for their own rights than >> they are willing to allow for others" > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Feb 21 03:58: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 DAA23562 for ; Fri, 21 Feb 2003 03:58:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L952E05086 for sipping-emergency-archive@odin.ietf.org; Fri, 21 Feb 2003 04:05:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L952p05079 for ; Fri, 21 Feb 2003 04:05:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23556 for ; Fri, 21 Feb 2003 03:57:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L950p05067 for ; Fri, 21 Feb 2003 04:05:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L945p05024 for ; Fri, 21 Feb 2003 04:04:05 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23535 for ; Fri, 21 Feb 2003 03:56:35 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1L90HAv015857; Fri, 21 Feb 2003 10:00:17 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4GJNRD; Fri, 21 Feb 2003 10:00:17 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1L90Gll012714; Fri, 21 Feb 2003 11:00:16 +0200 (EET) Message-ID: <3E55EA9F.FB3489BB@lmf.ericsson.se> Date: Fri, 21 Feb 2003 11:00:15 +0200 X-Sybari-Trust: ea82c6fa 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: "James M. Polk" , sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] General Question about Scope of this list References: <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii 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 Henning, > Given that this confusion seems to be perennial, Gonzalo might want to > update the web page. Does it look clearer now? http://www.softarmor.com/sipping/teams/emergency/ Gonzalo _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Feb 21 09:15: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 JAA00817 for ; Fri, 21 Feb 2003 09:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LEN2U25879 for sipping-emergency-archive@odin.ietf.org; Fri, 21 Feb 2003 09:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEN2p25876 for ; Fri, 21 Feb 2003 09:23:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00771 for ; Fri, 21 Feb 2003 09:15:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEN1p25866 for ; Fri, 21 Feb 2003 09:23:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEMcp25824 for ; Fri, 21 Feb 2003 09:22:38 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00765 for ; Fri, 21 Feb 2003 09:15:03 -0500 (EST) 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.3/8.12.3) with ESMTP id h1LEIqxw027037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Feb 2003 09:18:53 -0500 (EST) Message-ID: <3E563552.6000503@cs.columbia.edu> Date: Fri, 21 Feb 2003 09:18:58 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping-emergency@ietf.org References: <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> In-Reply-To: <3E55EA9F.FB3489BB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 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 Unfortunately, I have received no comments on http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-00.pdf Since the deadline for -00 I-Ds is Monday morning, I will submit the draft as is. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Feb 21 09:23: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 JAA01163 for ; Fri, 21 Feb 2003 09:23:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LEV1526253 for sipping-emergency-archive@odin.ietf.org; Fri, 21 Feb 2003 09:31:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEV1p26250 for ; Fri, 21 Feb 2003 09:31:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01154 for ; Fri, 21 Feb 2003 09:23:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEV0p26240 for ; Fri, 21 Feb 2003 09:31:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEUhp26213 for ; Fri, 21 Feb 2003 09:30:43 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01150 for ; Fri, 21 Feb 2003 09:23:07 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for sipping-emergency@ietf.org; Fri, 21 Feb 2003 09:25:53 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003022109264608478 ; Fri, 21 Feb 2003 09:26:46 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 09:26:28 -0500 Message-Id: From: "King, Kimberly S." To: "'Henning Schulzrinne'" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 Date: Fri, 21 Feb 2003 09:26:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , >Unfortunately, I have received no comments on >http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping >-emergency-req-00.pdf I'm sorry Henning. There are some items that aren't clear to me but I feel the problem may be with me and wanted to read it again to be fair to you. Kimberly _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Feb 21 10:53:56 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 KAA04380 for ; Fri, 21 Feb 2003 10:53:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LG13A00344 for sipping-emergency-archive@odin.ietf.org; Fri, 21 Feb 2003 11:01:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LG13p00341 for ; Fri, 21 Feb 2003 11:01:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04331 for ; Fri, 21 Feb 2003 10:53:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LG12p00333 for ; Fri, 21 Feb 2003 11:01:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LG0ep00304 for ; Fri, 21 Feb 2003 11:00:40 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04312 for ; Fri, 21 Feb 2003 10:53:02 -0500 (EST) 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.3/8.12.3) with ESMTP id h1LFuqxw002233 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Feb 2003 10:56:53 -0500 (EST) Message-ID: <3E564C4A.4090903@cs.columbia.edu> Date: Fri, 21 Feb 2003 10:56:58 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] NENA draft on requirements for last-mile VoIP 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 This draft was completed yesterday: http://www.cs.columbia.edu/sip/drafts/NENA_TID_IP_PSAP_I-F_DRAFT.doc I will be selectively citing some of the call setup-related requirements in the requirements draft. The draft was written by a group consisting of traditional telephony contributors, operational personnel and vendor-affiliated folks, so not all the sections are written at the same level. Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Feb 21 13:18:52 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 NAA09782 for ; Fri, 21 Feb 2003 13:18:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LIQ2110433 for sipping-emergency-archive@odin.ietf.org; Fri, 21 Feb 2003 13:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIQ2p10430 for ; Fri, 21 Feb 2003 13:26:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09771 for ; Fri, 21 Feb 2003 13:18:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIQ1p10409 for ; Fri, 21 Feb 2003 13:26:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIPFp10370 for ; Fri, 21 Feb 2003 13:25:15 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09739 for ; Fri, 21 Feb 2003 13:17:33 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 21 Feb 2003 10:21:33 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA00939; Fri, 21 Feb 2003 10:21:23 -0800 (PST) Message-Id: <4.3.2.7.2.20030221121940.04c05700@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 12:21:29 -0600 To: Henning Schulzrinne , sipping-emergency@ietf.org From: "James M. Polk" In-Reply-To: <3E563552.6000503@cs.columbia.edu> References: <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 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: , At 09:18 AM 2/21/2003 -0500, Henning Schulzrinne wrote: >Unfortunately, I have received no comments on >http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-00.pdf > >Since the deadline for -00 I-Ds is Monday morning, I will submit the draft >as is. sorry about the timing. I will send you comments today (FRIDAY).... I've been caught in several other battles that were to do with my writing something, and to be honest, those took priority. I should be finishing those up this afternoon, and can dedicate some time to your draft in time for you to review them. >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 14:52:22 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 OAA14842 for ; Sat, 22 Feb 2003 14:52:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MK04J02110 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 15:00:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MK03p02107 for ; Sat, 22 Feb 2003 15:00:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14836 for ; Sat, 22 Feb 2003 14:51:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MK02p02087 for ; Sat, 22 Feb 2003 15:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MJxKp02022 for ; Sat, 22 Feb 2003 14:59:20 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14822 for ; Sat, 22 Feb 2003 14:51:05 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 22 Feb 2003 11:54:41 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA18430; Sat, 22 Feb 2003 11:54:57 -0800 (PST) Message-Id: <4.3.2.7.2.20030222120157.024467d0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 22 Feb 2003 13:54:38 -0600 To: Henning Schulzrinne , sipping-emergency@ietf.org From: "James M. Polk" In-Reply-To: <3E563552.6000503@cs.columbia.edu> References: <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 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: , At 09:18 AM 2/21/2003 -0500, Henning Schulzrinne wrote: >Unfortunately, I have received no comments on >http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-00.pdf > >Since the deadline for -00 I-Ds is Monday morning, I will submit the draft >as is. Henning (and all) Because I've had much writing of my own this past few weeks, and with the deadline approaching for -00 IDs, I apologize for this coming so late. Here are a few questions and comments regrading this ID: #1 - From the Abstract: you mention MEGACO and H.323 (not an IETF protocol) - yet MGCP is used a fair amount for IP control within the US. #2 - PSAP stands for "Public Safety Answering Point" (not "...Service Access..."). I was corrected recently too by our NENA engineer within Cisco. #3 - "Emergency call center (ECC): An emergency call center (ECC) receives emergency calls within a specific geographic area..." Comment: London has what you refer to as ECCs, but the have all calls from the surrounding regional area come into a single center, the Call taker(s) determines where the call is coming from, then the emergency personnel are dispatched to the appropriate location from that centralized ECC. In other words, local emergency personnel are not called, they are dispatched by the ECC in London. This might be a subtle difference to your intent, but it is fairly different than the US model where you call (or are patched through to) the local ECC. #4 - From section 4 "Last Mile" you have omitted Cable access. I mention this because existing HFC Broadband connectivity can be as much as 100 miles away from the MSO Headend facility. This could easily have an affect on which ECC (PSAP is appropriate to contact). This is in contrast to DSL which is typically limited to 22,000 ft from the CO, with most not possible at distances greater than 15,000 due to the poor cables in the ground. This limits the jurisdictional boundaries that can be crossed by this technology. #5 - Also from section 4 "Last Mile" I don't believe CAMA trunks should be "....so called..." as you do in the second paragraph of the indented paragraph there #6 - From M8" ...from the selective router." Comment: Is this functionality (or device) used outside North America. If it is NA exclusive, the text should state that; possibly with a caveat with something to the effect of ".... and similar functionality utilized in other parts of the world." If the Selective Router is used throughout the world (or at least a lot of it), then the text could state that. Another comment: "Selective Router" is an undefined term at this point, and not know to too many people within the IETF (if even a handful). #7 - From M10 "Confidentiality" I think the word MUST is a problem. I believe this should be the goal, but not it if causes the call to fail, or be delayed. I believe this should be a SHOULD, and state that this is a goal, with some provision to determine that if a call is the threshold of stability due to this function, that it should be abandoned in place of receiving the call in the clear. #8 - Suggested text for consideration (likely in the Intro, as it has to do with everything further into this document): "Current North American Public Safety Answering Points (PSAPs) want 3 things during a traditional E911 call (in this order of importance): - The call completed - The callback number - The location of the caller For that call to occur over IP, 5 things are likely to be needed: - Proper call routing to the PSAP(based on caller location) - The call - Any priority flags - The location of the caller - A valid (should be verifiable) Contact Header (or mandatory Via header of the UAC and any/all Proxies involved in the call routing) for callback What's not so obvious is whether there needs to be further (any?) security involved that could fail the call. If security considerations are necessary, with the full realization that the emergency call could fail if they are not met, then the following is the minimum to be included in the list above: - Assurance that none of the signaling (headers) have been munged" This is from my unpublished framework ID on this subject, but it could be easily used in this doc. I would stress that at least the first 3 bullets are included here, as this is exactly what PSAPs want today. #9 - From section 5 "End-to-end emergency calls originate on an Internet device, traverse IP networks and terminate on an IP capable ECC (IECC)." Comment: this can be a moderately misleading statement. The most likely event or infrastructure will have the Emergency call hit the first Proxy and then travel straight to the local IECC (and not across the Internet - which most people define as traffic passing between two Tier 1 ISPs). If the Proxy is not local to the UA, then the issue of how this non-local proxy will know where the local PSAP is relative to this UA making the emergency call. #10 - From Section 5.2, 2nd sentence: "... ECCs only serve a small region ..." This isn't true in London that I know of. I don't know the exact nature of other major cities in Europe of Asia. Regardless, this statement made is not universally true, and has a major example where it isn't. Text couching this statement is recommended. #11 - From section 5.2, 2nd paragraph, 3rd sentence: "In caller-based resolution, the caller's UA consults a directory and determines the correct IECC based on its location." Comment: This is omitting the possibility of a Geopriv WG ID (you're aware of) and another ID you wrote in which the UA could have its location "feed" to in upon boot-up (via DHCP). Both IDs state that if the UA has its Geo-Loc present in the UA, some future functionality in SIP (not defined yet) could include the location information in a Header or MIME body, and not need this look-up (nor does it have to determine anything - as the location information is "just there" in the UA. #12 - also from section 5.2, 2nd paragraph, last sentence: "(It appears undesirable to have either the UA or every outbound proxy server contain a copy of the location-to-ECC mapping since this table changes frequently.)" Question: How often do any of these stated 5000 PSAPs move (as you elude to with this above comment)? #13 - Also from section 5.2, last paragraph "Depending on the location, any of several ten thousand destinations could be valid." comment: this seems to contradict the 5000 PSAPs within the US, unless you are referring to the total number of PSAP-like IECC and ECCs that exist throughout the world. If so, a brief mention of this would relieve confusion regarding this seemingly out of place number of destinations. Further, I believe it will be a burden on the Proxy to properly route the call regardless of how many destinations there can be. Having the location contained within the UA helps this. marrying some cross-functional code between SIP and either Geopriv or the available L2 (wireless) technology to determine the UA's location will greatly help this effort. I believe jurisdictions will demand this functionality - and it will not be easy. #14 - From I1: "The system MUST reach the correct IECC regardless of the location of the caller." I believe must be restated to: "The system MUST reach the correct IECC with respect to the location of the caller." #15 - From I8: Call setup latency Comment: This requirement is the first to elude to the concept of the Proxy having to know what to do with UAs and their coordinates (and the look-ups). This leads into a new requirement that I haven't seen yet from section 5: If the UA has its location, regardless of where the Proxy is, there is a need for the (or any) Proxy to know which PSAP to route the call to based on this location information. #16 - From I9: "A mandatory-to-implement protocol..." seems like a partial sentence #17 - From 5.3, 2nd paragraph, last sentence "Emergency numbers are generally not meant for anonymous tips. [TBD: Are there any exceptions?]" This is a viable and often used mechanism from pay phones within urban cities to quitely inform the police about something the call wants them to be aware of, yet have no record of who called (like calling in where a drug deal occurred or is about to occur). #18 - From section 5.4, first paragraph you earlier exploded the acronym ANI, but haven't for ALI here. #19 - observation at this point in the document I've made a few comments about Location of the caller, and this is the first real text that covers the subject. Therefore, I'd suggest that the Introduction briefly go through what section each general topic will be covered in (instead of having the reader read the whole ID before knowing a certain topic is indeed covered). #20 - A new Requirement that I haven't read here (and one that should be considered for section 5.2, else section 5.4): If the UA provides its location (coordinate or civil), or the first (or any) Proxy knows (or learns by some other means) the location of the UA making the emergency call, it MUST route the call to the appropriate ECC or IECC. This is hinted at, and talked around, but I think it should be stated for formally and robustly. ++++++++++++++++++++++++ this is from my first pass at the doc, I might have a few redundant comments or questions, or some out of place - this is likely cause by the lack of the intro explaining where each general topic will be covered (Comment # 19). If you've already published this ID, I'll reproduce this list of questions on the main SIPPING list for general discussion. >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 17:20:18 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 RAA16606 for ; Sat, 22 Feb 2003 17:20:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MMS1x09695 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 17:28:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMS1p09692 for ; Sat, 22 Feb 2003 17:28:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16603 for ; Sat, 22 Feb 2003 17:19:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMS0p09684 for ; Sat, 22 Feb 2003 17:28:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMRwp09670 for ; Sat, 22 Feb 2003 17:27:58 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16600 for ; Sat, 22 Feb 2003 17:19:43 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18mi3R-0004WI-00; Sat, 22 Feb 2003 14:23:33 -0800 To: Henning Schulzrinne , sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 In-Reply-To: Message from "James M. Polk" of "Sat, 22 Feb 2003 13:54:38 CST." <4.3.2.7.2.20030222120157.024467d0@localhost> Date: Sat, 22 Feb 2003 14:23:33 -0800 From: Allison Mankin Message-Id: 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: , Henning, Apologies for not paying enough attention to this list. I am somewhat concerned with the scope of your requirements. We had an AD/Chair discussion of restricting initial work to Last-Mile, with explanation of the benefit of an initial, fairly tractable and useful problem set. This is not following that restriction. Allison _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 17:37:18 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 RAA16727 for ; Sat, 22 Feb 2003 17:37:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MMj2V10783 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 17:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMj2p10780 for ; Sat, 22 Feb 2003 17:45:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16722 for ; Sat, 22 Feb 2003 17:36:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMj1p10772 for ; Sat, 22 Feb 2003 17:45:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMiOp10732 for ; Sat, 22 Feb 2003 17:44:24 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16713 for ; Sat, 22 Feb 2003 17:36:09 -0500 (EST) 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.3/8.12.3) with ESMTP id h1MMe0Qd016745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 17:40:01 -0500 (EST) Message-ID: <3E57FC55.9090007@cs.columbia.edu> Date: Sat, 22 Feb 2003 17:40:21 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Allison Mankin CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 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 Allison, if you're referring to our joint phone discussion (the only one I was in on), I took away from that conversation that requirements for both aspects were needed. Indeed, I believe that we're seriously short-changing needed developments if we can't get to work on the end-to-end requirements soon. Last-mile will not support VoIP terminals except if these are in local PBX-mode only (i.e., attached to a PSTN gateway in the same building or on the same campus). While public IP-accessible ECC may still be a few years away, private arrangements, either similar to onStar or corporate/campus security centers, seem likely sooner than that. For what it's worth, the last-mile requirements are essentially the same requirements as a PBX with ACD. Henning Allison Mankin wrote: > Henning, > > Apologies for not paying enough attention to this list. I am somewhat > concerned with the scope of your requirements. We had an AD/Chair discussion > of restricting initial work to Last-Mile, with explanation of the benefit > of an initial, fairly tractable and useful problem set. This is not following > that restriction. > > Allison _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 17:51:17 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 RAA16819 for ; Sat, 22 Feb 2003 17:51:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MMx1w11018 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 17:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMx1p11015 for ; Sat, 22 Feb 2003 17:59:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16816 for ; Sat, 22 Feb 2003 17:50:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMx0p11007 for ; Sat, 22 Feb 2003 17:59:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MMwbp10988 for ; Sat, 22 Feb 2003 17:58:37 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16813 for ; Sat, 22 Feb 2003 17:50:21 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18miX4-0006EF-00; Sat, 22 Feb 2003 14:54:10 -0800 To: Henning Schulzrinne cc: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 In-Reply-To: Message from Henning Schulzrinne of "Sat, 22 Feb 2003 17:40:21 EST." <3E57FC55.9090007@cs.columbia.edu> Date: Sat, 22 Feb 2003 14:54:10 -0800 From: Allison Mankin Message-Id: 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: , Henning, The problem with expressing all the requirements is that it will not guide the work and discussion on the shorter-term goals properly. Allison _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 17:57:17 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 RAA16862 for ; Sat, 22 Feb 2003 17:57:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MN52Z11210 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 18:05:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MN52p11207 for ; Sat, 22 Feb 2003 18:05:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16858 for ; Sat, 22 Feb 2003 17:56:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MN51p11199 for ; Sat, 22 Feb 2003 18:05:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MN4Kp11170 for ; Sat, 22 Feb 2003 18:04:20 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16855 for ; Sat, 22 Feb 2003 17:56:04 -0500 (EST) 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.3/8.12.3) with ESMTP id h1MMxtQd021788 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 17:59:56 -0500 (EST) Message-ID: <3E580101.8020207@cs.columbia.edu> Date: Sat, 22 Feb 2003 18:00:17 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Allison Mankin CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 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 The last-mile requirements are in a separate section, so I'm not sure I see the problem. (Besides, quite frankly, I'm not sure what needs to be done, SIP-wise, for the short-term issues. As I said, this is effectively an ACD with conference recording. It might be useful to say that, but I think we might make some progress if we can identify, at least within the design team, the likely areas needing work for the last-mile case. There are, to be sure, other useful ways to apply IP in the last-mile case, but those are effectively geopriv territory, namely the authorized retrieval of location information given an E.164 identifier.) Allison Mankin wrote: > Henning, > > The problem with expressing all the requirements is that it > will not guide the work and discussion on the shorter-term goals > properly. > > Allison _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 18:20:18 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 SAA17209 for ; Sat, 22 Feb 2003 18:20:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MNS4j12801 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 18:28:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNS3p12798 for ; Sat, 22 Feb 2003 18:28:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17201 for ; Sat, 22 Feb 2003 18:19:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNS2p12782 for ; Sat, 22 Feb 2003 18:28:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNQ5p12621 for ; Sat, 22 Feb 2003 18:26:05 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17173 for ; Sat, 22 Feb 2003 18:17:49 -0500 (EST) 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.3/8.12.3) with ESMTP id h1MNLYxw028130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 18:21:35 -0500 (EST) Message-ID: <3E580615.8090608@cs.columbia.edu> Date: Sat, 22 Feb 2003 18:21:57 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org References: <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> In-Reply-To: <4.3.2.7.2.20030222120157.024467d0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Emergency-req: remarks 1-4 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 > Because I've had much writing of my own this past few weeks, and with > the deadline approaching for -00 IDs, I apologize for this coming so late. Thanks for your extensive comments. Remarks inline where needed. I'll split my response to keep things manageable. > #3 - "Emergency call center (ECC): An emergency call center (ECC) > receives emergency calls within a specific geographic area..." > > Comment: London has what you refer to as ECCs, but the have all calls > from the surrounding regional area come into a single center, the Call > taker(s) determines where the call is coming from, then the emergency > personnel are dispatched to the appropriate location from that > centralized ECC. In other words, local emergency personnel are not > called, they are dispatched by the ECC in London. > > This might be a subtle difference to your intent, but it is fairly > different than the US model where you call (or are patched through to) > the local ECC. Hmm, isn't that the same as having a large regional PSAP in the US? I think they are called consolidated PSAP. Thus, I'm not sure how my definition contradicts the London example - the London ECC "receives emergency calls within a specific geographic area and dispatches emergency services, such as fire, police and rescue services." > > #4 - From section 4 "Last Mile" you have omitted Cable access. I mention > this because existing HFC Broadband connectivity can be as much as 100 > miles away from the MSO Headend facility. This could easily have an > affect on which ECC (PSAP is appropriate to contact). This is in > contrast to DSL which is typically limited to 22,000 ft from the CO, > with most not possible at distances greater than 15,000 due to the poor > cables in the ground. This limits the jurisdictional boundaries that can > be crossed by this technology. Actually, last-mile is not visible to the "subscriber", so DSL or whatever are simply the way that the ECC connects to the PSTN selective router. (I suspect US PSAPs would not choose a cable modem as their access technology, but that's a discussion we don't need to have here.) Maybe your remark hints at a broader lack of common understanding what 'last mile' means. I'm referring to the model described in the NENA TID that I sent around yesterday, where IP only replaces the analog or digital trunk from the last switch to the PSAP. In that model, there is no way that a subscriber can directly send a SIP request to the PSAP. You obviously raise a good point that illustrates that even in a near-term deployment of VoIP over a current cable plant causes difficulties for the last-mile model. (In NJ, the bastion of home rule, a PSAP might cover only one square mile, so we get DSL service out of a neighboring community.) to be continued _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 18:30:17 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 SAA17322 for ; Sat, 22 Feb 2003 18:30:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MNc2L14184 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 18:38:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNc2p14181 for ; Sat, 22 Feb 2003 18:38:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17319 for ; Sat, 22 Feb 2003 18:29:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNc1p14173 for ; Sat, 22 Feb 2003 18:38:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNbOp14045 for ; Sat, 22 Feb 2003 18:37:24 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17313 for ; Sat, 22 Feb 2003 18:29:06 -0500 (EST) 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.3/8.12.3) with ESMTP id h1MNWpQd001691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 18:32:52 -0500 (EST) Message-ID: <3E5808BA.7010502@cs.columbia.edu> Date: Sat, 22 Feb 2003 18:33:14 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 References: <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> In-Reply-To: <4.3.2.7.2.20030222120157.024467d0@localhost> 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 > #6 - From M8" ...from the selective router." > > Comment: Is this functionality (or device) used outside North America. > If it is NA exclusive, the text should state that; possibly with a > caveat with something to the effect of ".... and similar functionality > utilized in other parts of the world." I don't know whether this is a NA term. I qualified it. > > If the Selective Router is used throughout the world (or at least a lot > of it), then the text could state that. Given the lack of documentation on emergency call network architectures, I suspect we'll be hard-pressed to find out for sure. I'm hoping that somebody in the larger SIPPING community can suggest appropriate I18N terminology. > > Another comment: "Selective Router" is an undefined term at this point, > and not know to too many people within the IETF (if even a handful). Defined, by cribbing from the NENA master glossary: (E9-1-1) Control Office The Central Office that provides the tandem switching of 9-1-1calls. It controls delivery of the voice call with ANI to the PSAP and provides Selective Routing, Speed Calling, Selective Transfer, Fixed Transfer, and certain maintenance functions for each PSAP. Also known as 9-1-1 Selective Routing Tandem or Selective Router. > > #7 - From M10 "Confidentiality" I think the word MUST is a problem. I > believe this should be the goal, but not it if causes the call to fail, > or be delayed. I believe this should be a SHOULD, and state that this is > a goal, with some provision to determine that if a call is the threshold > of stability due to this function, that it should be abandoned in place > of receiving the call in the clear. Since the IETF can only specify "must implement", rather than "must use", I should have stated this as an implementation constraint. Reworded as "Implementations MUST support confidentiality". TBCont'd. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 19:57: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 TAA18468 for ; Sat, 22 Feb 2003 19:57:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N152819341 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 20:05:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N152p19338 for ; Sat, 22 Feb 2003 20:05:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18463 for ; Sat, 22 Feb 2003 19:56:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N151p19326 for ; Sat, 22 Feb 2003 20:05:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N14Ap19303 for ; Sat, 22 Feb 2003 20:04:10 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18447 for ; Sat, 22 Feb 2003 19:55:51 -0500 (EST) 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.3/8.12.3) with ESMTP id h1N0xbxw026360 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 19:59:38 -0500 (EST) Message-ID: <3E581D14.5070203@cs.columbia.edu> Date: Sat, 22 Feb 2003 20:00:04 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org References: <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> In-Reply-To: <4.3.2.7.2.20030222120157.024467d0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Emergency-req: 8-12 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 > - Proper call routing to the PSAP(based on caller location) > - The call > - Any priority flags Since the call is already identified as an emergency call, I don't see the need for any additional flags. (Adding such a flag mechanism would introduce additional attack vectors, for example.) > - The location of the caller > - A valid (should be verifiable) Contact Header (or mandatory Via > header of the UAC and any/all Proxies involved in the call routing) for > callback These items are enumerated in the beginning of the end-to-end section. They do not apply to the last-mile architecture. > > What's not so obvious is whether there needs to be further (any?) > security involved that could fail the call. If security considerations > are necessary, with the full realization that the emergency call could > fail if they are not met, then the following is the minimum to be > included in the list above: > > - Assurance that none of the signaling (headers) have been munged" > > This is from my unpublished framework ID on this subject, but it could > be easily used in this doc. I would stress that at least the first 3 > bullets are included here, as this is exactly what PSAPs want today. Noted. Added 'integrity' under call setup. > > #9 - From section 5 > > "End-to-end emergency calls originate on an Internet device, traverse IP > networks and terminate on an IP capable ECC (IECC)." > > Comment: this can be a moderately misleading statement. The most likely > event or infrastructure will have the Emergency call hit the first Proxy > and then travel straight to the local IECC (and not across the Internet > - which most people define as traffic passing between two Tier 1 ISPs). Where is that Internet definition from? I would define anything that's on an IP network connected to the global Internet as an Internet device. > If the Proxy is not local to the UA, then the issue of how this > non-local proxy will know where the local PSAP is relative to this UA > making the emergency call. Indeed. > > #10 - From Section 5.2, 2nd sentence: > > "... ECCs only serve a small region ..." This isn't true in London that > I know of. I don't know the exact nature of other major cities in Europe > of Asia. Regardless, this statement made is not universally true, and > has a major example where it isn't. Text couching this statement is > recommended. removed 'small' > > #11 - From section 5.2, 2nd paragraph, 3rd sentence: > > "In caller-based resolution, the caller's UA consults a directory and > determines the correct IECC based on its location." > > Comment: This is omitting the possibility of a Geopriv WG ID (you're > aware of) and another ID you wrote in which the UA could have its > location "feed" to in upon boot-up (via DHCP). Both IDs state that if > the UA has its Geo-Loc present in the UA, some future functionality in > SIP (not defined yet) could include the location information in a Header > or MIME body, and not need this look-up (nor does it have to determine > anything - as the location information is "just there" in the UA. Note that the text speaks of finding the correct IECC, not of determining the location. The idea is that if a UA knows its location (via whatever means, including the ones you mention), it can directly query a location-to-IECC mapping service and then contact the IECC. This model has trust advantages since the UA can choose whatever mapping service it considers trustworthy ahead of time, get back a reply it can trust (since it presumably has made sure it's talking to the right directory service) and can then easily use standard server authentication mechanism to detect that it is indeed talking to the desired IECC. This makes the trust problem much more tractable. In effect, the caller gets to choose its "PSAP certifying authority" without every PSAP having to be accredited by one certifying authority. I'm hoping that this type of mechanism is both implementable and can allay the fears of Jon of talking to the corner PSAP run by the Sopranos. > > #12 - also from section 5.2, 2nd paragraph, last sentence: > > "(It appears undesirable to have either the UA or every outbound proxy > server contain a copy of > the location-to-ECC mapping since this table changes frequently.)" > > Question: How often do any of these stated 5000 PSAPs move (as you elude > to with this above comment)? I hope you don't expect me to know that :-) I suspect that they don't move often, but consolidations, in particular, seem not uncommon. Also, you'd not only need all 5,000 US PSAPs, but every PSAP-equivalent in the world. Since you probably don't want to download the whole table over a wireless interface each time two PSAPs merge, you then need a synchronization mechanism. I suspect this can all be done (after all, this isn't all that different than downloading a version of Zagat's on your PDA and there are lots more restaurants in NYC than they are PSAPs, I suspect...), so I'll mention it as a possibility. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sat Feb 22 20:32: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 UAA18970 for ; Sat, 22 Feb 2003 20:32:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N1e3L21923 for sipping-emergency-archive@odin.ietf.org; Sat, 22 Feb 2003 20:40:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N1e3p21912 for ; Sat, 22 Feb 2003 20:40:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18961 for ; Sat, 22 Feb 2003 20:31:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N1e1p21892 for ; Sat, 22 Feb 2003 20:40:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N1dHp21846 for ; Sat, 22 Feb 2003 20:39:17 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18942 for ; Sat, 22 Feb 2003 20:30:57 -0500 (EST) 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.3/8.12.3) with ESMTP id h1N1Yhxw004524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 20:34:45 -0500 (EST) Message-ID: <3E582550.60506@cs.columbia.edu> Date: Sat, 22 Feb 2003 20:35:12 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org References: <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> In-Reply-To: <4.3.2.7.2.20030222120157.024467d0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Emergency-req: 13- 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 > Further, I believe it will be a burden on the Proxy to properly route > the call regardless of how many destinations there can be. Having the > location contained within the UA helps this. marrying some > cross-functional code between SIP and either Geopriv or the available L2 > (wireless) technology to determine the UA's location will greatly help > this effort. > > I believe jurisdictions will demand this functionality - and it will not > be easy. I don't think this is a big issue. We have running code for that, at least for the US (using a company that has a proprietary interface database that offers a geo-to-jurisdiction mapping). Indeed, existing telematics services such as OnStar use such mapping services, so this seems like a manageable problem on the user end. It's much harder on the backend if you want to support several competing providers of such translation services - you essentially get back to the registrar-registry problem for DNS. I suspect that this is far beyond where we want to go in this effort. > #15 - From I8: Call setup latency > > Comment: This requirement is the first to elude to the concept of the > Proxy having to know what to do with UAs and their coordinates (and the > look-ups). > > This leads into a new requirement that I haven't seen yet from section > 5: If the UA has its location, regardless of where the Proxy is, there > is a need for the (or any) Proxy to know which PSAP to route the call to > based on this location information. Yes, I considered that implied in the mediated model, but I amplified this. > > #17 - From 5.3, 2nd paragraph, last sentence > > "Emergency numbers are generally not meant for anonymous tips. [TBD: Are > there any exceptions?]" > > This is a viable and often used mechanism from pay phones within urban > cities to quitely inform the police about something the call wants them > to be aware of, yet have no record of who called (like calling in where > a drug deal occurred or is about to occur). If we do get SIP payphones, they'd convey the same information as today: the identity of the payphone and its location (since there's no need for personal authentication), so I guess this doesn't seem to raise any new issues. My TBD referred to the question as to whether there are jurisdictions that allow terminal selective anonymity, but I guess this question is unanswerable. > #19 - observation at this point in the document > > I've made a few comments about Location of the caller, and this is the > first real text that covers the subject. Therefore, I'd suggest that the > Introduction briefly go through what section each general topic will be > covered in (instead of having the reader read the whole ID before > knowing a certain topic is indeed covered). I've added a bit of verbiage up front, but the beginning of the End-to-End section does point to the 'who' and 'where' sections. > > #20 - A new Requirement that I haven't read here (and one that should be > considered for section 5.2, else section 5.4): If the UA provides its > location (coordinate or civil), or the first (or any) Proxy knows (or > learns by some other means) the location of the UA making the emergency > call, it MUST route the call to the appropriate ECC or IECC. Noted. > If you've already published this ID, I'll reproduce this list of > questions on the main SIPPING list for general discussion. The I-D editor picked it up at 12:55 on Friday, so I'll create a -01 version. It's at http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-01.pdf Thanks again for your comments. Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Feb 23 12:51:54 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 MAA10406 for ; Sun, 23 Feb 2003 12:51:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1NI02M15560 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 13:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NI02p15557 for ; Sun, 23 Feb 2003 13:00:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10401 for ; Sun, 23 Feb 2003 12:51:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NI01p15549 for ; Sun, 23 Feb 2003 13:00:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NHxBp15513 for ; Sun, 23 Feb 2003 12:59:11 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10396 for ; Sun, 23 Feb 2003 12:50:31 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 23 Feb 2003 09:54:29 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA05536; Sun, 23 Feb 2003 09:54:23 -0800 (PST) Message-Id: <4.3.2.7.2.20030223114348.022b5640@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Feb 2003 11:54:18 -0600 To: Henning Schulzrinne From: "James M. Polk" Cc: sipping-emergency@ietf.org In-Reply-To: <3E580615.8090608@cs.columbia.edu> References: <4.3.2.7.2.20030222120157.024467d0@localhost> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping-emergency] Re: Emergency-req: remarks 1-4 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: , At 06:21 PM 2/22/2003 -0500, Henning Schulzrinne wrote: >>Because I've had much writing of my own this past few weeks, and with the >>deadline approaching for -00 IDs, I apologize for this coming so late. > >Thanks for your extensive comments. Remarks inline where needed. I'll >split my response to keep things manageable. > >>#3 - "Emergency call center (ECC): An emergency call center (ECC) >>receives emergency calls within a specific geographic area..." >>Comment: London has what you refer to as ECCs, but the have all calls >>from the surrounding regional area come into a single center, the Call >>taker(s) determines where the call is coming from, then the emergency >>personnel are dispatched to the appropriate location from that >>centralized ECC. In other words, local emergency personnel are not >>called, they are dispatched by the ECC in London. >>This might be a subtle difference to your intent, but it is fairly >>different than the US model where you call (or are patched through to) >>the local ECC. > >Hmm, isn't that the same as having a large regional PSAP in the US? I >think they are called consolidated PSAP. > >Thus, I'm not sure how my definition contradicts the London example - the >London ECC "receives emergency calls within a specific geographic area and >dispatches emergency services, such as fire, police and rescue services." Many are not educated on the details or implementations of 911 and e911. Most in fact, believe this is a local issue only (meaning limited to a city, or region of a large city). I wasn't really commenting on contradictions (sorry if it came across that way) as educating how things are now. IP will only expand the territories, >>#4 - From section 4 "Last Mile" you have omitted Cable access. I mention >>this because existing HFC Broadband connectivity can be as much as 100 >>miles away from the MSO Headend facility. This could easily have an >>affect on which ECC (PSAP is appropriate to contact). This is in contrast >>to DSL which is typically limited to 22,000 ft from the CO, with most not >>possible at distances greater than 15,000 due to the poor cables in the >>ground. This limits the jurisdictional boundaries that can be crossed by >>this technology. > >Actually, last-mile is not visible to the "subscriber", so DSL or whatever >are simply the way that the ECC connects to the PSTN selective router. (I >suspect US PSAPs would not choose a cable modem as their access >technology, but that's a discussion we don't need to have here.) Maybe >your remark hints at a broader lack of common understanding what 'last >mile' means. I'm referring to the model described in the NENA TID that I >sent around yesterday, where IP only replaces the analog or digital trunk >from the last switch to the PSAP. In that model, there is no way that a >subscriber can directly send a SIP request to the PSAP. There are several installations that use HFC as primary line. They are installed in most of the largest cities in the US. The products are from Arris (co-owned by Nortel at one time, I use to work on the Nortel team of that partnership several years ago). Dallas/Fort Worth (where I am) has had the opportunity to convert over to HFC and off wire-pairs for more than a year for my primary phone service. The provider is a little company called AT&T. The business goal of AT&T is to penetrate all the 32 NFL cities (their term). At the MSO Headend, there is connectivity to a Class 5 switch (either co-located, or feed to it). Thus, this MSO might be quite a ways outside of the PSAP jurisdiction (likely not 100 miles in AT&T's case in the near term - but we are talking about years from now also) >You obviously raise a good point that illustrates that even in a near-term >deployment of VoIP over a current cable plant causes difficulties for the >last-mile model. (In NJ, the bastion of home rule, a PSAP might cover only >one square mile, so we get DSL service out of a neighboring community.) > >to be continued > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Feb 23 13:27:54 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 NAA10874 for ; Sun, 23 Feb 2003 13:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1NIa3a17109 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 13:36:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NIa2p17106 for ; Sun, 23 Feb 2003 13:36:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10871 for ; Sun, 23 Feb 2003 13:27:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NIa2p17098 for ; Sun, 23 Feb 2003 13:36:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NIZep17081 for ; Sun, 23 Feb 2003 13:35:40 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10867 for ; Sun, 23 Feb 2003 13:27:00 -0500 (EST) Received: from cs.columbia.edu (128.indianapolis-01rh16rt.in.dial-access.att.net[12.84.225.128]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003022318305211300mpk16e>; Sun, 23 Feb 2003 18:30:52 +0000 Message-ID: <3E5912B3.40301@cs.columbia.edu> Date: Sun, 23 Feb 2003 13:28:03 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org References: <4.3.2.7.2.20030222120157.024467d0@localhost> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> <4.3.2.7.2.20030223114348.022b5640@localhost> In-Reply-To: <4.3.2.7.2.20030223114348.022b5640@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Re: Emergency-req: remarks 1-4 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 > There are several installations that use HFC as primary line. They are We're still not connecting. HFC might well be used for regular telecommunications subscribers, but the 'last-mile' model is constrained to the case that the PSAP uses IP access, while the emergency callers only use regular PSTN, however they get there. > installed in most of the largest cities in the US. The products are from > Arris (co-owned by Nortel at one time, I use to work on the Nortel team > of that partnership several years ago). Dallas/Fort Worth (where I am) > has had the opportunity to convert over to HFC and off wire-pairs for > more than a year for my primary phone service. The provider is a little > company called AT&T. The business goal of AT&T is to penetrate all the > 32 NFL cities (their term). > > At the MSO Headend, there is connectivity to a Class 5 switch (either > co-located, or feed to it). Thus, this MSO might be quite a ways outside > of the PSAP jurisdiction (likely not 100 miles in AT&T's case in the > near term - but we are talking about years from now also) That's all true and important for the end-to-end model, but completely irrelevant to the last-mile model. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Feb 23 21:43: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 VAA18816 for ; Sun, 23 Feb 2003 21:43:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O2q3509499 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 21:52:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2q3p09496 for ; Sun, 23 Feb 2003 21:52:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18806 for ; Sun, 23 Feb 2003 21:43:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2q1p09488 for ; Sun, 23 Feb 2003 21:52:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2pjp09464 for ; Sun, 23 Feb 2003 21:51:45 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18797 for ; Sun, 23 Feb 2003 21:42:54 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 23 Feb 2003 18:47:09 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA04683; Sun, 23 Feb 2003 18:46:45 -0800 (PST) Message-Id: <4.3.2.7.2.20030223115500.022b4da8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Feb 2003 20:39:48 -0600 To: Henning Schulzrinne From: "James M. Polk" Cc: sipping-emergency@ietf.org In-Reply-To: <3E581D14.5070203@cs.columbia.edu> References: <4.3.2.7.2.20030222120157.024467d0@localhost> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1O2pkp09465 Subject: [Sipping-emergency] Re: Emergency-req: 8-12 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 At 08:00 PM 2/22/2003 -0500, Henning Schulzrinne wrote: >> - Proper call routing to the PSAP(based on caller location) >> - The call >> - Any priority flags > >Since the call is already identified as an emergency call, I don't see the >need for any additional flags. (Adding such a flag mechanism would >introduce additional attack vectors, for example.) I'm not proposing them, but they still might become a requirement from the jurisdiction. My list above was a possible projection of what an IP list could look like. I believe the priority flag was and is mentioned not as expected, just possible (that's why I use the word "any" - if there aren't any, you can't include them) >> - The location of the caller >> - A valid (should be verifiable) Contact Header (or mandatory Via >> header of the UAC and any/all Proxies involved in the call routing) for >> callback > >These items are enumerated in the beginning of the end-to-end section. >They do not apply to the last-mile architecture. Fair. I believe you can use them how you like. If you believe this list (or the section half of the whole list) is applicable to only the e2e section, then by all means include what you feel is appropriate. I was only offering a list, not 'the' list. >>What's not so obvious is whether there needs to be further (any?) >>security involved that could fail the call. If security considerations >>are necessary, with the full realization that the emergency call could >>fail if they are not met, then the following is the minimum to be >>included in the list above: >> - Assurance that none of the signaling (headers) have been munged" >>This is from my unpublished framework ID on this subject, but it could be >>easily used in this doc. I would stress that at least the first 3 bullets >>are included here, as this is exactly what PSAPs want today. > >Noted. Added 'integrity' under call setup. > >>#9 - From section 5 >>"End-to-end emergency calls originate on an Internet device, traverse IP >>networks and terminate on an IP capable ECC (IECC)." >>Comment: this can be a moderately misleading statement. The most likely >>event or infrastructure will have the Emergency call hit the first Proxy >>and then travel straight to the local IECC (and not across the Internet - >>which most people define as traffic passing between two Tier 1 ISPs). > >Where is that Internet definition from? Patrik Fältström is one of my coworkers who is part of this discussion within Cisco frequently. This is his tenuous definition - though he speaks it not in the absolute sense, but hesitantly as it hasn't been agree upon anywhere in the community. My use it as a guide, though opinions vary (obviously). >I would define anything that's on an IP network connected to the global >Internet as an Internet device. > >>If the Proxy is not local to the UA, then the issue of how this non-local >>proxy will know where the local PSAP is relative to this UA making the >>emergency call. > >Indeed. > >>#10 - From Section 5.2, 2nd sentence: >>"... ECCs only serve a small region ..." This isn't true in London that I >>know of. I don't know the exact nature of other major cities in Europe of >>Asia. Regardless, this statement made is not universally true, and has a >>major example where it isn't. Text couching this statement is recommended. > >removed 'small' > >>#11 - From section 5.2, 2nd paragraph, 3rd sentence: >>"In caller-based resolution, the caller's UA consults a directory and >>determines the correct IECC based on its location." >>Comment: This is omitting the possibility of a Geopriv WG ID (you're >>aware of) and another ID you wrote in which the UA could have its >>location "feed" to in upon boot-up (via DHCP). Both IDs state that if the >>UA has its Geo-Loc present in the UA, some future functionality in SIP >>(not defined yet) could include the location information in a Header or >>MIME body, and not need this look-up (nor does it have to determine >>anything - as the location information is "just there" in the UA. > >Note that the text speaks of finding the correct IECC, not of determining >the location. The idea is that if a UA knows its location (via whatever >means, including the ones you mention), it can directly query a >location-to-IECC mapping service and then contact the IECC. But.... doesn't the UA *not* know the IP address of the PSAP? If it doesn't in the INVITE, then the Proxy has to direct the INVITE (with the sos@) towards the proper PSAP. This will require the Proxy to know which PSAP to do to (unless there is only one in the area - in the case of a large regional service). Maybe I'm missing something...? >This model has trust advantages since the UA can choose whatever mapping >service it considers trustworthy ahead of time, get back a reply it can >trust (since it presumably has made sure it's talking to the right >directory service) and can then easily use standard server authentication >mechanism to detect that it is indeed talking to the desired IECC. This >makes the trust problem much more tractable. In effect, the caller gets to >choose its "PSAP certifying authority" without every PSAP having to be >accredited by one certifying authority. That will never happen >I'm hoping that this type of mechanism is both implementable and can allay >the fears of Jon of talking to the corner PSAP run by the Sopranos. > > >>#12 - also from section 5.2, 2nd paragraph, last sentence: >>"(It appears undesirable to have either the UA or every outbound proxy >>server contain a copy of >>the location-to-ECC mapping since this table changes frequently.)" >>Question: How often do any of these stated 5000 PSAPs move (as you elude >>to with this above comment)? > >I hope you don't expect me to know that :-) I suspect that they don't move >often, but consolidations, in particular, seem not uncommon. Also, you'd >not only need all 5,000 US PSAPs, but every PSAP-equivalent in the world. >Since you probably don't want to download the whole table over a wireless >interface each time two PSAPs merge, you then need a synchronization >mechanism. how hard would this be to include in something like a DHCP configuration download? Or have the UA periodically do something like an OPTIONs query to the Proxy it knows, and exchange the necessary information to learn the available choice in the background. >I suspect this can all be done (after all, this isn't all that different >than downloading a version of Zagat's on your PDA and there are lots more >restaurants in NYC than they are PSAPs, I suspect...), so I'll mention it >as a possibility. > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Feb 23 21:53:10 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 VAA18981 for ; Sun, 23 Feb 2003 21:53:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O31Ts09728 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 22:01:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O31Tp09725 for ; Sun, 23 Feb 2003 22:01:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18952 for ; Sun, 23 Feb 2003 21:52:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O31Sp09717 for ; Sun, 23 Feb 2003 22:01:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2wcp09583 for ; Sun, 23 Feb 2003 21:58:38 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18903 for ; Sun, 23 Feb 2003 21:49:47 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 23 Feb 2003 18:54:02 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA10976; Sun, 23 Feb 2003 18:53:37 -0800 (PST) Message-Id: <4.3.2.7.2.20030223205206.0215a410@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Feb 2003 20:53:44 -0600 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sipping-emergency] Re: Emergency-req: remarks 1-4 Cc: sipping-emergency@ietf.org In-Reply-To: <3E5912B3.40301@cs.columbia.edu> References: <4.3.2.7.2.20030223114348.022b5640@localhost> <4.3.2.7.2.20030222120157.024467d0@localhost> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> <4.3.2.7.2.20030223114348.022b5640@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 01:28 PM 2/23/2003 -0500, Henning Schulzrinne wrote: >>There are several installations that use HFC as primary line. They are > >We're still not connecting. HFC might well be used for regular >telecommunications subscribers, but the 'last-mile' model is constrained >to the case that the PSAP uses IP access, while the emergency callers only >use regular PSTN, however they get there. now I understand your direction.... >>installed in most of the largest cities in the US. The products are from >>Arris (co-owned by Nortel at one time, I use to work on the Nortel team >>of that partnership several years ago). Dallas/Fort Worth (where I am) >>has had the opportunity to convert over to HFC and off wire-pairs for >>more than a year for my primary phone service. The provider is a little >>company called AT&T. The business goal of AT&T is to penetrate all the 32 >>NFL cities (their term). >>At the MSO Headend, there is connectivity to a Class 5 switch (either >>co-located, or feed to it). Thus, this MSO might be quite a ways outside >>of the PSAP jurisdiction (likely not 100 miles in AT&T's case in the near >>term - but we are talking about years from now also) > >That's all true and important for the end-to-end model, but completely >irrelevant to the last-mile model. noted (knowing now the direction you are referring to). BTW - I'm fine with all your other responses to the listed comments and questions. >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Feb 23 23:02:41 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 XAA20286 for ; Sun, 23 Feb 2003 23:02:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O4B3q13611 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 23:11:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4B2p13608 for ; Sun, 23 Feb 2003 23:11:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20281 for ; Sun, 23 Feb 2003 23:02:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4B1p13594 for ; Sun, 23 Feb 2003 23:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4Arp13576 for ; Sun, 23 Feb 2003 23:10:53 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20275 for ; Sun, 23 Feb 2003 23:02:00 -0500 (EST) Received: from cs.columbia.edu (5.indianapolis-19rh15rt.in.dial-access.att.net[12.85.4.5]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003022404055311100ee5v4e>; Mon, 24 Feb 2003 04:05:54 +0000 Message-ID: <3E599978.8070906@cs.columbia.edu> Date: Sun, 23 Feb 2003 23:03:04 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping-emergency@ietf.org References: <4.3.2.7.2.20030222120157.024467d0@localhost> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030217161831.047e6110@localhost> <3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se> <4.3.2.7.2.20030222120157.024467d0@localhost> <4.3.2.7.2.20030223115500.022b4da8@localhost> In-Reply-To: <4.3.2.7.2.20030223115500.022b4da8@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sipping-emergency] Re: Emergency-req: 8-12 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 > > Patrik Fältström is one of my coworkers who is part of this discussion > within Cisco frequently. This is his tenuous definition - though he > speaks it not in the absolute sense, but hesitantly as it hasn't been > agree upon anywhere in the community. My use it as a guide, though > opinions vary (obviously). Pardon my timidity, but I'd rather not use this document to attempt a definition of Internet beyond the generally understood "a network of networks"... If Patrik wants to write a separate draft to clarify the internet/Internet/intranet/whatever distinction for current needs, it would be appropriate to cite it. >> Note that the text speaks of finding the correct IECC, not of >> determining the location. The idea is that if a UA knows its location >> (via whatever means, including the ones you mention), it can directly >> query a location-to-IECC mapping service and then contact the IECC. > > > But.... doesn't the UA *not* know the IP address of the PSAP? If it > doesn't in the INVITE, then the Proxy has to direct the INVITE (with the > sos@) towards the proper PSAP. This will require the Proxy to know which > PSAP to do to (unless there is only one in the area - in the case of a > large regional service). Maybe I'm missing something...? Assumptions: (1) UA knows its own location, e.g., long/lat. (2) UA knows at least one translation service that converts long/lat to ECC identity. How the UA knows this service is a matter of configuration, but it might be reasonable to assume that these lookup services change rarely. (Even if one were to go out of business, since the query interface is standardized, it would be trivial for the survivor to buy the address at the Chapter 7 sale...) These assumptions are not unreasonable since there are commercial services that offer this type of service. They are currently not designed to be used by millions of users, but this seems like a problem that good system engineering could solve. The problem is much more tractable than even the most modest-sized search engine, say, both in terms of query rate (a few queries/second), stability of the data and number of entries (thousands). Process: UA contacts this abstract service and gets back the SIP URI of the geographically appropriate ECC. Is this clearer? > >> This model has trust advantages since the UA can choose whatever >> mapping service it considers trustworthy ahead of time, get back a >> reply it can trust (since it presumably has made sure it's talking to >> the right directory service) and can then easily use standard server >> authentication mechanism to detect that it is indeed talking to the >> desired IECC. This makes the trust problem much more tractable. In >> effect, the caller gets to choose its "PSAP certifying authority" >> without every PSAP having to be accredited by one certifying authority. > > > That will never happen I'm trying to avoid the discussion of this since we will likely not get anywhere speculating. I'm trying to point out ways that we can avoid needing central authorities, while not preventing their emergence. In my opinion, we should provide the best (most reliable, secure, scalable, ...) tools possible and then help the operational community do the right thing. > how hard would this be to include in something like a DHCP configuration > download? Or have the UA periodically do something like an OPTIONs query > to the Proxy it knows, and exchange the necessary information to learn > the available choice in the background. The data volume remains the same, so I'm not sure how "background" helps. In any event, the draft now mentions synchronization-of-local-data as one possibility. Since this is a requirements document, I'm trying to exhaustively list all possible options, not pick favorites. Abstractly, I don't see any other possibilities beyond "UA knows itself" (local data), "UA asks somebody" (UA queries network directory) or "UA asks somebody that asks somebody" (UA sends request to proxy that queries directory or has local knowledge; this can recurse, obviously). Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Feb 23 23:49:41 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 XAA21149 for ; Sun, 23 Feb 2003 23:49:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O4w1816031 for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 23:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4w1p16028 for ; Sun, 23 Feb 2003 23:58:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21142 for ; Sun, 23 Feb 2003 23:49:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4w0p16020 for ; Sun, 23 Feb 2003 23:58:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O4vbp16002 for ; Sun, 23 Feb 2003 23:57:37 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21135 for ; Sun, 23 Feb 2003 23:48:45 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18nAbR-000L7a-00; Sun, 23 Feb 2003 20:52:33 -0800 To: Henning Schulzrinne cc: "James M. Polk" , sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: Emergency-req: 8-12 In-Reply-To: Message from Henning Schulzrinne of "Sun, 23 Feb 2003 23:03:04 EST." <3E599978.8070906@cs.columbia.edu> Date: Sun, 23 Feb 2003 20:52:33 -0800 From: Allison Mankin Message-Id: 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: , Henning, Since this is a requirements document, I'm trying to exhaustively list all possible options, not pick favorites. A requirements document should be more generic. There's almost a sense that you and James are writing an quasi-RFP for US and European centers. Your words give the sense of avoiding "the" solution by giving ranges of them. The goal should be to give the problem with some clarity to SIPPING so that the group can determine 1. if it's a necessary one for the WG. 2. if it's one that can be done with existing SIP capabilities and whether they have issues such as security strengths that might need modifications (a number of times SIPPING has found that the feature was fine, but it needed some normative modification). 3. if not, what requirements there are for new SIP capabilities. I see far less generic material in the current draft. I too am working to deadlines this weekend, so this comment must be brief, but I have a real concern for what we will see from this draft. Allison _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Feb 24 09:15: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 JAA15101 for ; Mon, 24 Feb 2003 09:15:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OEO2927979 for sipping-emergency-archive@odin.ietf.org; Mon, 24 Feb 2003 09:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OEO2p27976 for ; Mon, 24 Feb 2003 09:24:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15091 for ; Mon, 24 Feb 2003 09:14:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OEO1p27967 for ; Mon, 24 Feb 2003 09:24:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OENvp27949 for ; Mon, 24 Feb 2003 09:23:57 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15088 for ; Mon, 24 Feb 2003 09:14:53 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for sipping-emergency@ietf.org; Mon, 24 Feb 2003 09:17:38 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003022409183001737 ; Mon, 24 Feb 2003 09:18:30 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1XSYAW69>; Mon, 24 Feb 2003 09:20:32 -0500 Message-Id: From: "King, Kimberly S." To: "'Allison Mankin'" , Henning Schulzrinne Cc: "James M. Polk" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: Emergency-req: 8-12 Date: Mon, 24 Feb 2003 09:18:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , All, I am sorry about being so clueless in this area but Allison's words ring true. Maybe I can use my lack of knowledge to help. Ultimately, what is it that is required that the current SIP lacks (SIPPING should answer later)? To get there, name what is required (this work). I'm getting lost in what is the context. It looks to me like there are three cases. a) someone uses IP-based phone or IM to call for help (sos/911) and this hits a gateway (either regular IP-PSTN gateway or IP to text messaging (e.g., SMS). What is required in this case? b) someone uses IP-based phone or IM to call for help (sos/911) and this goes end-to-end IP. (It appears to me that it might not be detectable to the caller whether a gateway will intervene so perhaps what is required should be the same as case a).) c) the receiving center is IP-based but calls come in from the PSTN. Have I got this correct? Now, if so, isn't this simple? What is needed? location information? time-stamps? some assuredness that the message is authentic? ? When I try to read the draft, I don't get it in clear language what is needed but my feelings are that it shouldn't be that complicated. What am I missing? Kimberly >-----Original Message----- >From: Allison Mankin [mailto:mankin@psg.com] >Sent: Sunday, February 23, 2003 11:53 PM >To: Henning Schulzrinne >Cc: James M. Polk; sipping-emergency@ietf.org >Subject: Re: [Sipping-emergency] Re: Emergency-req: 8-12 > > >Henning, > > Since this is a requirements document, I'm trying to > exhaustively list all possible options, not pick favorites. > >A requirements document should be more generic. There's >almost a sense that you and James are writing an quasi-RFP >for US and European centers. Your words give the sense of >avoiding "the" solution by giving ranges of them. > >The goal should be to give the problem with some clarity to >SIPPING so that the group can determine 1. if it's a necessary >one for the WG. 2. if it's one that can be done with existing >SIP capabilities and whether they have issues such as security >strengths that might need modifications (a number of times SIPPING >has found that the feature was fine, but it needed some normative >modification). 3. if not, what requirements there are for new >SIP capabilities. I see far less generic material in the current >draft. > >I too am working to deadlines this weekend, so this comment must >be brief, but I have a real concern for what we will see from >this draft. > >Allison >_______________________________________________ >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 Mon Feb 24 09:47:30 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 JAA15551 for ; Mon, 24 Feb 2003 09:47:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OEu4c29987 for sipping-emergency-archive@odin.ietf.org; Mon, 24 Feb 2003 09:56:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OEu4p29984 for ; Mon, 24 Feb 2003 09:56:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15542 for ; Mon, 24 Feb 2003 09:46:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OEu3p29976 for ; Mon, 24 Feb 2003 09:56:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OEsxp29832 for ; Mon, 24 Feb 2003 09:54:59 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15524 for ; Mon, 24 Feb 2003 09:45:54 -0500 (EST) 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.3/8.12.3) with ESMTP id h1OEnixw022663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Feb 2003 09:49:46 -0500 (EST) Message-ID: <3E5A3123.3070502@cs.columbia.edu> Date: Mon, 24 Feb 2003 09:50:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: Emergency-req: 8-12 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 > I'm getting lost in what is the context. It looks to me like there are > three cases. > > a) someone uses IP-based phone or IM to call for help (sos/911) and this > hits a gateway (either regular IP-PSTN gateway or IP to text messaging > (e.g., SMS). What is required in this case? I was trying to avoid getting into the details of how the current system works and (more importantly) the properties it has, but maybe that's a bad idea. The case you describe has two important sub-cases: (1) The gateway is in the same town as the caller. (I'll say 'town' for simplicity; I mean 'same ECC serving area', but that's much longer...). In that case, the call reaches the right ECC. A problem arises if the phone has no E.164 phone number in the ECC calling area. As an example, if I take my Vonage/Denwa phone from New York to Lexington, I might configure the right local Lexington, KY gateway, but the poor PSAP will see a 212 phone number and have no clue where I am or who I am. (2) The gateway is in a different town. Since there are 5000 PSAPs in the US and it is unlikely that most service providers would use nearly that many gateways, this is a likely scenario. In addition to the problems in case (1), you are now connected to a gateway in the wrong city. Thus, if the Vonage gateway is in New York, my Lexington emergency call will reach the NYPD, which isn't going to be too helpful. I suspect that the New York 911 call taker things that I'm nuts if I tell them that the accident is a 1000 miles away. This is described without example and more tersely in the section 'Identifying the Appropriate Emergency Call Center'. Would it be helpful to write it up at this level? > b) someone uses IP-based phone or IM to call for help (sos/911) and this > goes end-to-end IP. (It appears to me that it might not be detectable to > the caller whether a gateway will intervene so perhaps what is required > should be the same as case a).) This is indeed somewhat similar. The location problem is easier, since the caller could route the call to the right ECC. > c) the receiving center is IP-based but calls come in from the PSTN. > > Have I got this correct? > > Now, if so, isn't this simple? What is needed? location information? > time-stamps? some assuredness that the message is authentic? ? The primary problem, as alluded to in the beginning of the end-to-end section, is getting the call to the right PSAP/ECC. That's a fundamental requirement - you're not going to get useful emergency service otherwise. A secondary requirement is that the ECC gets location and other information (hazardous materials at your place, etc.). That's a longer-term issue, since *current* wireless systems don't deliver that, either. (They will, in the next few years.) > > When I try to read the draft, I don't get it in clear language what is > needed but my feelings are that it shouldn't be that complicated. What am I > missing? In my view, this isn't complicated once you get down to the details. Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 04:47: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 EAA21841 for ; Tue, 25 Feb 2003 04:47:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P9u1B13191 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 04:56:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9u1p13187 for ; Tue, 25 Feb 2003 04:56:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21813 for ; Tue, 25 Feb 2003 04:46:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9u0p13171 for ; Tue, 25 Feb 2003 04:56:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9q9p13032 for ; Tue, 25 Feb 2003 04:52:09 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21791 for ; Tue, 25 Feb 2003 04:42:41 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1P9kFC21790; Tue, 25 Feb 2003 09:46:15 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 04:46:20 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E3A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" , Allison Mankin Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 Date: Tue, 25 Feb 2003 04:46:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , >From what I took away from our phone call, one concern was that the last-mile work needs to block until the geopriv work has become more fully specified. The short-term issues seemed like they might warrant a separate document precisely because that document is achievable (and passable by the IESG) in the short term. I also note that the document really doesn't seem to talk about the trunking-replacement architecture we discussed on the telephone call at all, except as a component of the end-to-end solution. If that this realistically the only architecture that will be deployed in the next few years, perhaps the document should give it more attention. One nit: if (following I-6) integrity properties of responses from an IECC are REQUIRED, this entails that authentication of the IECC to the caller is also REQUIRED (which would seem to contradict I-3). You cannot provide integrity properties without authentication. - J > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, February 22, 2003 3:00 PM > To: Allison Mankin > Cc: sipping-emergency@ietf.org > Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] > draft-schulzrinne-sipping-emergency-req-00 > > > The last-mile requirements are in a separate section, so I'm > not sure I > see the problem. (Besides, quite frankly, I'm not sure what > needs to be > done, SIP-wise, for the short-term issues. As I said, this is > effectively an ACD with conference recording. It might be > useful to say > that, but I think we might make some progress if we can identify, at > least within the design team, the likely areas needing work for the > last-mile case. There are, to be sure, other useful ways to > apply IP in > the last-mile case, but those are effectively geopriv > territory, namely > the authorized retrieval of location information given an > E.164 identifier.) > > Allison Mankin wrote: > > Henning, > > > > The problem with expressing all the requirements is that it > > will not guide the work and discussion on the shorter-term goals > > properly. > > > > Allison > > _______________________________________________ > 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 Feb 25 08:20:00 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 IAA00362 for ; Tue, 25 Feb 2003 08:20:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDT0B28473 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 08:29:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDT0p28470 for ; Tue, 25 Feb 2003 08:29:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00354 for ; Tue, 25 Feb 2003 08:19:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDSxp28460 for ; Tue, 25 Feb 2003 08:28:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDPOp28289 for ; Tue, 25 Feb 2003 08:25:24 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00230 for ; Tue, 25 Feb 2003 08:15:51 -0500 (EST) 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.3/8.12.3) with ESMTP id h1PDJZZU019347 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Feb 2003 08:19:39 -0500 (EST) Message-ID: <3E5B6D7D.70201@cs.columbia.edu> Date: Tue, 25 Feb 2003 08:19:57 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 References: <15A2739B7DAA624D8091C65981D7DA8101214E3A@stntexch2.va.neustar.com> In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E3A@stntexch2.va.neustar.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 Maybe this is due to the lack of precision on my part, but the 'last-mile' section (Section 4) is exactly that. Indeed, the very first sentence says "In last-mile access, an ECC replaces an analog (CAMA) or digital (ISDN) trunk with packet-based access, typically over one or more high-speed access lines such as DSL or leased lines." Suggestions on how to make this clearer are welcome. Peterson, Jon wrote: >>From what I took away from our phone call, one concern was that the > last-mile work needs to block until the geopriv work has become more fully > specified. The short-term issues seemed like they might warrant a separate > document precisely because that document is achievable (and passable by the > IESG) in the short term. > > I also note that the document really doesn't seem to talk about the > trunking-replacement architecture we discussed on the telephone call at all, > except as a component of the end-to-end solution. If that this realistically > the only architecture that will be deployed in the next few years, perhaps > the document should give it more attention. I'm afraid I don't see this. Section 4 draws largely from the NENA TID, which only talks about trunk replacement. > > One nit: if (following I-6) integrity properties of responses from an IECC > are REQUIRED, this entails that authentication of the IECC to the caller is > also REQUIRED (which would seem to contradict I-3). You cannot provide > integrity properties without authentication. Depends on what you're protecting. If you're protecting the integrity of the request from caller to IECC (e.g., including the location information), the IECC doesn't have to be authenticated. Also, I don't see why this has to wait until geopriv is done. While the details on how this works will obviously be affected by the concrete output of geopriv, the requirements remain the same. Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 09:52:01 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 JAA02373 for ; Tue, 25 Feb 2003 09:52:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PF14v02368 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 10:01:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PF14p02365 for ; Tue, 25 Feb 2003 10:01:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02352 for ; Tue, 25 Feb 2003 09:51:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PF11p02340 for ; Tue, 25 Feb 2003 10:01:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PF00p02253 for ; Tue, 25 Feb 2003 10:00:00 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02312 for ; Tue, 25 Feb 2003 09:50:25 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for sipping-emergency@ietf.org; Tue, 25 Feb 2003 09:53:10 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003022509540417232 ; Tue, 25 Feb 2003 09:54:04 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 09:56:07 -0500 Message-Id: From: "King, Kimberly S." To: "'Henning Schulzrinne'" , "Peterson, Jon" Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 Date: Tue, 25 Feb 2003 09:54:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , Henning, >"In last-mile access, an ECC replaces an analog (CAMA) or >digital (ISDN) >trunk with packet-based access, >typically over one or more high-speed access lines such as DSL >or leased >lines." > >Suggestions on how to make this clearer are welcome. I believe it isn't as clear because it disorients the reader. The last mile (reader is thinking from the perspective of being the client) has packet-based access (access puts the reader in the perspective of being on the "server" side). I can't completely re-word it as I'm not totally clear what you are trying to say but I'll take a shot at it. "In the last mile situation, instead of calls being terminated by analog (CAMA) or digital (ISDN) trunks, they are terminated by high-speed DSL or leased line packet-based solutions." Kimberly _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 10:02:59 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 KAA02603 for ; Tue, 25 Feb 2003 10:02:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PFC2G03523 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 10:12:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFC2p03520 for ; Tue, 25 Feb 2003 10:12:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02586 for ; Tue, 25 Feb 2003 10:02:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFC1p03512 for ; Tue, 25 Feb 2003 10:12:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFBIp03494 for ; Tue, 25 Feb 2003 10:11:18 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02559 for ; Tue, 25 Feb 2003 10:01:44 -0500 (EST) 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.3/8.12.3) with ESMTP id h1PF5Zs7008557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Feb 2003 10:05:36 -0500 (EST) Message-ID: <3E5B8655.4000202@cs.columbia.edu> Date: Tue, 25 Feb 2003 10:05:57 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "King, Kimberly S." CC: "Peterson, Jon" , sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00 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 Maybe we're getting closer to the source of the confusion... During the teleconference, I had associated 'last-mile' with the recently-completed NENA effort, which only deals with what section 4 describes. Since it's the last mile before reaching the PSAP/ECC, I used that term. Maybe others were thinking of what I'd consider 'first-mile', i.e., from a VoIP phone to a PSTN gateway? That might explain a few of the rounds of discussion... Jon, Allison: where's first and last? :-) King, Kimberly S. wrote: > Henning, > > >>"In last-mile access, an ECC replaces an analog (CAMA) or >>digital (ISDN) >>trunk with packet-based access, >>typically over one or more high-speed access lines such as DSL >>or leased >>lines." >> >>Suggestions on how to make this clearer are welcome. > > > > I believe it isn't as clear because it disorients the reader. The last mile > (reader is thinking from the perspective of being the client) has > packet-based access (access puts the reader in the perspective of being on > the "server" side). > > I can't completely re-word it as I'm not totally clear what you are trying > to say but I'll take a shot at it. > > "In the last mile situation, instead of calls being terminated by analog > (CAMA) or digital (ISDN) trunks, they are terminated by high-speed DSL or > leased line packet-based solutions." > > Kimberly _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 16:33:01 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 QAA18357 for ; Tue, 25 Feb 2003 16:33:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PLgDC00785 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 16:42:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLgCp00782 for ; Tue, 25 Feb 2003 16:42:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18335 for ; Tue, 25 Feb 2003 16:32:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLgBp00774 for ; Tue, 25 Feb 2003 16:42:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLeWp00694 for ; Tue, 25 Feb 2003 16:40:32 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18309 for ; Tue, 25 Feb 2003 16:30:47 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1PLX3C05519; Tue, 25 Feb 2003 21:33:03 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 16:33:09 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E3F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 Date: Tue, 25 Feb 2003 16:33:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , Heh, right. I've been considering the 'last mile' chunk to be between the end user (currently, their POTS phone - in the future, their IP phone) and the selection router - that's how I thought we were using the term in our conf call, and hence my confusion (I was contrasting the terms 'last mile' with 'trunking replacement' on the call). The use of the term 'access' in the title of section 4 made me think you were describing the access portion of the network (i.e. copper to the home, etc). Your suggestion in the intro to the section that the transport could be analog or ISDN but might be replaced with DSL certainly supported that reading. I thought the term 'trunking' was used casually there. I guess looking more closely at that section, requirement M-7 and a few others might have tipped me off that these requirements were about the trunking replacement. The definition in section 3 of 'last mile emergency service' also is a pretty good indicator. I don't know if this would have been unclear to someone who hadn't been on our conference call. I imagine that paraphrasing the definition of 'last mile' from section 3 in the intro to section 4 would clear up any conceivable ambiguity. I also would avoid using the term 'access' in the title of section 4. >From my perspective anyway, what I'm concerned about is that the full e2e solution be bundled separately from the more immediately achievable work. Whether or not these two are in separate sections is less material to me, but ultimately, we know that the section 4 solution is not depending on geopriv, but the later material is. I think there is value in having the section 4 work go forward on its own merits, and fully specifying this solution - I know you think this is trivial, but to me, trivial means achievable. :) Putting the later e2e work in a separate document would remove any geopriv dependencies for the section 4 work. - J > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, February 25, 2003 7:06 AM > To: King, Kimberly S. > Cc: Peterson, Jon; sipping-emergency@ietf.org > Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] > draft-schulzrinne-sipping-emergency-req-00 > > > Maybe we're getting closer to the source of the confusion... > During the > teleconference, I had associated 'last-mile' with the > recently-completed > NENA effort, which only deals with what section 4 describes. > Since it's > the last mile before reaching the PSAP/ECC, I used that term. Maybe > others were thinking of what I'd consider 'first-mile', i.e., from a > VoIP phone to a PSTN gateway? > > That might explain a few of the rounds of discussion... Jon, Allison: > where's first and last? :-) > > King, Kimberly S. wrote: > > Henning, > > > > > >>"In last-mile access, an ECC replaces an analog (CAMA) or > >>digital (ISDN) > >>trunk with packet-based access, > >>typically over one or more high-speed access lines such as DSL > >>or leased > >>lines." > >> > >>Suggestions on how to make this clearer are welcome. > > > > > > > > I believe it isn't as clear because it disorients the > reader. The last mile > > (reader is thinking from the perspective of being the client) has > > packet-based access (access puts the reader in the > perspective of being on > > the "server" side). > > > > I can't completely re-word it as I'm not totally clear what > you are trying > > to say but I'll take a shot at it. > > > > "In the last mile situation, instead of calls being > terminated by analog > > (CAMA) or digital (ISDN) trunks, they are terminated by > high-speed DSL or > > leased line packet-based solutions." > > > > Kimberly > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 16:42:51 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 QAA18653 for ; Tue, 25 Feb 2003 16:42:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PLq3601237 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 16:52:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLq3p01234 for ; Tue, 25 Feb 2003 16:52:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18640 for ; Tue, 25 Feb 2003 16:42:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLq1p01217 for ; Tue, 25 Feb 2003 16:52:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLpcp01183 for ; Tue, 25 Feb 2003 16:51:38 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18632 for ; Tue, 25 Feb 2003 16:41:55 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1PLirC05904; Tue, 25 Feb 2003 21:44:53 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 16:44:59 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E43@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" , "King, Kimberly S." Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 Date: Tue, 25 Feb 2003 16:44:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , I also looked around a bit on the web to see how the term 'last-mile' was being used. This seems typical of the definitions I could find: The last mile refers to the distance between the subscriber and the telephone company's central office, or the subscriber and the neighborhood node of the cable company. http://cablingdb.com/GlossaryPages/GlossaryL/Last_Mile.asp Refers to the telecommunications technology that connects the customer's home directly to the cable or telephone company. When used as an adjective, spelled last-mile, as in "the last-mile technology." http://isp.webopedia.com/TERM/L/last_mile.html - J > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, February 25, 2003 1:33 PM > To: 'Henning Schulzrinne'; King, Kimberly S. > Cc: sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] > draft-schulzrinne -sipping-emergency-req-00 > > > > Heh, right. I've been considering the 'last mile' chunk to be > between the > end user (currently, their POTS phone - in the future, their > IP phone) and > the selection router - that's how I thought we were using the > term in our > conf call, and hence my confusion (I was contrasting the > terms 'last mile' > with 'trunking replacement' on the call). The use of the term > 'access' in > the title of section 4 made me think you were describing the > access portion > of the network (i.e. copper to the home, etc). Your > suggestion in the intro > to the section that the transport could be analog or ISDN but might be > replaced with DSL certainly supported that reading. I thought the term > 'trunking' was used casually there. > > I guess looking more closely at that section, requirement M-7 > and a few > others might have tipped me off that these requirements were about the > trunking replacement. The definition in section 3 of 'last > mile emergency > service' also is a pretty good indicator. I don't know if > this would have > been unclear to someone who hadn't been on our conference > call. I imagine > that paraphrasing the definition of 'last mile' from section > 3 in the intro > to section 4 would clear up any conceivable ambiguity. I also > would avoid > using the term 'access' in the title of section 4. > > From my perspective anyway, what I'm concerned about is that > the full e2e > solution be bundled separately from the more immediately > achievable work. > Whether or not these two are in separate sections is less > material to me, > but ultimately, we know that the section 4 solution is not > depending on > geopriv, but the later material is. I think there is value in > having the > section 4 work go forward on its own merits, and fully specifying this > solution - I know you think this is trivial, but to me, trivial means > achievable. :) Putting the later e2e work in a separate document would > remove any geopriv dependencies for the section 4 work. > > - J > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, February 25, 2003 7:06 AM > > To: King, Kimberly S. > > Cc: Peterson, Jon; sipping-emergency@ietf.org > > Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] > > draft-schulzrinne-sipping-emergency-req-00 > > > > > > Maybe we're getting closer to the source of the confusion... > > During the > > teleconference, I had associated 'last-mile' with the > > recently-completed > > NENA effort, which only deals with what section 4 describes. > > Since it's > > the last mile before reaching the PSAP/ECC, I used that term. Maybe > > others were thinking of what I'd consider 'first-mile', > i.e., from a > > VoIP phone to a PSTN gateway? > > > > That might explain a few of the rounds of discussion... > Jon, Allison: > > where's first and last? :-) > > > > King, Kimberly S. wrote: > > > Henning, > > > > > > > > >>"In last-mile access, an ECC replaces an analog (CAMA) or > > >>digital (ISDN) > > >>trunk with packet-based access, > > >>typically over one or more high-speed access lines such as DSL > > >>or leased > > >>lines." > > >> > > >>Suggestions on how to make this clearer are welcome. > > > > > > > > > > > > I believe it isn't as clear because it disorients the > > reader. The last mile > > > (reader is thinking from the perspective of being the client) has > > > packet-based access (access puts the reader in the > > perspective of being on > > > the "server" side). > > > > > > I can't completely re-word it as I'm not totally clear what > > you are trying > > > to say but I'll take a shot at it. > > > > > > "In the last mile situation, instead of calls being > > terminated by analog > > > (CAMA) or digital (ISDN) trunks, they are terminated by > > high-speed DSL or > > > leased line packet-based solutions." > > > > > > Kimberly > > > _______________________________________________ > 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 Feb 25 16:56:51 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 QAA19256 for ; Tue, 25 Feb 2003 16:56:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PM63P02446 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 17:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PM63p02443 for ; Tue, 25 Feb 2003 17:06:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19242 for ; Tue, 25 Feb 2003 16:56:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PM61p02427 for ; Tue, 25 Feb 2003 17:06:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PM5Mp02392 for ; Tue, 25 Feb 2003 17:05:22 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19203 for ; Tue, 25 Feb 2003 16:55:39 -0500 (EST) 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.3/8.12.3) with ESMTP id h1PLxTWP024513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Feb 2003 16:59:34 -0500 (EST) Message-ID: <3E5BE755.20601@cs.columbia.edu> Date: Tue, 25 Feb 2003 16:59:49 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "King, Kimberly S." , sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 References: <15A2739B7DAA624D8091C65981D7DA8101214E43@stntexch2.va.neustar.com> In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E43@stntexch2.va.neustar.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 think we'll be better off I replace last-mile by 'ECC trunk replacement'. I'm not too wedded to terminology. Peterson, Jon wrote: > I also looked around a bit on the web to see how the term 'last-mile' was > being used. This seems typical of the definitions I could find: > > The last mile refers to the distance between the subscriber and the > telephone company's central office, or the subscriber and the neighborhood > node of the cable company. > > http://cablingdb.com/GlossaryPages/GlossaryL/Last_Mile.asp > > Refers to the telecommunications technology that connects the customer's > home directly to the cable or telephone company. When used as an adjective, > spelled last-mile, as in "the last-mile technology." > > http://isp.webopedia.com/TERM/L/last_mile.html > > - J > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 16:59:52 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 QAA19377 for ; Tue, 25 Feb 2003 16:59:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PM93Z03429 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 17:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PM93p03426 for ; Tue, 25 Feb 2003 17:09:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19331 for ; Tue, 25 Feb 2003 16:59:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PM92p03418 for ; Tue, 25 Feb 2003 17:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PM8op03307 for ; Tue, 25 Feb 2003 17:08:50 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19327 for ; Tue, 25 Feb 2003 16:59:07 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1PM2IC06710; Tue, 25 Feb 2003 22:02:18 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 17:02:24 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E47@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "King, Kimberly S." , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 Date: Tue, 25 Feb 2003 17:02:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , That would be fine with me. - J > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, February 25, 2003 2:00 PM > To: Peterson, Jon > Cc: King, Kimberly S.; sipping-emergency@ietf.org > Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] > draft-schulzrinne -sipping-emergency-req-00 > > > I think we'll be better off I replace last-mile by 'ECC trunk > replacement'. I'm not too wedded to terminology. > > Peterson, Jon wrote: > > I also looked around a bit on the web to see how the term > 'last-mile' was > > being used. This seems typical of the definitions I could find: > > > > The last mile refers to the distance between the subscriber and the > > telephone company's central office, or the subscriber and > the neighborhood > > node of the cable company. > > > > http://cablingdb.com/GlossaryPages/GlossaryL/Last_Mile.asp > > > > Refers to the telecommunications technology that connects > the customer's > > home directly to the cable or telephone company. When used > as an adjective, > > spelled last-mile, as in "the last-mile technology." > > > > http://isp.webopedia.com/TERM/L/last_mile.html > > > > - J > > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Tue Feb 25 17:50:48 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 RAA20587 for ; Tue, 25 Feb 2003 17:50:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PN02U06001 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 18:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PN02p05998 for ; Tue, 25 Feb 2003 18:00:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20584 for ; Tue, 25 Feb 2003 17:50:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PN01p05990 for ; Tue, 25 Feb 2003 18:00:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMxbp05952 for ; Tue, 25 Feb 2003 17:59:37 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20581 for ; Tue, 25 Feb 2003 17:49:52 -0500 (EST) 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.3/8.12.3) with ESMTP id h1PMrkWP022723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Feb 2003 17:53:47 -0500 (EST) Message-ID: <3E5BF40F.4020708@cs.columbia.edu> Date: Tue, 25 Feb 2003 17:54:07 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 References: <15A2739B7DAA624D8091C65981D7DA8101214E3F@stntexch2.va.neustar.com> In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E3F@stntexch2.va.neustar.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 >>From my perspective anyway, what I'm concerned about is that the full e2e > solution be bundled separately from the more immediately achievable work. > Whether or not these two are in separate sections is less material to me, > but ultimately, we know that the section 4 solution is not depending on > geopriv, but the later material is. I think there is value in having the > section 4 work go forward on its own merits, and fully specifying this > solution - I know you think this is trivial, but to me, trivial means > achievable. :) Putting the later e2e work in a separate document would > remove any geopriv dependencies for the section 4 work. I would like to identify any real work which isn't just "purchasing requirements for PSAP RFP" in the trunk replacement part. Can you identify anything? I happen to think that while end-to-end or even first-mile (something I haven't called out explicitly) does need geo information that the problem can be scoped properly so that it does not interfere with geopriv work. At this point, I don't see the need to specify in detail how the PSAP gets the location of the caller. We know it needs to - I don't think geopriv is going to change that. There are only two plausible ways to convey location - in a 'using protocol' and in some out-of-band retrieval mode using a geopriv-specific mechanism. I don't think that level of detail is controversial or likely to change. Also, the PSAP selection problem can be partially solved with existing (apparently non-controversial) items in geopriv, namely the DHCP items. Thus, as long as we assume that geopriv does its job, we can fill in the other pieces and make progress, treating geopriv as a suitable black box. Thus, if we scope the work properly, I don't see why we'd bump into geopriv issues except saying "you guys over there, we'll need you, get busy". Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Wed Feb 26 16:14:22 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 QAA25865 for ; Wed, 26 Feb 2003 16:14:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QLO2Z11765 for sipping-emergency-archive@odin.ietf.org; Wed, 26 Feb 2003 16:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLO2p11762 for ; Wed, 26 Feb 2003 16:24:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25853 for ; Wed, 26 Feb 2003 16:13:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLO1p11726 for ; Wed, 26 Feb 2003 16:24:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLN5p11691 for ; Wed, 26 Feb 2003 16:23:05 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25786 for ; Wed, 26 Feb 2003 16:12:54 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1QLGCC30008; Wed, 26 Feb 2003 21:16:12 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 16:16:19 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E5A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 Date: Wed, 26 Feb 2003 16:16:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , inline. - J > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, February 25, 2003 2:54 PM > To: Peterson, Jon > Cc: sipping-emergency@ietf.org > Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] > draft-schulzrinne -sipping-emergency-req-00 > > [snip] > > I would like to identify any real work which isn't just "purchasing > requirements for PSAP RFP" in the trunk replacement part. Can you > identify anything? > Well, there are a number of issues, I think, many of which you identify in your section 4 (in M1-M12). Some other things include: - For ISUP e911 trunks, ISUP encapsulation in SIP seems like a reasonable way to carry signaling information between the selective router and the IECC. What about for non-ISUP signaling systems? - What sorts of URIs are used to represent IECCs (especially in light of M4 and and M12)? - Are there any special rules for the distribution of credentials used for authentication between IECCs and selective routers? How many IECCs are associated with selective routers and vice versa? - Are there any RTP requirements that emerge from M6? Again, this might not require radical new extensions to the SIP protocol - it's probably doable with more or less the tools we have today. But depicting a framework and architecture in an I-D along with the section 4 reqs would make it easier for the industry to understand how this trunking replacement solution fits in. > I happen to think that while end-to-end or even first-mile (something I > haven't called out explicitly) does need geo information that the > problem can be scoped properly so that it does not interfere with > geopriv work. At this point, I don't see the need to specify in detail > how the PSAP gets the location of the caller. We know it needs to - I > don't think geopriv is going to change that. There are only two > plausible ways to convey location - in a 'using protocol' and in some > out-of-band retrieval mode using a geopriv-specific mechanism. I don't > think that level of detail is controversial or likely to change. > If the PSAP is expected to retrieve or receive the location information over IP, then I would argue we've moved into the realm of geopriv. If on the other the PSAP derives this location information from an ALI interface, then we don't need geopriv - but, ALI is only relevant to telephone numbers, at least at the moment. Not all SIP endpoints will have telephone numbers, etc. > Also, the PSAP selection problem can be partially solved with existing > (apparently non-controversial) items in geopriv, namely the DHCP items. > PSAP selection isn't really the main problem here, I think. I agree that DHCP could help with PSAP selection. Certainly there hasn't been much controversy about the DHCP proposal to date, but I would note that the WG is more focused on delivering a framework and requirements that jumping into a solution. The DHCP solution is, as far as I understand it, oriented towards informing a telephone where it lives. The degree to which this entails moving location information (civil or geospatial) over an open IP network will largely dictate whether or not DHCP would have to meet the security and policy requirements of geopriv. Until those requirements are finished, it's hard to establish how well the DHCP solution meets them. > Thus, as long as we assume that geopriv does its job, we can fill in the > other pieces and make progress, treating geopriv as a suitable black box. > > Thus, if we scope the work properly, I don't see why we'd bump into > geopriv issues except saying "you guys over there, we'll need you, get > busy". > > Henning > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Wed Feb 26 16:38:22 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 QAA27049 for ; Wed, 26 Feb 2003 16:38:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QLm2513705 for sipping-emergency-archive@odin.ietf.org; Wed, 26 Feb 2003 16:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLm2p13702 for ; Wed, 26 Feb 2003 16:48:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27031 for ; Wed, 26 Feb 2003 16:37:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLm1p13694 for ; Wed, 26 Feb 2003 16:48:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLlWp13660 for ; Wed, 26 Feb 2003 16:47:32 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27007 for ; Wed, 26 Feb 2003 16:37:20 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 26 Feb 2003 13:41:04 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA07484; Wed, 26 Feb 2003 13:41:14 -0800 (PST) Message-Id: <4.3.2.7.2.20030226153806.09aaaee8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 15:41:09 -0600 To: Henning Schulzrinne , "Peterson, Jon" From: "James M. Polk" Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 Cc: "King, Kimberly S." , sipping-emergency@ietf.org In-Reply-To: <3E5BE755.20601@cs.columbia.edu> References: <15A2739B7DAA624D8091C65981D7DA8101214E43@stntexch2.va.neustar.com> <15A2739B7DAA624D8091C65981D7DA8101214E43@stntexch2.va.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 04:59 PM 2/25/2003 -0500, Henning Schulzrinne wrote: >I think we'll be better off I replace last-mile by 'ECC trunk >replacement'. I'm not too wedded to terminology. I'll jump on here, this was my confusion in my long list of comments as well - were you referring to the last mile (from the subscriber) or the first mile (from the PSAP)? Notice this is why I emphasized HFC connectivity (which is prevalent to the home). Upon my additional reading, you did define the idea in how you look at it, but used terms the rest of us use differently. We obviously took our definitions to heart in our comments. I'll stop beating a dead horse now cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Thu Feb 27 10:19:02 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 KAA07719 for ; Thu, 27 Feb 2003 10:19:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RFT3m27345 for sipping-emergency-archive@odin.ietf.org; Thu, 27 Feb 2003 10:29:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFT3p27342 for ; Thu, 27 Feb 2003 10:29:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07679 for ; Thu, 27 Feb 2003 10:18:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFT1p27324 for ; Thu, 27 Feb 2003 10:29:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFS8p27249 for ; Thu, 27 Feb 2003 10:28:08 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07635 for ; Thu, 27 Feb 2003 10:17:34 -0500 (EST) 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.3/8.12.3) with ESMTP id h1RFLR7T000255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Feb 2003 10:21:28 -0500 (EST) Message-ID: <3E5E2D02.30406@cs.columbia.edu> Date: Thu, 27 Feb 2003 10:21:38 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00 References: <15A2739B7DAA624D8091C65981D7DA8101214E5A@stntexch2.va.neustar.com> In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E5A@stntexch2.va.neustar.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 > Well, there are a number of issues, I think, many of which you identify in > your section 4 (in M1-M12). Some other things include: At least from my vantage point, all of them are effectively the same requirements that apply to a PBX with ACD. Can you identify any that cannot be done with existing or in-progress SIP* work? At best, this could result in a draft similar to the end system requirements that Henry Sinnreich and others are putting together, but that seems to stray very far into "RFP list" territory. > > - For ISUP e911 trunks, ISUP encapsulation in SIP seems like a reasonable > way to carry signaling information between the selective router and the > IECC. What about for non-ISUP signaling systems? I don't see the advantage of carrying ISUP information across the IP trunk. The only information that's in a 911 call right now is the ANI. We know how to do that in SIP - stick a tel URI in the From header or use one of the NAI mechanisms to convey the ANI. (By definition, the ECC has to trust the selective router, so that model fits.) > > - What sorts of URIs are used to represent IECCs (especially in light of M4 > and and M12)? I suspect that they'll tel URIs for now, SIP URIs later. What would be different about them? > > - Are there any special rules for the distribution of credentials used for > authentication between IECCs and selective routers? How many IECCs are > associated with selective routers and vice versa? I suspect the number of ECCs per SR is smallish (no more than a handful). Assuming the SR uses SIP addressing, it knows that a certain ECC is addressed as, say, psap.fayette.co.ky.us (for the Fayette County, Kentucky PSAP). This knowledge has to be hard-configured, so standard TLS server certs will do the job. > > - Are there any RTP requirements that emerge from M6? I don't see how call routing affects RTP. Call routing is just a policy within the ECC proxy, not very different from how an airline would manage their callcenter. > > Again, this might not require radical new extensions to the SIP protocol - > it's probably doable with more or less the tools we have today. But That's my perception as well. > depicting a framework and architecture in an I-D along with the section 4 > reqs would make it easier for the industry to understand how this trunking > replacement solution fits in. That's all useful (with the "RFP caveat" above), but doesn't solve the real problem of SIP terminals placing emergency calls. > If the PSAP is expected to retrieve or receive the location information over > IP, then I would argue we've moved into the realm of geopriv. If on the > other the PSAP derives this location information from an ALI interface, then > we don't need geopriv - but, ALI is only relevant to telephone numbers, at > least at the moment. Not all SIP endpoints will have telephone numbers, etc. The emergency call problem is not going to get solved in one step. After all, most wireless phones still only convey the most basic location information (cell sector). I don't see the benefit of delaying what we can do today. However, saying that it doesn't work for all phones doesn't seem to be reason to delay making it work for most SIP endpoints (which will have or be able to get a phone number). Note that a SIP endpoint doesn't even have to have a permanent, addressable phone number to make traditional ALI work. You can assign what's known as an ELIN, which is a pseudo-number which is then mapped to a location. This is done for MLTS (multi-line phone systems) for 911 today - in a handful of states, it's even mandated by law for larger businesses. After all, many black-phone extensions without DID don't have real phone numbers, either. > > >>Also, the PSAP selection problem can be partially solved with existing >>(apparently non-controversial) items in geopriv, namely the DHCP items. >> > > > PSAP selection isn't really the main problem here, I think. I agree that > DHCP could help with PSAP selection. I disagree. PSAP selection is *the* main problem for consumer and business VoIP emergency deployment. If you don't get that right, you've added minutes, at best, to the emergency call, as the confused call taker tries to figure out which part of the country the emergency call is from. I'm sure that if I call from where I live right now and reach a NY gateway, that my call will be sent to Lexington, MA instead of Lexington, KY... While conveying location information automatically to the ECC is an important service, it is secondary to getting the call through. After all, we do without today for almost all wireless calls and all telematics (OnStar, etc.) calls. > > Certainly there hasn't been much controversy about the DHCP proposal to > date, but I would note that the WG is more focused on delivering a framework > and requirements that jumping into a solution. The DHCP solution is, as far > as I understand it, oriented towards informing a telephone where it lives. Correct (or mostly, as it may only be able to identify the location of the switch or access point). > The degree to which this entails moving location information (civil or > geospatial) over an open IP network will largely dictate whether or not DHCP > would have to meet the security and policy requirements of geopriv. Until > those requirements are finished, it's hard to establish how well the DHCP > solution meets them. While I can see that kidnapping-is-us may not want its victims to find out where they are, I'm having a hard time seeing how this information provides anything that isn't visible to any human being in the same place. Even if we ignore the particular mechanism for getting the location information to the device (after all, there are likely to be many different ones, from local GPS to various query mechanisms), the remainder of the architecture doesn't really change. Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency