Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter

From: [email-masked]
Date: Mon, 11 Oct 2004 14:30:55 -0400

I agree with all the comments so far. 

Does the statement: "This group is considering emergency services calls which might be made by any user of the PSTN or Internet" imply that, to some degree, this group will also be considering how to route and/or protocols for PSTN originated emergency calls for the ERC as well?

Nate

Peterson, Jon wrote:
> All,
> 
> Here's a new version of the ECRIT charter for your consideration, that
> attempts to incorporate the discussion over the past couple of weeks.
> 
> Any further issues?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> ---
> 
> Emergency Context  Resolution with Internet Technologies (ECRIT)
> 
> Transport Area Director(s):
> Allison Mankin <[email-masked]>
> Jon Peterson <[email-masked]>
> 
> Transport Area Advisor: TBD
> 
> Working Group Chairs:  TBD
> 
> In a number of areas the public switched telephone network (PSTN)
> has been configured to recognize an explicitly specified number (commonly
> one that is short and easily memorized) as a call for emergency services.  
> These numbers (e.g. 911, 112) relate to an emergency service context and
> depend
> on a broad, regional configuration of service contact methods and a
> geographically
> constrained context of service delivery.  These calls are intended to be
> delivered to
> special call  centers equipped to manage emergency response. Successful
> delivery
> of an emergency service call within those systems requires both an
> association of
> the physical location of the originator with  an appropriate emergency
> service
> center and call routing to deliver the call to the center.
> 
> Calls placed using Internet technologies do not use the same systems to
> achieve those goals, and the common use of overlay networks and tunnels
> (either as VPNs or for mobility) makes meeting them more challenging.  There
> are, however, Internet technologies available to describe location and to
> manage call routing.  This working group will describe when these may be
> appropriate
> and how they may be used.   Explicitly outside the scope of this group
> is the question of pre-emption or prioritization of emergency services
> traffic. This group is considering emergency services calls which might be
> made by
> any user of the PSTN or Internet, as opposed to government or military
> services that may impose very different authentication  and routing
> requirements.
> 
> The group will show how the availability of location data and call routing
> information
> at different steps in  session setup would enable communication between a
> user
> and a relevant emergency response center. Though the term "call routing" is
> used in this
> document, it should be understood that some of the mechanisms which 
> will be described might be used to enable other types of media 
> streams. Video and text messaging, for example, might be used to request
> emergency services.
> 
> While this group anticipates a close working relationship with NENA, any
> solution
> presented must be useful regardless of jurisdiction, and it must be possible
> to
> use without a single, central authority.  Further, it must be possible for
> multiple
> delegations within a jurisdiction to be handled independently, as call
> routing
> for specific emergency types may be indepdent.
> 
> Deliverables:
> 
> Informational RFC containing terminology definitions and the requirements.
> 
> A BCP describing how to identify a session set-up request is to an emergency
> response center.
> 
> A BCP describing strategies for associating session originators with 
> physical locations.
> 
> A BCP or Standards Track RFC describing how to route an emergency call
> based on location information.  Either within that document or as a separate
> document, a description of how error conditions are returned to the session
> originator and how to test for error conditions without activating an
> emergency
> response.  Privacy concerns related to that testing must be addressed
> in this document set.
> 
> A BCP describing how to discover the media stream types an ERC supports.
> 
> An Informational document describing the threats and security
> considerations.
> 
> 
> _______________________________________________
> Sipping-emergency mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-emergency

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Roger Marshall <[email-masked]>
Date: Wed, 13 Oct 2004 17:21:48 -0700

Jon:
Does the mention of NENA imply a formal relationship of approval by either
entity in any way, or rather an informal exchange of ideas and/or
information between the two?

Roger Marshall
TeleCommunication Systems, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Sunday, October 10, 2004 11:01 PM
To: [email-masked]
Subject: [Sipping-emergency] New revision of proposed ECRIT charter

All,

Any further issues?

Jon Peterson
NeuStar, Inc.

---

In a number of areas the public switched telephone network (PSTN) has been
configured to recognize an explicitly specified number (commonly one that is
short and easily memorized) as a call for emergency services.  
These numbers (e.g. 911, 112) relate to an emergency service context and
depend on a broad, regional configuration of service contact methods and a
geographically constrained context of service delivery.  These calls are
intended to be delivered to special call  centers equipped to manage
emergency response. Successful delivery of an emergency service call within
those systems requires both an association of the physical location of the
originator with  an appropriate emergency service center and call routing to
deliver the call to the center.

made by any user of the PSTN or Internet, as opposed to government or
military services that may impose very different authentication  and routing
requirements.

The group will show how the availability of location data and call routing
information at different steps in  session setup would enable communication
between a user and a relevant emergency response center. Though the term
"call routing" is used in this document, it should be understood that some
of the mechanisms which will be described might be used to enable other
types of media streams. Video and text messaging, for example, might be used
to request emergency services.

While this group anticipates a close working relationship with NENA, any
solution presented must be useful regardless of jurisdiction, and it must be
possible to use without a single, central authority.  Further, it must be
possible for multiple delegations within a jurisdiction to be handled
independently, as call routing for specific emergency types may be
indepdent.

Deliverables:

A BCP or Standards Track RFC describing how to route an emergency call based
on location information.  Either within that document or as a separate
document, a description of how error conditions are returned to the session
originator and how to test for error conditions without activating an
emergency response.  Privacy concerns related to that testing must be
addressed in this document set.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 Oct 2004 13:18:47 -0400

Well, it certainly isn't intended to imply that. Um... I suppose we can take
out the term "PSTN" there.

- J

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 11, 2004 11:31 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: RE: [Sipping-emergency] New revision of proposed 
> ECRIT charter
> 
> 
> Does the statement: "This group is considering emergency 
> services calls which might be made by any user of the PSTN or 
> Internet" imply that, to some degree, this group will also be 
> considering how to route and/or protocols for PSTN originated 
> emergency calls for the ERC as well?
> 
> Nate
> 
> Peterson, Jon wrote:
> > All,
> >

---

From: Roger Marshall <[email-masked]>
Date: Fri, 15 Oct 2004 10:47:07 -0700

Looks fine to me, whith amendments as suggested by others.

Roger Marshall
TCS

-----Original Message-----

All,

Any further issues?

Jon Peterson
NeuStar, Inc.

---

Deliverables:

---

From: "Abbott, Nadine B." <[email-masked]>
Date: Thu, 21 Oct 2004 10:57:34 -0400

Jon,

In the North American National Emergency Number Association (NENA) VoIP
Location WG, we have been grappling with the problem of how additional
information relevant to an emergency call might be carried to the emergency
call taker.  For example, this might include information about the caller
(e.g., Customer Name, Class of Service--Residence, Business, Public, etc.)
and information about/from a VoIP/Communications Service Provider (e.g.,
contact information for that provider) that are relevant to an emergency
call.  We are not yet ready (before this next meeting) to provide a list of
proposed requirements.  
However, I wondered if you consider that the charter for ECRIT, as written,
covers the issue of how such information--caller supplied and/or service
provider supplied--might be carried in SIP?

Respectfully,
Nadine Abbott
NENA VoIP Location WG team leader

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 21 Oct 2004 10:33:21 -0500

Isn't most of this an extension to the PIDF-LO effort in Geopriv, and not 
part of ECRIT?

The portion that I believe is part of SIP/PING would be the addition of a 
body part by the VSP (in add the contact info you want) - which has so far 
been frowned upon (to say the least) in these WGs

>NENA VoIP Location WG team leader

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 28 Oct 2004 11:20:25 +0200

hi james, 
 
some data items seem to be part of the pidf-lo work. however, as nadine
mentioned there are additional fields:
- Customer Name, 
- Class of Service--Residence, Business, Public, etc.
- information about/from a VoIP/Communications Service Provider

this information is not included in the pidf-lo.

is this use case for saml you are often talking about? 

ciao
hannes

> From: James M. Polk [mailto:[email-masked]] 
> Sent: Donnerstag, 21. Oktober 2004 17:33
> To: Abbott, Nadine B.; Peterson, Jon
> Isn't most of this an extension to the PIDF-LO effort in 
> Geopriv, and not part of ECRIT?
> 
> The portion that I believe is part of SIP/PING would be the 
> addition of a body part by the VSP (in add the contact info 
> you want) - which has so far been frowned upon (to say the 
> least) in these WGs
>