Subject: AW: [Ecrit] introduction section (<draft-schulzrinne-ecrit-requirements-01.txt>)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 9 Aug 2005 15:49:43 +0200

hi henning, 

> I agree that this can be shortened, but would like suggesting keeping 
> text that allows the reader to identify how our overall sequence of 
> steps work. This is far from obvious to most "bystanders" and 
> we don't 
> have another document to point to.
that's true. we don't have another document at the moment.

> Below, I trimmed stuff I think is 
> unncessary details and did some re-ordering.
good. 

ciao
hannes

> 
> Tschofenig, Hannes wrote:
> > hi all, 
> > 
> > please find my comments below (#). 
> > 
> > i think the introduction is too long and repeats requirements. 
> > 
> > 
> > 1.  Introduction
> > 
> >    Users of telephone-like services expect to be able to call for
> >    emergency help, such as police, the fire department or 
> an ambulance,
> >    regardless of where they are, what (if any) service 
> provider they are
> >    using and what kind of device they are using.  Unfortunately, the
> >    mechanisms for emergency calls that have evolved in the public
> >    circuit-switched telephone network (PSTN) are not quite 
> appropriate
> >    for evolving IP-based voice, text and real-time multimedia
> >    communications.  This document outlines the key 
> requirements that end
> >    systems and network elements such as SIP proxies need to 
> satisfy in
> >    order to provide emergency call services that offer at 
> least the same
> >    functionality as existing PSTN services, with the goal of making
> >    emergency calling more robust, cheaper to implement and 
> multimedia-
> >    capable.
> > 
> 
> > 
> >    This document only focuses on end-to-end IP-based calls, 
> i.e., where
> >    the emergency call originates from an IP end system, (Internet
> >    device), and terminates to an IP-capable PSAP, done 
> entirely over an
> >    IP network.
> > 
> > 
> > 
> > # ------ i would shorten the following paragraphs below by 
> just saying
> > something like. 
> > Section 2 defines terminology, Section 3 lists high-level 
> requirements,
> > etc... 
> > 
> >  
> >    This document identifies functional and security issues for
> > #                                          ^^^^^^^^^^^^^^^^
> > #  in fact this document does not specify security requirements. 
> > 
> >    determining the correct emergency identifier, for identifying the
> >    appropriate PSAP (emergency address) and for identifying 
> the caller
> >    and its current location.
> 
> [should be in section order]
> 
>  >    Emergency calls need to identify the location from 
> which the call is
>  >    initiated (Section 5).  The caller location needs to be 
> identified
>  >    for two purposes, namely to route the call to the 
> appropriate PSAP
>  >    and to display the caller location to the call taker to simplify
>  >    dispatching emergency assistance to the correct location.
> 
> 
> 
> 
> > 
> >    Emergency calls need to be identified (Section 6).  Emergency
> >    identifiers are used by the emergency caller to declare 
> a call to be
> >    an emergency call.  
> > 
> >    Emergency calls need to be routed to the appropriate PSAP (ref.
> >    Section 6).  
> 
> >    Emergency calls need to identify who placed the call 
> (Section 7). 
> 
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 17 Aug 2005 10:37:03 +0200

I want to suggest to sharpen up wording about other media than voice.
There is one part of the introduction about this topic that needs
sharpening and there is another later specifically on other media.

This is my proposed wording of these sections:

1. In 1. Introduction:
------------------------------------------------------------------------
---------
"Users of other real-time and near real-time services
also expect to be able to summon emergency help. For example,
instant messaging (IM) and real time text users want to use such
services. IM and real time text are particularly helpful for
hearing-disabled users (RFC 3351 [4]), when there is a need for
exactness as for example for spelling out names and addresses and in
cases where bandwidth is scarce."

3. In 3. High Level requirements
------------------------------------------------------------------------
----------

"R4. Multiple Modes: Multiple communication modes, including
Multimedia data and services MUST be supported.
Motivation: In PSTN, voice and text telephony
( often called TTY or TDD in North America ) are the only commonly
supported media.
Emergency calling must support a variety of media. Such
media should include voice, conversational text, instant
messaging and video.

It should also be possible to involve relay services in the call
for translation between different modes. It should be possible
to connect the relay service so that the direct flow of media
to the emergency service is maintained.
In addition, it should be possible to convey telemetry data,
such as data from automobile crash sensors. "

I hope you find them useful.
Motivations for the proposed modifications:

a. Real time text and IM are not for the future. They are here now, and
their older PSTN companion is used for emergency since long. We cannot
leave a gap in service provision until some undefined future!

b. There are clear observations that relay services are important to
include in some calls for translation between different media.

c. Mention both real time text and IM. The users should be provided with
the service they use daily, also when they need to do the emergency
call. They have different characteristics, and both will be used for
different purposes or by different users.

Regards

Gunnar Hellstrom.
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of
>[email-masked]
>Sent: Monday, July 11, 2005 9:50 PM
>To: [email-masked]
>Subject: I-D ACTION:draft-schulzrinne-ecrit-requirements-01.txt
>
>
>A New Internet-Draft is available from the on-line
>Internet-Drafts directories.
>
>
>	Title		: Requirements for Emergency Context
>Resolution with Internet Technologies
>	Author(s)	: H. Schulzrinne, R. Marshall
>	Filename	: draft-schulzrinne-ecrit-requirements-01.txt
>	Pages		: 23
>	Date		: 2005-7-11
>
>This document enumerates requirements for emergency calls placed by
>   the public using voice-over-IP (VoIP) and general Internet
>multimedia
>   systems, where Internet protocols are used end-to-end.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-req
uirements-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-schulzrinne-ecrit-requirements-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-01.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.