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

["Peterson, Jon" <[e-mail]>]

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

- J

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, October 11, 2004 11:31 AM
> To: Peterson, Jon
> Cc: [e-mail]
> Subject: RE: [Sipping-emergency] New revision of proposed 
> ECRIT charter
> 
> 
> 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 <[e-mail]>
> > Jon Peterson <[e-mail]>
> > 
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 
> _______________________________________________
> Sipping-emergency mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 
> 

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