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