RE: [Sipping-emergency] Emergency Scenarios Document
dick.rr.knight@bt.com Wed, 28 May 2003 09:10 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 FAA22628
for <sipping-emergency-archive@odin.ietf.org>;
Wed, 28 May 2003 05:10:28 -0400 (EDT)
Received: (from mailnull@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h4S9A2a19462
for sipping-emergency-archive@odin.ietf.org; Wed, 28 May 2003 05:10:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S9A2B19459
for <sipping-emergency-web-archive@optimus.ietf.org>;
Wed, 28 May 2003 05:10:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22617
for <sipping-emergency-web-archive@ietf.org>;
Wed, 28 May 2003 05:09:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 19Kwv1-0000GF-00
for sipping-emergency-web-archive@ietf.org; Wed, 28 May 2003 05:08:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
by ietf-mx with esmtp (Exim 4.12) id 19Kwv0-0000GB-00
for sipping-emergency-web-archive@ietf.org; Wed, 28 May 2003 05:08:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S9A1B19430
for <sipping-emergency-web-archive@ietf.org>; Wed, 28 May 2003 05:10:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S8PJB14719
for <sipping-emergency@optimus.ietf.org>; Wed, 28 May 2003 04:25:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21132
for <sipping-emergency@ietf.org>; Wed, 28 May 2003 04:25:16 -0400 (EDT)
From: dick.rr.knight@bt.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 19KwDk-0007ht-00
for sipping-emergency@ietf.org; Wed, 28 May 2003 04:23:40 -0400
Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt03.HC.BT.COM)
by ietf-mx with esmtp (Exim 4.12) id 19KwDk-0007hc-00
for sipping-emergency@ietf.org; Wed, 28 May 2003 04:23:40 -0400
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89)
id <LJM1CN8L>; Wed, 28 May 2003 09:24:51 +0100
Message-ID: <E0E9F9BE940EFC4186DB15A079FF315001AA5CCE@i2km35-ukdy.domain1.systemhost.net>
To: taylor@nortelnetworks.com, PMcCalmont@intrado.com
Cc: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au,
mbarnes@nortelnetworks.com, jmce@nortelnetworks.com, steve.norreys@bt.com
Subject: RE: [Sipping-emergency] Emergency Scenarios Document
Date: Wed, 28 May 2003 09:24:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <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>
With respect to the discussion on call hold, please note that there are digital switches that support "last party clear" for certain applications, including emergency calls (911, 112, 999 etc.). It is true that this MAY not be supported by ISUP, but it is supported with other SS7 user parts - notably TUP and a UK variant NUP. Regards, Dick Knight British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: 27 May 2003 17:47 To: McCalmont, Patti Cc: sipping-emergency@ietf.org; Patrick.Emery@aca.gov.au; Knight,RR,Dick,XGH4 KNIGHTRR R; Mary Barnes; James McEachern; Norreys,SE,Steve,XGH4 R Subject: Re: [Sipping-emergency] Emergency Scenarios Document I'll be replying to Henning's comments, but since this note is relatively short I'll address it first. McCalmont, Patti wrote: > Section 3.3 > > >> In the legacy network ....mapping database. > > > The term "mapping database is used a few times within the document. Is mapping > database trying to refer to a selective routing database that is used to > determine how to route the call based on the location of the caller to the PSAP? > If so, a better term would be location database or selective routing database > (term used in US/Canada. Or, is it trying to refer to the phone number to > location information, Automatic Location Identification (ALI) database, or both? > Some clarification is needed. [PTT] I'll clarify. In North American terms I'm referring to the ALI database. > > For PBX operation, an additional issue is that telephone number assignments are > under control of the private network operator. PBXs without > direct-inward-dialing (DID) introduce an additional challenge. Typically, the > calling number is used as a unique reference to identify the caller's location. > > Without CAMA or PRI connections for emergency calls, those PBX locations cannot > convey the caller's identity (even with DID). What is typically used is the > Billing Number or Main Directory number for the PBX when they don't have the > CAMA/PRI. There may need some clarification as connections required in order to > provide the DID stations or is that what was trying to be said with > "administrative arrangements"? [PTT] I seem to have gotten this wrong, as you and Henning point out. I'll have to extend the discussion. > > > A special arrangement at the switch serving the ECC allows the emergency operator > to hold open the voice path back to the caller as long as necessary, even if the > caller goes on-hook. It should be noted that this functionality is not supported > for ISDN. Thus, the operator can also ring the caller's line in this situation or > others where it might be necessary. > > Call Hold applies globally to Basic 911 and is an option for Enhanced 9-1-1 so > which type of "legacy network" is described in this section. If Enhanced 9-1-1, > then Call Hold (as stated later) is an optional feature. > > Henning wrote: I would qualify this as "In analog switches, ....". Most switches > today are effectively ISDN (or equivalent), so this feature is likely only > available to a tiny fraction of end systems. > > Most switches today are digital so I don't like the term "analog switches". It > would be better to talk about the interfaces into the switch as being analog or > digital (ISDN). [PTT] Yes, that's right. In North America, there aren't many ISDN lines, but in Europe there are. In both places, most switches are digital. > > > Section 4.3.1 > >> There is still the problem of distinguishing between voice and text emergency >> calls. If the user enters an actual emergency number, that can be the one that >> serves the user's needs. If the configuration is by DHCP or SIP registrar, it >> may be that selection of the appropriate number is based on pre-configuration >> of the SIP phone as voice or text bas > > > Henning wrote: Unless I'm really off my rocker, the number is the same for TDD > calls. See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence. > > He is correct. It's the equipment at the PSAP that detects the call as TDD > nothing in how the user dials. [PTT] That's in North America. It's different in Australia. I suppose I should modify the discussion to make it clear that the requirement is only present in some countries. > > Patti McCalmont > > _______________________________________________ Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list > Sipping-emergency@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-emergency > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency
- [Sipping-emergency] Emergency Scenarios Document Tom Taylor
- [Sipping-emergency] [Fwd: RE: Emergency Scenarios… Tom Taylor
- Re: [Sipping-emergency] Emergency Scenarios Docum… Henning Schulzrinne
- Re: [Sipping-emergency] Emergency Scenarios Docum… Henning Schulzrinne
- RE: [Sipping-emergency] Emergency Scenarios Docum… McCalmont, Patti
- Re: [Sipping-emergency] Emergency Scenarios Docum… Tom Taylor
- RE: [Sipping-emergency] Emergency Scenarios Docum… dick.rr.knight
- Re: [Sipping-emergency] Emergency Scenarios Docum… Tom Taylor