Subject: [Ecrit] FW: I-D Action:draft-rosen-ecrit-additional-data-00.txt

From: Brian Rosen <[email-masked]>
Date: Mon, 01 Mar 2010 17:14:44 -0500

In NENA, we designed a data structure that would provide us information that
a carrier or other service provider knows about a call.  In the current
9-1-1 system, there is information in what is called the "ALI" (Automatic
Location Identification) query response that has nothing to do with
location, but instead has other information about the service provider or
the subscriber.

In the NENA i3 work, we defined a new data structure "Additional Data about
a Call" that gave non-location information known by a device or service
provider in the path of the call.  Since we went to all the trouble to point
out that the ACCESS NETWORK provides location, we point out that this is the
CALLING NETWORK that is providing this data.  There could be more than one
of them, if there were more than one service provider in the path, which can
happen.  The URL to this structure is passed in a sip "Call-Info" header.

Anyway, we want this data regardless of whether the service provider is a
North American service provider, and we think the data is useful to all
PSAPs.  

It serves one other purpose: it has a "hook" for data that is device
specific.  Examples are crash data for a telematics equipped vehicle, or
sensor data from a health monitoring device.  The Additional Data about a
Call does not define such data, just provides a place for a URL to it.

So, we're submitting the NENA data structure to the IETF to see if we can
get agreement in ecrit to create an Internet standard that everyone can use.
NENA understands that that could mean that the structure changes from what
NENA designed.

We look forward to your comments on the idea.

Brian and Hannes

------ Forwarded Message
From: <[email-masked]>
Reply-To: <[email-masked]>
Date: Mon,  1 Mar 2010 14:00:01 -0800 (PST)
To: <[email-masked]>
Subject: I-D Action:draft-rosen-ecrit-additional-data-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

 Title           : Additional Data related to a Call for Emergency Call
Purposes
 Author(s)       : B. Rosen, H. Tschofenig
 Filename        : draft-rosen-ecrit-additional-data-00.txt
 Pages           : 24
 Date            : 2010-03-01

When an emergency call is sent to a PSAP, the device that sends it,
as well as any service provider in the path of the call may have
information about the call which the PSAP may be able to use.  This
document describes an XML data structure that contains this kind of
information in a standardized form.  A URI that points to the
structure can be included in the SIP signaling with the call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosen-ecrit-additional-data-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------ End of Forwarded Message

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 1 Mar 2010 17:41:35 -0500

One general concern of mine is that we seem to be heading towards (at least) three different enterprise registrations:

- the SIP Forum needs to register providers to identify configurations and seems to be about to establish a registry;

- the IETF has enterprise numbers;

- NENA has an (unregistered?) URN for its registry.

I suspect that in many cases, the company URL or domain name would be better than nothing.

Given the likelihood of international calls as we no longer need traditional roaming, it would be nice to be clear how this might work outside the US. Should all non-US carriers register with NENA? Can they? Would an IETF enterprise ID, given that it's free and easy to get, be sufficient?

It might be useful to define at least some indication of roles. For example, a single call may well have a telematics data provider, a SIP provider and maybe a third-party data provider (e.g., Google Health). The document seemed fuzzy on who all would be identified and how the call taker could tell who is doing what.

Henning

On Mar 1, 2010, at 5:14 PM, Brian Rosen wrote:

> <draft-rosen-ecrit-additional-data-00.txt>_______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Mon, 01 Mar 2010 17:50:24 -0500

I think we would agree that a URL would be better than nothing.

The NENA ID exists, and maintaining it makes sense.  There may be similar
registries in other countries.

There is more than a unique ID in a NENA registry: there is other data that
NENA keeps that PSAPs can get at, although the proposed data structure
duplicates some of that.

So I guess we would say: if a national registry exists, use it.
If it doesn't, use a URL.

The service provider role is pretty wrapped up in the "service delivered by
provider to user".  I doubt we would object to having another element that
would be a more precise role definition of the provider.

Brian

On 3/1/10 5:41 PM, "Henning Schulzrinne" <[email-masked]> wrote:

> One general concern of mine is that we seem to be heading towards (at least)
> three different enterprise registrations:
> 
> - the SIP Forum needs to register providers to identify configurations and
> seems to be about to establish a registry;
> 
> Given the likelihood of international calls as we no longer need traditional
> roaming, it would be nice to be clear how this might work outside the US.
> Should all non-US carriers register with NENA? Can they? Would an IETF
> enterprise ID, given that it's free and easy to get, be sufficient?
> 
> It might be useful to define at least some indication of roles. For example, a
> single call may well have a telematics data provider, a SIP provider and maybe
> a third-party data provider (e.g., Google Health). The document seemed fuzzy
> on who all would be identified and how the call taker could tell who is doing
> what.
> 
> Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 1 Mar 2010 18:00:03 -0500

> If it doesn't, use a URL.

My main concern is the ability to access data. If I visit Korea, using Vonage as my US-based service provider, will the PSAP be able to resolve a NENA URN and how? (This may not be a problem for the US-Korea example, given the large number of travelers, but may be harder for the Estonia-New Zealand-type case.)

I think duplicating as much as possible of the NENA-registered information is a good thing. Indeed, I'd argue that all (public) information should be accessible in machine-parseable form (i.e.,  XML, not just a web page), so that one doesn't need two access protocols and can more readily render tags and other information in appropriate (e.g., translated) form.