Re: [Sipping-emergency] Emergency Scenarios Document
Tom Taylor <taylor@nortelnetworks.com> Fri, 13 June 2003 12: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 IAA00738
for <sipping-emergency-archive@odin.ietf.org>;
Fri, 13 Jun 2003 08:56:10 -0400 (EDT)
Received: (from mailnull@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5DCtgE07030
for sipping-emergency-archive@odin.ietf.org; Fri, 13 Jun 2003 08:55:42 -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 h5DCtfm07027
for <sipping-emergency-web-archive@optimus.ietf.org>;
Fri, 13 Jun 2003 08:55:41 -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 IAA00715
for <sipping-emergency-web-archive@ietf.org>;
Fri, 13 Jun 2003 08:55:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 19Qo3e-0004Bu-00
for sipping-emergency-web-archive@ietf.org; Fri, 13 Jun 2003 08:53:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
by ietf-mx with esmtp (Exim 4.12) id 19Qo3e-0004Bq-00
for sipping-emergency-web-archive@ietf.org; Fri, 13 Jun 2003 08:53:30 -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 h5CJC0a17864
for <sipping-emergency-web-archive@ietf.org>; Thu, 12 Jun 2003 15:12:00 -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 h5CJBcm17844
for <sipping-emergency@optimus.ietf.org>; Thu, 12 Jun 2003 15:11:38 -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 PAA24105
for <sipping-emergency@ietf.org>; Thu, 12 Jun 2003 15:11:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 19QXRw-0005Pw-00
for sipping-emergency@ietf.org; Thu, 12 Jun 2003 15:09:28 -0400
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
by ietf-mx with esmtp (Exim 4.12) id 19QXRv-0005Pr-00
for sipping-emergency@ietf.org; Thu, 12 Jun 2003 15:09:27 -0400
Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67])
by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
h5CJAeg02132; Thu, 12 Jun 2003 15:10:40 -0400 (EDT)
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 MLYH9A29; Thu, 12 Jun 2003 15:10:40 -0400
Received: from nortelnetworks.com (acart1ct.ca.nortel.com [47.129.129.69]) by
zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service
Version 5.5.2653.13) id JQNA0TF8; Thu, 12 Jun 2003 15:10:41 -0400
Message-ID: <3EE8D021.40109@nortelnetworks.com>
Date: Thu, 12 Jun 2003 15:10:25 -0400
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.4b) Gecko/20030507
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: sipping-emergency@ietf.org, Patrick.Emery@aca.gov.au,
dick.rr.knight@bt.com, "Mary Barnes" <mbarnes@nortelnetworks.com>,
"James McEachern" <jmce@nortelnetworks.com>, steve.norreys@bt.com
Subject: Re: [Sipping-emergency] Emergency Scenarios Document
References: <3ECA9992.9030002@nortelnetworks.com>
<3ECD816D.4080608@cs.columbia.edu>
In-Reply-To: <3ECD816D.4080608@cs.columbia.edu>
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: <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: 7bit
Content-Transfer-Encoding: 7bit
About time I finished this and got the document submitted. My remarks prefaced with [PTT]. I had help from Jim McEachern. Henning Schulzrinne wrote: >> centresin the PSTN, the scenarios involving stationary or >> nomadic SIP > > > spelling [PTT] Fixed > >> phones are described and then alternative strategies for >> supporting the information flows for the scenarios needed to >> meet these requirements are examined. The analysis presented >> here is a necessary step in defining the SIP specific >> requirements for invoking emergency assistance and understanding >> the level of functionality that can be provided by existing SIP >> devices and network elements and that which requires further >> development. > > >> in the European Market in general, or 000 in Australia. (Globally > > > I thought it was European Community? [PTT] Fixed. > >> there are about 60 different emergency services numbers in use >> [4].) > > >> This document uses the term SIP phone to denote a device which >> plugs into a wired network. This can be a either a physical >> phone device or a PC running a software based SIP client (often >> referred to as a SIP softphone). These devices can be >> stationary or nomadic. > > > Why a wired network? I think the issues for a PDA or laptop or even a > phone (via an Ethernet-to-802.11 bridge) that connects via an 802.11 > hotspot are fairly similar. [PTT] I've rewritten this section to focus on the distinction between stationary, nomadic, and mobile, with little mention of access technology. This should also answer your next comment. > >> >> Scenarios involving cellular phones using SIP signalling are not >> necessarily considered, because the current expectation is that >> they use the emergency service solutions devised for cellular >> phones in general. However, it is anticipated that many aspects >> of a general SIP signaling solution could apply to those >> scenarios. The requirements for Wi-Fi enabled devices (e.g. a >> SIP softphone with Wi- >> Fi access, a Wi-Fi phone etc.) using SIP signalling are >> considered from the perspective that these devices can be >> represented as nomadic SIP users and thus addressed by several >> of the scenarios described in this document. > > > I would not make the distinction up front. > >> "legacy" is used to refer to "Enhanced 911" functionality.) > > > You mean 'basic 911'? [PTT] I mean E911. A number of the requirements come up only in that context. > >> the difference in medium and the fact that a different number >> may be dialed to initiate the call. > > > I think all single-number systems support TDD on the same number; that's > at least true for 911, as far as I know. [PTT] Qualified to say that it may be different in some countries (Australia, for sure). > >> (1) The caller requires an easily-remembered, >> location-independent means of identifying an emergency >> call. Moreover, it must be possible to indicate whether >> this is a voice call or one to be directed to a text ECC. > > > I don't think so. I think the 911 destination listens for the TDD modem > tone and then switches to a TDD. This is not by number. > >> >> (5) The ECC operator can stay in touch with the caller, even >> though the telephone set goes on hook for an intervening >> period. An example of when this is useful is if the caller, >> feeling unwell, accidentally drops the telephone back onto >> its cradle, but then is able to retrieve it. > > > As discussed previously, this is not a universal feature. This is more > of an urban legend at this point :-) [PTT] Qualified to say it depends on the country. It's required in Canada. > >> >> (6) Emergency calls are given priority handling in call >> processing and high quality media connections. (The quality >> of media connections is outside the scope of this document.) > > > Again, I don't think this is generally true, at least in the US. [PTT] Qualified to say it depends on the country. It's done in the UK. > > >> >> (7) The caller can be held accountable for the call, to dissuade >> callers from misuse of the system. > > > If you ignore pay phones :-) > >> >> 3.3 Legacy System Operation >> In the legacy network, the public telephone system operator is >> responsible for maintaining the mapping database. > > > This is imprecise - at least in the US, there is no 'the' telephone > system operator. It is generally the ILEC, but I think it would be > unhelpful to imply that we live in pre-1984/pre-1996 land. [PTT] Changed to operators (plural). > >> the location. Alternatively, various locations can be >> identified within the business and assigned a pseudo directory >> number (DN), > > > Even for phones with DID, extensions are usually not visible to the > outside. (I've tried it - all of our extensions show up as 7000. We have > DID in 7000 to 7199.) [PTT] Right. It requires additional arrangements. When it is done, blocks of numbers are allocated to specific trunks. For each outward call, the telco checks the calling line identification against the trunk it is arriving on and accepts if if that check passes. My text is actually correct, but I've expanded upon the DID case a bit. > >> 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. > > > 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. [PTT] You're getting confused between digital switches and analogue vs. ISDN access. In the US and Canada, most lines are analogue, even though practically all the switches are digital. In Europe, ISDN access is the dominant mode. > >> 4.1 A General Look At The Problem > > > at the > >> signalling passes through other intelligent elements -- SIP >> proxies and a gateway -- before reaching the telephone network. >> The SIP > > > A SIP proxy isn't mandatory. [PTT] Agreed, and I've always had that in mind. I added "perhaps" after the proxies. > > [More in next message.] > > > > _______________________________________________ > 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