From mailnull@www1.ietf.org Thu Apr 3 04:30: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 EAA11260 for ; Thu, 3 Apr 2003 04:30:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h339XBq25485 for sipping-emergency-archive@odin.ietf.org; Thu, 3 Apr 2003 04:33: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 h339XBK25482 for ; Thu, 3 Apr 2003 04:33:11 -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 EAA11245 for ; Thu, 3 Apr 2003 04:30: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 h339XAK25473 for ; Thu, 3 Apr 2003 04:33:10 -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 h339SUK25255 for ; Thu, 3 Apr 2003 04:28:30 -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 EAA11166 for ; Thu, 3 Apr 2003 04:25:47 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h339S3I3019837; Thu, 3 Apr 2003 11:28:03 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4RX8GL; Thu, 3 Apr 2003 11:28:04 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h339S3Av021169; Thu, 3 Apr 2003 12:28:03 +0300 (EET DST) Message-ID: <3E8BFEA1.2080501@lmf.ericsson.se> Date: Thu, 03 Apr 2003 12:28:01 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Jonathan Rosenberg'" , "'Jon Peterson (jon.peterson@NeuStar.com)'" , "'Rohan Mahy'" , "'Henning Schulzrinne'" , "'Tom Taylor'" , "'Gonzalo Camarillo'" , mankin@psg.com, Mary Barnes , Emergency References: <004901c2f951$09038cd0$ee036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Re: Report on sipemergency call 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, my action points... > 1) Gonzalo: Please add myself, Mary, and Tom to the sip-emergency list and > SIPPING design team. I have added the email addresses below to the mailing list dean.willis@softarmor.com mbarnes@nortelnetworks.com taylor@nortelnetworks.com jdrosen@dynamicsoft.com I have added all four to the design team: http://www.softarmor.com/sipping/teams/emergency/ Cheers, Gonzalo _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Thu Apr 3 13:05:40 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 NAA04641 for ; Thu, 3 Apr 2003 13:05:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33I81p10213 for sipping-emergency-archive@odin.ietf.org; Thu, 3 Apr 2003 13:08: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 h33I81K10210 for ; Thu, 3 Apr 2003 13:08: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 NAA04629 for ; Thu, 3 Apr 2003 13:05:09 -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 h33I80K10202 for ; Thu, 3 Apr 2003 13:08: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 h33I7wK10188 for ; Thu, 3 Apr 2003 13:07:58 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04626 for ; Thu, 3 Apr 2003 13:05:06 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33I7WJ11587 for ; Thu, 3 Apr 2003 13:07:32 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFVBP70; Thu, 3 Apr 2003 13:07:32 -0500 Received: from nortelnetworks.com (acart1c5.ca.nortel.com [47.129.129.48]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWMTP; Thu, 3 Apr 2003 13:07:33 -0500 Message-ID: <3E8C785E.7070203@nortelnetworks.com> Date: Thu, 03 Apr 2003 13:07:26 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Scenario Document Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've sent this to the list rather than individuals. Will I be missing anyone (e.g. Jon, Allison)? This is how I propose to structure the scenarios document. You may tell me if this covers too much: 1. System Requirements Here's the complete list as I understand it. Feel free to suggest additions or modifications. (a) Provide a means for an user to direct a call to the emergency call centre in jurisdiction. (b) Provide a means for the emergency call centre to determine the geographic location of the calling user. (c) Provide a means for the emergency call centre to call back to the user should this be necessary. 2. System Components Here I would include Dean's list, which he classified into "degrees of freedom" and "information sources". 3. Scenario Description and Analysis Here I would describe each scenario, then analyze the associated logical constraints on our use of the degrees of freedom and information sources. 4. Conclusions This would summarize the constraints on solution, looking across the different scenarios. Comments? _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Thu Apr 3 14:04:39 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 OAA07285 for ; Thu, 3 Apr 2003 14:04:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33J71517193 for sipping-emergency-archive@odin.ietf.org; Thu, 3 Apr 2003 14: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 h33J71K17190 for ; Thu, 3 Apr 2003 14: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 OAA07268 for ; Thu, 3 Apr 2003 14:04:07 -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 h33J70K17142 for ; Thu, 3 Apr 2003 14: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 h33J6iK17074 for ; Thu, 3 Apr 2003 14:06:44 -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 OAA07257 for ; Thu, 3 Apr 2003 14:03:50 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 03 Apr 2003 11:06:19 -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 LAA26819; Thu, 3 Apr 2003 11:06:17 -0800 (PST) Message-Id: <4.3.2.7.2.20030403130453.0224f130@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Apr 2003 13:06:32 -0600 To: Tom Taylor , sipping-emergency@ietf.org From: "James M. Polk" Subject: Re: [Sipping-emergency] Scenario Document In-Reply-To: <3E8C785E.7070203@nortelnetworks.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: , Tom Have you read Henning's Requirements ID? It seems to cover what you mention, unless you plan on expanding much more than his ID, which there is already some contention on parts of - which is why I'm commenting on your email. At 01:07 PM 4/3/2003 -0500, Tom Taylor wrote: >I've sent this to the list rather than individuals. Will I be missing >anyone (e.g. Jon, Allison)? > >This is how I propose to structure the scenarios document. You may tell >me if this covers too much: > >1. System Requirements > >Here's the complete list as I understand it. Feel free to suggest >additions or modifications. > >(a) Provide a means for an user to direct a call to the emergency call >centre in jurisdiction. > >(b) Provide a means for the emergency call centre to determine the >geographic location of the calling user. > >(c) Provide a means for the emergency call centre to call back to the user >should this be necessary. > >2. System Components > >Here I would include Dean's list, which he classified into "degrees of >freedom" and "information sources". > >3. Scenario Description and Analysis > >Here I would describe each scenario, then analyze the associated logical >constraints on our use of the degrees of freedom and information sources. > >4. Conclusions > >This would summarize the constraints on solution, looking across the >different scenarios. > >Comments? > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ************************************* "The road to destruction is well traveled and crowded, if you choose to get on that road, destruction will hit you head on" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Thu Apr 3 15:09:42 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 PAA10230 for ; Thu, 3 Apr 2003 15:09:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33KC7F24383 for sipping-emergency-archive@odin.ietf.org; Thu, 3 Apr 2003 15:12:07 -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 h33KC7K24380 for ; Thu, 3 Apr 2003 15:12:07 -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 PAA10178 for ; Thu, 3 Apr 2003 15:09:11 -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 h33KC5K24372 for ; Thu, 3 Apr 2003 15:12:05 -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 h33K96K24134 for ; Thu, 3 Apr 2003 15:09:06 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09827 for ; Thu, 3 Apr 2003 15:06:10 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33K8c305863 for ; Thu, 3 Apr 2003 15:08:38 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFDHY62; Thu, 3 Apr 2003 15:08:38 -0500 Received: from nortelnetworks.com (acart1c5.ca.nortel.com [47.129.129.48]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWMVF; Thu, 3 Apr 2003 15:08:39 -0500 Message-ID: <3E8C94C2.9090706@nortelnetworks.com> Date: Thu, 03 Apr 2003 15:08:34 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] [Fwd: Report on sipemergency call] 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 Apologies for the duplication. I've forwarded Dean's minutes to the complete sipping-emergency list so James can see where I'm coming from in doing the scenarios document. There was a bit of discussion following these minutes, so you may want to consult the archives. -------- Original Message -------- Subject: Report on sipemergency call Date: Wed, 2 Apr 2003 13:49:52 -0600 From: Dean Willis To: 'Jonathan Rosenberg' , 'Jon Peterson (jon.peterson@NeuStar.com)' , 'Rohan Mahy' , 'Henning Schulzrinne' , Taylor, Tom-PT [CAR:5N00:EXCH], 'Gonzalo Camarillo' , , Barnes, Mary [NGC:B602:EXCH] CC: Given the scheduling confusion, the call proceeded with myself, Mary Barnes, Tom Taylor, and Henning Schulzrinne in attendance. Sorry folks -- too many irons in the fire, not enough wranglers to hold the cows down. We discussed both the background and our current knowledge of the situation, including some info that Henning just picked up at VON while talking to Nate Wilcox of the Vermont 911 center. Our current proposal is to proceed with developing a scenarios document which will capture a little of the analysis as well as describing the known main problem modalities. This will provide background for a "guidelines" document that will help implementers understand the limitations and effectively use existing specifications, perhaps including usage conventions. Further analysis of the scenarios and guidelines will provide input to Henning's longer-reaching requirements draft and potential future work on more sophisticated solutions. Tom and Mary have agreed to take a crack at drafting the scenarios document, and will attempt to coordinate the vocabulary with that used in Henning's requirements draft, for example "emergency call center" instead of PSAP. Three "degrees of freedom" in the system were identified: 1) Phones 2) Gateways 3) Emergency call centers Six "information sources" were identified: 1) User of the phone 2) The phone and supporting network 3) Gateways 4) The service provider and its routing systems 5) Emergency call centers 6) Third-party database providers We identified five basic scenarios in the discussion: 1) Stationary SIP phones having known locations and operating with a local gateway. This is essentially the "PBX" problem. 2) Stationary SIP phones having known locations operating with a gateway(s) from a single operator with gateways in the PSAP regions in which phones are located. This might be viewed as the "CLEC" problem. 3) Stationary or low-mobility phones sparsely distributed across a relatively large geographical areas and operating with dynamically selected gateways from a single operator or coalition of operators. This might be labeled the "Vonage" problem, although we probably shouldn't call it that in the draft. 4) Mobile SIP phones operating with a fixed (personal or enterprise) gateway. This might be labeled the "dynamicsoft" problem as it describes my office -- for example, we have a field office in KC with a Texas phone number served by a gateway in Plano. Of course, we probably don't want to use this name for the problem in the draft. 5) Mobile SIP phones operating with a personal gateway. This appears to be a degenerate case of the #4, or did I miss something? To Do items: 1) Gonzalo: Please add myself, Mary, and Tom to the sip-emergency list and SIPPING design team. 2) Mary and Tom: Re-read Henning's draft and begin scenarios draft. 3) All of us: be thinking about how to address the scenarios, and give consideration to internationalization issues. 4) Henning: Adapt requirements draft to consider scenarios draft and likely-to-emerge practices draft. 5) Tom and Mary: Dig out references on existing PSAP functions and routing models 6) Henning: Follow-up with Nate Wilcox from Vermont 911 center Thoughts on proposed "practices" draft. 1) Should document what can be down now, with existing protocols. 2) Should document limitations of existing approaches. For example, in scenario 5, 911 services aren't going to work right. 3) Should NOT identify extensions to protocols. 4) May identify helpful practices outside of pure SIP, such as providing DID numbers for emergency call centers and databases correlating emergency call centers with geoloc. -- Dean _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 00:33:27 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 AAA26494 for ; Fri, 4 Apr 2003 00:33:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h345a4c01753 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 00:36: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 h345a3K01750 for ; Fri, 4 Apr 2003 00:36: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 AAA26471 for ; Fri, 4 Apr 2003 00:32:55 -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 h345a2K01741 for ; Fri, 4 Apr 2003 00: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 h345ZiK01709 for ; Fri, 4 Apr 2003 00:35:44 -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 AAA26463 for ; Fri, 4 Apr 2003 00:32:36 -0500 (EST) Received: from cs.columbia.edu (dhcp64-134-126-202.sjcc.sjc.wayport.net [64.134.126.202]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h345Z2JV025281 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Apr 2003 00:35:03 -0500 (EST) Message-ID: <3E8D18CA.6010207@cs.columbia.edu> Date: Fri, 04 Apr 2003 00:31:54 -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: Jonathan Rosenberg CC: Emergency References: <004901c2f951$09038cd0$ee036e3f@txdwillis> <3E8B7114.6040607@cs.columbia.edu> <3E8B9D71.9000406@dynamicsoft.com> In-Reply-To: <3E8B9D71.9000406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Re: Report on sipemergency call 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 is great information. Just to be sure I understand, Intrado is > doing two separate translations? One for a translation of the civil > address to lat/long, done at the time of provisioning of the civil > address, and the other is the translation of the lat/long into a PSAP > identity, done at call setup time? Its not clear to me why both > translations cannot be done at the same time, at provisioning time. They probably could, but the geocoding (civil-to-geo) is presumably much more stable than the assignment of areas to PSAPs, except maybe after California drifts off into the Pacific. > > Is there a site which maintains a list of providers similar to Intrado? Not that I know of. http://www.nena9-1-1.org/Buyers%20Guide/index.htm is the closest I know of, but it doesn't seem to have that category. See also http://www.nena9-1-1.org/PSAPs/index.htm > > Thanks, > Jonathan R. > > Henning Schulzrinne wrote: > >> Dean, thanks for the summary. >> >> As it happened, I had a breakfast conversation with Vonage an hour >> after the call, discussing their "911" implementation. They are not >> calling it that, since it's only an approximation, not the real thing. >> >> From my discussion, their implementation works as follows, >> implementing one of the stop-gap implementations that I described >> during the talk: >> >> - Customer can enter their location (street address) into a web form. >> >> - Customer gets reminder email once a month, as in "are you still >> living there"? Also, the system detects whether the subnet address of >> the phone has changed, indicating a likely change in physical address >> rather than just a new DHCP lease. >> >> - Address gets geo-coded (via a database maintained by Intrado, but >> other companies offer similar services) into longitude/latitude. >> >> - The outbound proxy directs all SIP requests with 911 to a special >> custom-coded proxy that queries (using an Intrado-proprietary >> XML-over-HTTP protocol) the Intrado jurisdictional database. This >> query returns a 10-digit number of the PSAP handling that part of the >> country. The Vonage fellow confirmed my suspicion that this number is >> often an administrative number, but at least it's the right PSAP. The >> call is then handed to a gateway that dials that number. >> >> - This approach has known limitations: >> . requires an agreement with Intrado (they are set up to serve ILECs >> and CLECs, not necessarily a dynamicsoft-sized business). >> . the calling party number is either the gateway or the caller, >> neither of which is likely to be mappable to anything approaching a >> useful street address. >> . the manual address entry is probably only workable with mobility >> measured in months, not "employee takes phone home after work" or >> "person has multiple devices located in different places" cases. The >> latter case may be solvable, but things start to get a bit more >> complicated from a user perspective. >> >> Apparently, Intrado is pretty much the only vendor with nationwide >> coverage. Other, smaller vendors cover parts of the country. >> >> They are starting to roll this out in the next month or so. This is a >> first step, offering "basic" rather than "enhanced" 911 service. >> >> On average, each US household places about 1 911 call per year, so the >> call volume is pretty modest, from a scaling perspective. >> >> I mentioned the on-going IETF efforts. The Vonage fellow was very >> interested in contributing to the discussion. I told him that I would >> mention this to the group. >> >> Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 00:43:25 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 AAA26581 for ; Fri, 4 Apr 2003 00:43:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h345k2x02853 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 00:46: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 h345k1K02850 for ; Fri, 4 Apr 2003 00:46: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 AAA26578 for ; Fri, 4 Apr 2003 00:42:53 -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 h345k0K02841 for ; Fri, 4 Apr 2003 00:46: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 h345jpK02823 for ; Fri, 4 Apr 2003 00:45:51 -0500 Received: from jalapeno.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26575 for ; Fri, 4 Apr 2003 00:42:33 -0500 (EST) Received: from cs.columbia.edu (dhcp64-134-126-202.sjcc.sjc.wayport.net [64.134.126.202]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h345j1vP024408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Apr 2003 00:45:02 -0500 (EST) Message-ID: <3E8D1B20.4050606@cs.columbia.edu> Date: Fri, 04 Apr 2003 00:41:52 -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: Jonathan Rosenberg CC: Emergency References: <004901c2f951$09038cd0$ee036e3f@txdwillis> <3E8B5F57.4030007@dynamicsoft.com> <3E8B7338.803@cs.columbia.edu> <3E8BB7A7.9090603@dynamicsoft.com> In-Reply-To: <3E8BB7A7.9090603@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Re: Report on sipemergency call 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 mean, making sure that resources are available, whatever they may be, > for completing a 911 call. I have heard (again, just what I've heard) > that a 5E will hang up an existing non-emergency call if it is in an > all-circuits busy condition when it receives a 911 call. This would seem > to relate to the ieprep stuff, I suppose. Never heard that mentioned, including the relevant Bellcore document. > > -Jonathan R. > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 08:42: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 IAA21681 for ; Fri, 4 Apr 2003 08:42:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Dj2I16678 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 08: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 h34Dj2K16675 for ; Fri, 4 Apr 2003 08: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 IAA21674 for ; Fri, 4 Apr 2003 08:41: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 h34Dj0K16663 for ; Fri, 4 Apr 2003 08:45: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 h34DhTK16561 for ; Fri, 4 Apr 2003 08:43:29 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21608 for ; Fri, 4 Apr 2003 08:40:13 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA15524; Fri, 4 Apr 2003 08:42:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18234; Fri, 4 Apr 2003 08:42:42 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <2BDH5RZT>; Fri, 4 Apr 2003 08:42:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B600C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Emergency Subject: RE: [Sipping-emergency] Re: Report on sipemergency call Date: Fri, 4 Apr 2003 08:42:40 -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 believe this is not true. This would be preemption and I don't believe preemption occurs even in all-circuits-busy. The only preemption is in the "we don't talk about it" national emergency stuff that is alternately denied and quietly admitted to. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, April 04, 2003 12:42 AM > To: Jonathan Rosenberg > Cc: Emergency > Subject: [Sipping-emergency] Re: Report on sipemergency call > > > > I mean, making sure that resources are available, whatever > they may be, > > for completing a 911 call. I have heard (again, just what > I've heard) > > that a 5E will hang up an existing non-emergency call if it > is in an > > all-circuits busy condition when it receives a 911 call. > This would seem > > to relate to the ieprep stuff, I suppose. > > Never heard that mentioned, including the relevant Bellcore document. > > > > > -Jonathan R. > > > > _______________________________________________ > 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 Fri Apr 4 09:33:32 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 JAA23192 for ; Fri, 4 Apr 2003 09:33:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34EaIA19904 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 09:36:18 -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 h34EaIK19901 for ; Fri, 4 Apr 2003 09:36:18 -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 JAA23175 for ; Fri, 4 Apr 2003 09:33:01 -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 h34EaHK19893 for ; Fri, 4 Apr 2003 09:36:17 -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 h34EZUK19819 for ; Fri, 4 Apr 2003 09:35:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23156 for ; Fri, 4 Apr 2003 09:32:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h34EYfBd011102; Fri, 4 Apr 2003 09:34:41 -0500 (EST) Message-ID: <3E8D97FD.5000808@dynamicsoft.com> Date: Fri, 04 Apr 2003 09:34:37 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Emergency References: <004901c2f951$09038cd0$ee036e3f@txdwillis> <3E8B5F57.4030007@dynamicsoft.com> <3E8B7338.803@cs.columbia.edu> <3E8BB7A7.9090603@dynamicsoft.com> <3E8D1B20.4050606@cs.columbia.edu> In-Reply-To: <3E8D1B20.4050606@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Re: Report on sipemergency call 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 OK, then I am just confused. Apologies. -Jonathan R. Henning Schulzrinne wrote: >> I mean, making sure that resources are available, whatever they may >> be, for completing a 911 call. I have heard (again, just what I've >> heard) that a 5E will hang up an existing non-emergency call if it is >> in an all-circuits busy condition when it receives a 911 call. This >> would seem to relate to the ieprep stuff, I suppose. > > > Never heard that mentioned, including the relevant Bellcore document. > >> >> -Jonathan R. >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 11:37:13 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 LAA28677 for ; Fri, 4 Apr 2003 11:37:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Ge3D30137 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 11: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 h34Ge3830134 for ; Fri, 4 Apr 2003 11: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 LAA28636 for ; Fri, 4 Apr 2003 11:36:42 -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 h34Ge2830126 for ; Fri, 4 Apr 2003 11:40: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 h34GdM830075 for ; Fri, 4 Apr 2003 11:39: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 LAA28606 for ; Fri, 4 Apr 2003 11:36:01 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 04 Apr 2003 08:38:48 -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 IAA20408 for ; Fri, 4 Apr 2003 08:38:30 -0800 (PST) Message-Id: <4.3.2.7.2.20030404103622.05571f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Apr 2003 10:38:52 -0600 To: sipping-emergency@ietf.org From: "James M. Polk" Subject: Re: [Sipping-emergency] [Fwd: Report on sipemergency call] In-Reply-To: <3E8C94C2.9090706@nortelnetworks.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 03:08 PM 4/3/2003 -0500, Tom Taylor wrote: >Apologies for the duplication. I've forwarded Dean's minutes to the complete >sipping-emergency list so James can see where I'm coming from in doing the >scenarios >document. There was a bit of discussion following these minutes, so you >may want to >consult the archives. Well then.... I guess I have to ask "what call"? I didn't see anything on this list announcing such an event - so how are people on this limited attendance list supposed to learn about them in order to attend.... >Given the scheduling confusion, the call proceeded with myself, Mary Barnes, >Tom Taylor, and Henning Schulzrinne in attendance. Sorry folks -- too many >irons in the fire, not enough wranglers to hold the cows down. cheers, James ************************************* "The road to destruction is well traveled and crowded, if you choose to get on that road, destruction will hit you head on" _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 15:31: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 PAA07281 for ; Fri, 4 Apr 2003 15:31:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34KY9m16233 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 15:34:09 -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 h34KY9816230 for ; Fri, 4 Apr 2003 15:34:09 -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 PAA07267 for ; Fri, 4 Apr 2003 15:30: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 h34KY8816222 for ; Fri, 4 Apr 2003 15:34:08 -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 h34KXN816153 for ; Fri, 4 Apr 2003 15:33:23 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07248 for ; Fri, 4 Apr 2003 15:29:58 -0500 (EST) Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h34KVNOg017639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Apr 2003 14:32:20 -0600 From: "Dean Willis" To: "'James M. Polk'" , Subject: RE: [Sipping-emergency] [Fwd: Report on sipemergency call] Date: Fri, 4 Apr 2003 14:31:06 -0600 Message-ID: <001201c2fae9$3fff5fe0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <4.3.2.7.2.20030404103622.05571f00@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h34KXN816154 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 > Well then.... I guess I have to ask "what call"? I didn't see > anything on > this list announcing such an event - so how are people on > this limited > attendance list supposed to learn about them in order to attend.... The call I put together to find out what the heck was going on -- a "limited invitation please explain this to the dense administrative guy who doesn't understand why we haven't made more progress before we go public" kind of call. Or, as Douglas Adams wrote "Don't Panic!" Actually, I was interested in 911 type services -- I think we're starting to get a good handle on the MLPP and IEPREP stuff. -- Dean _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 16:39:19 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 QAA09075 for ; Fri, 4 Apr 2003 16:39:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34LgE321763 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 16:42:14 -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 h34LgE821760 for ; Fri, 4 Apr 2003 16:42:14 -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 QAA09068 for ; Fri, 4 Apr 2003 16:38: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 h34LgC821750 for ; Fri, 4 Apr 2003 16:42:12 -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 h34Lfe821689 for ; Fri, 4 Apr 2003 16:41:40 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09049 for ; Fri, 4 Apr 2003 16:38:13 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34Lefv25463 for ; Fri, 4 Apr 2003 15:40:41 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 15:40:42 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABC3C@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sipping-emergency@ietf.org'" Date: Fri, 4 Apr 2003 15:40:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAF2.D5F6A158" Subject: [Sipping-emergency] FW: Connection Hold (was RE: Report on sipemergency call Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FAF2.D5F6A158 Content-Type: text/plain; charset="iso-8859-1" This just bounced (I don't know if Henning's originally post made it to the list either...) -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Friday, April 04, 2003 3:37 PM To: 'Henning Schulzrinne' Cc: sip-emergency@ietf.org Subject: Connection Hold (was RE: Report on sipemergency call Henning, By "punting" are you proposing to remove some of the text from your requirement S2 (i.e the "MAY make it more difficult to disconnect")? I fully agree that this would likely be solved by an end-system as described in S2. However, I think since this topic gets brought up every time SIP and emergency calls have been discussed (at least the discussions I've heard over the past 2+ years). [Just as the early media continues on and on, I can see this one following a similar path unless we address it upfront.] I think one reason debate of this topic seems to keep recurring is that it appears to be an easy target highlighting that a SIP network can't meet the expectations that some folks have in terms of equivalent functionality that they feel they have in the PSTN. Just playing devil's advocate, one could suggest that the only reason the functionality is optional in today's networks is that the value it brought wasn't worth the deployment impact of ensuring that all the network components in the PSTN could support it. And, following on this, the argument might be that since we're building SIP from scratch, why can't we make sure it gets considered and engineered in from the beginning? I think what we need to do is understand why this optional functionality was considered desireable (i.e. why was it an underlying requirement) and resolve that either the condition in the PSTN under which this functionality was desireable doesn't apply to SIP or address what the fundamental requirement is in terms of SIP. I think you've addressed the equivalent implied functional requirement in terms of SIP. But, I think it's worth considering why they even had that requirement in the PSTN and if it's even still needed in SIP. In terms of PSTN emergency calls, this functionality was highly desireable because that physical phone line is the only communication path and potential means of identifying the person making the call. However, we all know that SIP is different because you have multiple methods of communication and of course this is stated up front in Henning's current requirements document and clearly stated upfront in section 2, so I'm not proposing any new requirements. I agree for the audience on this list that the requirements are fine, but perhaps the requirements document needs to be absolutely blunt that there may appear to be equivalent functionality that isn't provided by these requirements, however, here's some examples of such things and explicitly explain why they don't map to a hard and fast requirement for SIP. So, perhaps what I'm proposing either expanding section 2 with a bit more background or an appendix for now that gives the background on this and states why this is only a MAY requirement (i.e the SIP paradigm provides additional information via other means such that the calling voice line is not the only means for getting information about the caller so it's not deemed imperative that the "connection" remains active, although one could enforce this at an intelligent endpoint.) Mary. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, April 03, 2003 5:59 PM To: Barnes, Mary [NGC:B602:EXCH] Cc: sip-emergency@ietf.org Subject: Re: Report on sipemergency call From some of my notes (sorry, original source lost). In any event, doesn't contradict the earlier discussion, just probably indicates that this is a requirement we can punt on for now. (In any event, I don't see how this can be anything but an end-system feature. Knowing that a call is an emergency call is crucial to implementing any such end system services, so that's why the requirements document calls this out.) Reverse reachability is much more important, in my opinion. The full document (ANSI T1.628-2001) states: ------------------------------- 4.1.4 E9-1-1 Call Hold E9-1-1 Call hold is an optional network feature provided to a PSAP which prevents a caller from disconnecting an ESC. Capabilities needed for supporting E9-1-1 Call Hold are described in Clauses 4 and 5. However, there is no DSS1 or SS7 support for this capability at this time. ------------------------------- Both documents clearly state that CALL HOLD can not be universally supported, in fact it is clearly stated that a network reconnect - i.e. call back will be attempted only - this is because the network may not have the actual callers station ID, but some other number, reflecting maybe the billing number or a location based "equivalent number" in the case of larger organizations. The fact that SS7 does not support this provision will effect the ability of call hold via Tandem Offices as is the case with most E911 offerings. ------_=_NextPart_001_01C2FAF2.D5F6A158 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Connection Hold (was RE: Report on sipemergency call

This just bounced (I don't know if Henning's = originally post made it to the list either...)

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH]
Sent: Friday, April 04, 2003 3:37 PM
To: 'Henning Schulzrinne'
Cc: sip-emergency@ietf.org
Subject: Connection Hold (was RE: Report on = sipemergency call


Henning,

By "punting" are you proposing to remove = some of the text from your requirement S2 (i.e the "MAY make it = more difficult to disconnect")?   

I fully agree that this would likely be solved by an = end-system as described in S2.  However, I think since this topic = gets brought up every time SIP and emergency calls have been discussed = (at least the discussions I've heard over the past 2+ years). [Just as = the early media continues on and on, I can see this one following a = similar path unless we address it upfront.] 

I think one reason debate of this topic seems to keep = recurring is that it appears to be an easy target highlighting that a = SIP network can't meet the expectations that some folks have in terms = of equivalent functionality that they feel they have in the PSTN.  = Just playing devil's advocate, one could suggest that the only reason = the functionality is optional in today's networks is that the value it = brought wasn't worth the deployment impact of ensuring that all the = network components in the PSTN could support it.  And, following = on this, the argument might be that since we're building SIP from = scratch, why can't we make sure it gets considered and engineered in = from the beginning?

I think what we need to do is understand why this = optional functionality was considered desireable (i.e. why was it an = underlying requirement) and resolve that either the condition in the = PSTN under which this functionality was desireable doesn't apply to SIP = or address what the fundamental requirement is in terms of SIP.  I = think you've addressed the equivalent implied functional requirement in = terms of SIP.  But, I think it's worth considering why they even = had that requirement in the PSTN and if it's even still needed in = SIP. 

In terms of PSTN emergency calls, this functionality = was highly desireable because that physical phone line is the only = communication path and potential means of identifying the person making = the call.  However, we all know that SIP is different because you = have multiple methods of communication and of course this is stated up = front in Henning's current requirements document and clearly stated = upfront in section 2, so I'm not proposing any new requirements. =

I agree for the audience on this list that the = requirements are fine, but perhaps the requirements document needs to = be absolutely blunt that there may appear to be equivalent = functionality that isn't provided by these requirements, however, = here's some examples of such things and explicitly explain why they = don't map to a hard and fast requirement for SIP.   So, = perhaps what I'm proposing either expanding section 2 with a bit more = background or an appendix for now that gives the background on this and = states why this is only a MAY requirement (i.e the SIP paradigm = provides additional information via other means such that the calling = voice line is not the only means for getting information about the = caller so it's not deemed imperative that the "connection" = remains active, although one could enforce this at an intelligent = endpoint.) 

Mary.

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Thursday, April 03, 2003 5:59 PM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: sip-emergency@ietf.org
Subject: Re: Report on sipemergency call


 From some of my notes (sorry, original source = lost). In any event,
doesn't contradict the earlier discussion, just = probably indicates that
this is a requirement we can punt on for now. (In = any event, I don't see
how this can be anything but an end-system feature. = Knowing that a call
is an emergency call is crucial to implementing any = such end system
services, so that's why the requirements document = calls this out.)

Reverse reachability is much more important, in my = opinion.


The full document (ANSI T1.628-2001) states:

-------------------------------
4.1.4   E9-1-1 Call Hold

E9-1-1 Call hold is an optional network feature = provided to a PSAP which
prevents a caller from disconnecting an ESC.  = Capabilities needed for
supporting E9-1-1 Call Hold are described in Clauses = 4 and 5.  However,
there is no DSS1 or SS7 support for this capability = at this time.
-------------------------------

Both documents clearly state that CALL HOLD can not = be universally
supported, in fact it is clearly stated that a = network reconnect - i.e.
call back will be attempted only - this is because = the network may not
have the actual callers station ID, but some other = number, reflecting
maybe the billing number or a location based = "equivalent number" in the
case of larger organizations.  The fact that = SS7 does not support this
provision will effect the ability of call hold via = Tandem Offices as is
the case with most E911 offerings.


------_=_NextPart_001_01C2FAF2.D5F6A158-- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 17:06:06 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 RAA09971 for ; Fri, 4 Apr 2003 17:06:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34M92J24565 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 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 h34M92824562 for ; Fri, 4 Apr 2003 17:09: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 RAA09952 for ; Fri, 4 Apr 2003 17:05:34 -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 h34M90824544 for ; Fri, 4 Apr 2003 17:09: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 h34M81824513 for ; Fri, 4 Apr 2003 17:08:01 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09906 for ; Fri, 4 Apr 2003 17:04:33 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h34M73hr029694 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Apr 2003 17:07:03 -0500 (EST) Message-ID: <3E8E020A.8020607@cs.columbia.edu> Date: Fri, 04 Apr 2003 17:07:06 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 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] Call hold 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 Mary Barnes wrote: > Henning, > > By "punting" are you proposing to remove some of the text from your > requirement S2 (i.e the "MAY make it more difficult to disconnect")? I'm not sure it matters. It doesn't seem necessary for a minimal implementation of emergency calling that does no more than basic 911 in the US/Canada, but that shouldn't keep us from collecting requirements that allow services that improve upon the user experience. That's why I labeled it a MAY rather than a SHOULD or MUST requirement. Since our current effort is on a minimal feature set and since we seem to agree that this is probably an end system implementation issue rather than a protocol requirement as long as the end system can reliably detect that an emergency call is in progress, we may be able to defer this and move on to the more crucial service aspects. > > I fully agree that this would likely be solved by an end-system as described > in S2. However, I think since this topic gets brought up every time SIP and > emergency calls have been discussed (at least the discussions I've heard > over the past 2+ years). [Just as the early media continues on and on, I can > see this one following a similar path unless we address it upfront.] I think this would be more appropriately addressed in the requirements doc. If that's ok, I will add some explanatory text to that section reflecting our discussion. Btw, I dug up the ANSI reference and found another interesting document that directly bears on this topic: http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=577743 http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=557653 Can anybody here get at these documents through some kind of liaison relationship? I don't have a spare $238 to buy these documents... http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=557182 is also relevant. > > I think one reason debate of this topic seems to keep recurring is that it > appears to be an easy target highlighting that a SIP network can't meet the > expectations that some folks have in terms of equivalent functionality that > they feel they have in the PSTN. Just playing devil's advocate, one could > suggest that the only reason the functionality is optional in today's > networks is that the value it brought wasn't worth the deployment impact of > ensuring that all the network components in the PSTN could support it. And, > following on this, the argument might be that since we're building SIP from > scratch, why can't we make sure it gets considered and engineered in from > the beginning? Given that support is purely predicated on end system behavior, there seems little harm in suggesting that implementors take this into consideration. My perception is that the IETF has generally tried to stay away from "user interface" descriptions, but I won't complain > > I think what we need to do is understand why this optional functionality was > considered desireable (i.e. why was it an underlying requirement) and > resolve that either the condition in the PSTN under which this functionality > was desireable doesn't apply to SIP or address what the fundamental > requirement is in terms of SIP. I think you've addressed the equivalent > implied functional requirement in terms of SIP. But, I think it's worth > considering why they even had that requirement in the PSTN and if it's even > still needed in SIP. > In terms of PSTN emergency calls, this functionality was highly desireable > because that physical phone line is the only communication path and > potential means of identifying the person making the call. However, we all > know that SIP is different because you have multiple methods of > communication and of course this is stated up front in Henning's current > requirements document and clearly stated upfront in section 2, so I'm not > proposing any new requirements. Also, I think this was motivated since it was difficult to call back the original caller. I suspect that in most cases, callers don't make a different call, but simply hang up. In that case, ringback is far more useful to get the emergency caller back on the line to ascertain that the emergency has indeed passed or was a false alarm (or, as seems common, that the emergency call button was pressed while the phone was in somebody's back pocket). > > I agree for the audience on this list that the requirements are fine, but > perhaps the requirements document needs to be absolutely blunt that there > may appear to be equivalent functionality that isn't provided by these > requirements, however, here's some examples of such things and explicitly > explain why they don't map to a hard and fast requirement for SIP. So, > perhaps what I'm proposing either expanding section 2 with a bit more > background or an appendix for now that gives the background on this and > states why this is only a MAY requirement (i.e the SIP paradigm provides > additional information via other means such that the calling voice line is > not the only means for getting information about the caller so it's not > deemed imperative that the "connection" remains active, although one could > enforce this at an intelligent endpoint.) I will try to add some motivating text. > > Mary. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, April 03, 2003 5:59 PM > To: Barnes, Mary [NGC:B602:EXCH] > Cc: sip-emergency@ietf.org > Subject: Re: Report on sipemergency call > > > From some of my notes (sorry, original source lost). In any event, doesn't contradict the earlier discussion, just probably indicates that this is a requirement we can punt on for now. (In any event, I don't see how this can be anything but an end-system feature. Knowing that a call is an emergency call is crucial to implementing any such end system services, so that's why the requirements document calls this out.) > > Reverse reachability is much more important, in my opinion. > > > The full document (ANSI T1.628-2001) states: > > ------------------------------- > 4.1.4 E9-1-1 Call Hold > > E9-1-1 Call hold is an optional network feature provided to a PSAP which > prevents a caller from disconnecting an ESC. Capabilities needed for > supporting E9-1-1 Call Hold are described in Clauses 4 and 5. However, > there is no DSS1 or SS7 support for this capability at this time. > ------------------------------- > > Both documents clearly state that CALL HOLD can not be universally > supported, in fact it is clearly stated that a network reconnect - i.e. > call back will be attempted only - this is because the network may not > have the actual callers station ID, but some other number, reflecting > maybe the billing number or a location based "equivalent number" in the > case of larger organizations. The fact that SS7 does not support this > provision will effect the ability of call hold via Tandem Offices as is > the case with most E911 offerings. > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Fri Apr 4 17:58: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 RAA11156 for ; Fri, 4 Apr 2003 17:58:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34N0xC27874 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 18:00: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 h34N0x827871 for ; Fri, 4 Apr 2003 18:00:59 -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 RAA11132 for ; Fri, 4 Apr 2003 17:57: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 h34N0v827861 for ; Fri, 4 Apr 2003 18:00:57 -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 h34MuN827603 for ; Fri, 4 Apr 2003 17:56:23 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11081 for ; Fri, 4 Apr 2003 17:52:54 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34MtHv09503; Fri, 4 Apr 2003 16:55:17 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 16:55:18 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABC40@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Henning Schulzrinne'" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Call hold Date: Fri, 4 Apr 2003 16:55:17 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) 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, I can access and download the referenced documents (but can't share them; I can't even share them with Tom, who must retrieve them himself). However, I took a look and this is the detailed information that is described at a high level for Nortel's product (per that other URL I had sent) around the SS7 support for the Connection Hold. (For ISDN, it's not possible to prevent the disconnect, so that's why they need the dialback). The first line of the addendum is the deletion of that text in section 6.1.4 referenced in your initial email below. Are you certain that was from TR.628-2001 (and not 2000) as the one document is the addendum to TR.628-2000 and I couldn't find a TR.628-2001? The addendum also has all the TCAP messaging for the interface to the SRDB. Mary. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, April 04, 2003 4:07 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] Call hold Mary Barnes wrote: > Henning, > > By "punting" are you proposing to remove some of the text from your > requirement S2 (i.e the "MAY make it more difficult to disconnect")? I'm not sure it matters. It doesn't seem necessary for a minimal implementation of emergency calling that does no more than basic 911 in the US/Canada, but that shouldn't keep us from collecting requirements that allow services that improve upon the user experience. That's why I labeled it a MAY rather than a SHOULD or MUST requirement. Since our current effort is on a minimal feature set and since we seem to agree that this is probably an end system implementation issue rather than a protocol requirement as long as the end system can reliably detect that an emergency call is in progress, we may be able to defer this and move on to the more crucial service aspects. > > I fully agree that this would likely be solved by an end-system as described > in S2. However, I think since this topic gets brought up every time SIP and > emergency calls have been discussed (at least the discussions I've heard > over the past 2+ years). [Just as the early media continues on and on, I can > see this one following a similar path unless we address it upfront.] I think this would be more appropriately addressed in the requirements doc. If that's ok, I will add some explanatory text to that section reflecting our discussion. Btw, I dug up the ANSI reference and found another interesting document that directly bears on this topic: http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=577743 http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=557653 Can anybody here get at these documents through some kind of liaison relationship? I don't have a spare $238 to buy these documents... http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=557182 is also relevant. > > I think one reason debate of this topic seems to keep recurring is that it > appears to be an easy target highlighting that a SIP network can't meet the > expectations that some folks have in terms of equivalent functionality that > they feel they have in the PSTN. Just playing devil's advocate, one could > suggest that the only reason the functionality is optional in today's > networks is that the value it brought wasn't worth the deployment impact of > ensuring that all the network components in the PSTN could support it. And, > following on this, the argument might be that since we're building SIP from > scratch, why can't we make sure it gets considered and engineered in from > the beginning? Given that support is purely predicated on end system behavior, there seems little harm in suggesting that implementors take this into consideration. My perception is that the IETF has generally tried to stay away from "user interface" descriptions, but I won't complain > > I think what we need to do is understand why this optional functionality was > considered desireable (i.e. why was it an underlying requirement) and > resolve that either the condition in the PSTN under which this functionality > was desireable doesn't apply to SIP or address what the fundamental > requirement is in terms of SIP. I think you've addressed the equivalent > implied functional requirement in terms of SIP. But, I think it's worth > considering why they even had that requirement in the PSTN and if it's even > still needed in SIP. > In terms of PSTN emergency calls, this functionality was highly desireable > because that physical phone line is the only communication path and > potential means of identifying the person making the call. However, we all > know that SIP is different because you have multiple methods of > communication and of course this is stated up front in Henning's current > requirements document and clearly stated upfront in section 2, so I'm not > proposing any new requirements. Also, I think this was motivated since it was difficult to call back the original caller. I suspect that in most cases, callers don't make a different call, but simply hang up. In that case, ringback is far more useful to get the emergency caller back on the line to ascertain that the emergency has indeed passed or was a false alarm (or, as seems common, that the emergency call button was pressed while the phone was in somebody's back pocket). > > I agree for the audience on this list that the requirements are fine, but > perhaps the requirements document needs to be absolutely blunt that there > may appear to be equivalent functionality that isn't provided by these > requirements, however, here's some examples of such things and explicitly > explain why they don't map to a hard and fast requirement for SIP. So, > perhaps what I'm proposing either expanding section 2 with a bit more > background or an appendix for now that gives the background on this and > states why this is only a MAY requirement (i.e the SIP paradigm provides > additional information via other means such that the calling voice line is > not the only means for getting information about the caller so it's not > deemed imperative that the "connection" remains active, although one could > enforce this at an intelligent endpoint.) I will try to add some motivating text. > > Mary. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, April 03, 2003 5:59 PM > To: Barnes, Mary [NGC:B602:EXCH] > Cc: sip-emergency@ietf.org > Subject: Re: Report on sipemergency call > > > From some of my notes (sorry, original source lost). In any event, doesn't contradict the earlier discussion, just probably indicates that this is a requirement we can punt on for now. (In any event, I don't see how this can be anything but an end-system feature. Knowing that a call is an emergency call is crucial to implementing any such end system services, so that's why the requirements document calls this out.) > > Reverse reachability is much more important, in my opinion. > > > The full document (ANSI T1.628-2001) states: > > ------------------------------- > 4.1.4 E9-1-1 Call Hold > > E9-1-1 Call hold is an optional network feature provided to a PSAP which > prevents a caller from disconnecting an ESC. Capabilities needed for > supporting E9-1-1 Call Hold are described in Clauses 4 and 5. However, > there is no DSS1 or SS7 support for this capability at this time. > ------------------------------- > > Both documents clearly state that CALL HOLD can not be universally > supported, in fact it is clearly stated that a network reconnect - i.e. > call back will be attempted only - this is because the network may not > have the actual callers station ID, but some other number, reflecting > maybe the billing number or a location based "equivalent number" in the > case of larger organizations. The fact that SS7 does not support this > provision will effect the ability of call hold via Tandem Offices as is > the case with most E911 offerings. > _______________________________________________ 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 Fri Apr 4 17:58: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 RAA11192 for ; Fri, 4 Apr 2003 17:58:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34N14g27964 for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 18: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 h34N14827960 for ; Fri, 4 Apr 2003 18: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 RAA11140 for ; Fri, 4 Apr 2003 17:57:35 -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 h34N12827940 for ; Fri, 4 Apr 2003 18: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 h34N0C827817 for ; Fri, 4 Apr 2003 18:00:12 -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 RAA11119 for ; Fri, 4 Apr 2003 17:56:43 -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.8p1/8.12.8) with ESMTP id h34Mx8Hg019034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Apr 2003 17:59:13 -0500 (EST) Message-ID: <3E8E0E40.4050907@cs.columbia.edu> Date: Fri, 04 Apr 2003 17:59:12 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes CC: sipping-emergency@ietf.org Subject: Re: [Sipping-emergency] Call hold References: <1B54FA3A2709D51195C800508BF9386A09DABC40@zrc2c000.us.nortel.com> In-Reply-To: <1B54FA3A2709D51195C800508BF9386A09DABC40@zrc2c000.us.nortel.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 Mary Barnes wrote: > Henning, > > took a look and this is the detailed information that is described at a high > level for Nortel's product (per that other URL I had sent) around the SS7 > support for the Connection Hold. (For ISDN, it's not possible to prevent the > disconnect, so that's why they need the dialback). The first line of the > addendum is the deletion of that text in section 6.1.4 referenced in your > initial email below. Are you certain that was from TR.628-2001 (and not > 2000) as the one document is the addendum to TR.628-2000 and I couldn't find > a TR.628-2001? No, I suspect that whoever sent it to me introduced a typo, given the two documents and their different years. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Sun Apr 6 10:01: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 KAA27687 for ; Sun, 6 Apr 2003 10:01:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h36E52w11709 for sipping-emergency-archive@odin.ietf.org; Sun, 6 Apr 2003 10:05:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36E52811706 for ; Sun, 6 Apr 2003 10:05:02 -0400 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 KAA27671 for ; Sun, 6 Apr 2003 10:00:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36E51811698 for ; Sun, 6 Apr 2003 10:05:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36E4P811671 for ; Sun, 6 Apr 2003 10:04:25 -0400 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 KAA27658 for ; Sun, 6 Apr 2003 10:00:08 -0400 (EDT) Received: from cs.columbia.edu (164.indianapolis-08rh15rt.in.dial-access.att.net[12.84.238.164]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003040614023911100r18kre>; Sun, 6 Apr 2003 14:02:40 +0000 Message-ID: <3E8CCCA0.30209@cs.columbia.edu> Date: Thu, 03 Apr 2003 19:06:56 -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: sipping-emergency@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] Call hold 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 some of my notes (sorry, original source lost). In any event, doesn't contradict the earlier discussion, just probably indicates that this is a requirement we can punt on for now. (In any event, I don't see how this can be anything but an end-system feature. Knowing that a call is an emergency call is crucial to implementing any such end system services, so that's why the requirements document calls this out.) Reverse reachability is much more important, in my opinion. The full document (ANSI T1.628-2001) states: ------------------------------- 4.1.4 E9-1-1 Call Hold E9-1-1 Call hold is an optional network feature provided to a PSAP which prevents a caller from disconnecting an ESC. Capabilities needed for supporting E9-1-1 Call Hold are described in Clauses 4 and 5. However, there is no DSS1 or SS7 support for this capability at this time. ------------------------------- Both documents clearly state that CALL HOLD can not be universally supported, in fact it is clearly stated that a network reconnect - i.e. call back will be attempted only - this is because the network may not have the actual callers station ID, but some other number, reflecting maybe the billing number or a location based "equivalent number" in the case of larger organizations. The fact that SS7 does not support this provision will effect the ability of call hold via Tandem Offices as is the case with most E911 offerings. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From mailnull@www1.ietf.org Mon Apr 7 11:40: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 LAA23965 for ; Mon, 7 Apr 2003 11:40:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37Fj2M21001 for sipping-emergency-archive@odin.ietf.org; Mon, 7 Apr 2003 11:45:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Fj2820998 for ; Mon, 7 Apr 2003 11:45:02 -0400 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 LAA23956 for ; Mon, 7 Apr 2003 11:40:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Fj1820990 for ; Mon, 7 Apr 2003 11:45:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37FiN820945 for ; Mon, 7 Apr 2003 11:44:23 -0400 Received: from jalapeno.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23924 for ; Mon, 7 Apr 2003 11:39:35 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h37Fg8vP019726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 Apr 2003 11:42:08 -0400 (EDT) Message-ID: <3E919C6B.2020306@cs.columbia.edu> Date: Mon, 07 Apr 2003 11:42:35 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: multipart/mixed; boundary="------------020402030805080005080907" Subject: [Sipping-emergency] [Fwd: Re: SR count in the US?] Sender: sipping-emergency-admin@ietf.org Errors-To: sipping-emergency-admin@ietf.org X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------020402030805080005080907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI. --------------020402030805080005080907 Content-Type: message/rfc822; name="Re: SR count in the US?" Content-Disposition: inline; filename="Re: SR count in the US?" Return-Path: Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h37Fc9O30121 for ; Mon, 7 Apr 2003 11:38:09 -0400 Received: from nenamail.nena.org (nenamail.nena.org [216.29.40.131]) by cs.columbia.edu (8.12.9/8.12.6) with ESMTP id h37Fc6J9029410 for ; Mon, 7 Apr 2003 11:38:09 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: SR count in the US? X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 7 Apr 2003 11:38:05 -0400 Message-ID: <914F76321A9B9342A16AA81682A681910C2B47@nenamail.nena.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SR count in the US? Thread-Index: AcL6/B4Fpwm8VCBtSTySohgqL5xbkwCH3/oQ From: "Roger Hixson" To: "Henning Schulzrinne" , "Migwg" X-MIME-Autoconverted: from quoted-printable to 8bit by magnum.cs.columbia.edu id h37Fc9O30121 X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Content-Transfer-Encoding: 8bit >From our NENA SWAT work, at least 410 and less than 450. Roger Hixson, ENP Technical Issues Director NENA - `The Voice of 9-1-1' 800-332-3911 rhixson@nena.org -----Original Message----- From: Henning Schulzrinne Sent: Friday, April 04, 2003 5:47 PM To: Migwg Subject: SR count in the US? Does anybody have any order-magnitude estimate as to the number of selective routers in the US (as opposed to the number of PSAPs)? Thank you. Henning --------------020402030805080005080907-- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency