RE: [Sipping-emergency] Emergency Scenarios Document

"McCalmont, Patti" <PMcCalmont@intrado.com> Tue, 27 May 2003 15:56 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17990 for <sipping-emergency-archive@odin.ietf.org>; Tue, 27 May 2003 11:56:29 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RFu3X30403 for sipping-emergency-archive@odin.ietf.org; Tue, 27 May 2003 11:56:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFu2B30400 for <sipping-emergency-web-archive@optimus.ietf.org>; Tue, 27 May 2003 11:56:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17977 for <sipping-emergency-web-archive@ietf.org>; Tue, 27 May 2003 11:55:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgmQ-0005hb-00 for sipping-emergency-web-archive@ietf.org; Tue, 27 May 2003 11:54:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KgmP-0005hV-00 for sipping-emergency-web-archive@ietf.org; Tue, 27 May 2003 11:54:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFu1B30384 for <sipping-emergency-web-archive@ietf.org>; Tue, 27 May 2003 11:56:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFt5B30345 for <sipping-emergency@optimus.ietf.org>; Tue, 27 May 2003 11:55:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17959 for <sipping-emergency@ietf.org>; Tue, 27 May 2003 11:55:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KglV-0005hD-00 for sipping-emergency@ietf.org; Tue, 27 May 2003 11:53:29 -0400
Received: from [12.147.68.162] (helo=ns2.sccx.com) by ietf-mx with esmtp (Exim 4.12) id 19KglU-0005h1-00 for sipping-emergency@ietf.org; Tue, 27 May 2003 11:53:28 -0400
Received: from puma.lgmt.trdo (puma.scc911.com [10.100.5.15]) by ns2.sccx.com with ESMTP id h4RFoHRd016040 for <sipping-emergency@ietf.org>; Tue, 27 May 2003 09:50:17 -0600 (MDT)
Received: from PANTHER.lgmt.trdo (panther.lgmt.trdo) by puma.lgmt.trdo (Content Technologies SMTPRS 4.3.1) with ESMTP id <T62757313acc6f310ca3ac@puma.lgmt.trdo>; Tue, 27 May 2003 09:54:30 -0600
Received: from JAGUAR.lgmt.trdo ([172.20.150.65]) by PANTHER.lgmt.trdo with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 May 2003 09:54:30 -0600
Content-Class: urn:content-classes:message
Subject: RE: [Sipping-emergency] Emergency Scenarios Document
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 27 May 2003 10:54:29 -0500
Message-ID: <19B3D8818B23554581D1E8C65C2964392DB8B2@jaguar.scc911.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [Sipping-emergency] Emergency Scenarios Document
Thread-Index: AcMhT8Beu7iKP+VNSVCw0L7MpK9jigDE0Qgg
From: "McCalmont, Patti" <PMcCalmont@intrado.com>
To: <sipping-emergency@ietf.org>
Cc: <Patrick.Emery@aca.gov.au>, <dick.rr.knight@bt.com>, "Barnes Mary" <mbarnes@nortelnetworks.com>, "James McEachern" <jmce@nortelnetworks.com>, <steve.norreys@bt.com>
X-OriginalArrivalTime: 27 May 2003 15:54:30.0610 (UTC) FILETIME=[426C5320:01C32468]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RFt6B30347
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Id: <sipping-emergency.ietf.org>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Section 3.3

> In the legacy network ....mapping database.

The term "mapping database is used a few times within the document. Is mapping database trying to refer to a selective routing database that is used to determine how to route the call based on the location of the caller to the PSAP? If so, a better term would be location database or selective routing database (term used in US/Canada. Or, is it trying to refer to the phone number to location information, Automatic Location Identification (ALI) database, or both? Some clarification is needed.
   
      For PBX operation, an additional issue is that telephone number 
      assignments are under control of the private network operator.  PBXs 
      without direct-inward-dialing (DID) introduce an additional 
      challenge.  Typically, the calling number is used as a unique 
      reference to identify the caller's location.

Without CAMA or PRI connections for emergency calls, those PBX locations cannot convey the caller's identity (even with DID). What is typically used is the Billing Number or Main Directory number for the PBX when they don't have the CAMA/PRI. There may need some clarification as connections required in order to provide the DID stations or is that what was trying to be said with "administrative arrangements"? 


      A special arrangement at the switch serving the ECC allows the 
      emergency operator to hold open the voice path back to the caller as 
      long as necessary, even if the caller goes on-hook.  It should be 
      noted that this functionality is not supported for ISDN. Thus, the 
      operator can also ring the caller's line in this situation or others 
      where it might be necessary. 

Call Hold applies globally to Basic 911 and is an option for Enhanced 9-1-1 so which type of "legacy network" is described in this section. If Enhanced 9-1-1, then Call Hold (as stated later) is an optional feature.

	Henning wrote: I would qualify this as "In analog switches, ....". Most switches today 
	are effectively ISDN (or equivalent), so this feature is likely only 
	available to a tiny fraction of end systems.

Most switches today are digital so I don't like the term "analog switches". It would be better to talk about the interfaces into the switch as being analog or digital (ISDN).


Section 4.3.1
>       There is still the problem of distinguishing between voice and text 
>       emergency calls.  If the user enters an actual emergency number, that 
>       can be the one that serves the user's needs.  If the configuration is 
>       by DHCP or SIP registrar, it may be that selection of the appropriate 
>       number is based on pre-configuration of the SIP phone as voice or 
>       text bas

	Henning wrote: Unless I'm really off my rocker, the number is the same for TDD calls. 
	See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence.

He is correct. It's the equipment at the PSAP that detects the call as TDD nothing in how the user dials.

Patti McCalmont	

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency
_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency