Subject: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22

From: Roger Marshall <[email-masked]>
Date: Mon, 5 May 2014 18:52:21 +0000

I'd like to propose that a new Call-Info header - something to be added to the draft based on some early implementation experience in NENA and NG9-1-1.

In addition to the Call-Info header usage already defined in the draft, I propose that we require the addition of a single new Call-Info header that includes a purpose parameter to denote the service provider that handed off the call last, making this provided-by information easily accessible for routing reasons without requiring the elements along the path to dig out the value from the PIDF-LO - whether from the MIME body part of from a by-Reference retrieval operation.

We would want to retain Call-Info with purpose=EmergencyCallData.ProviderInfo to carry the "full XML" (either byV or byR), one per Access Network Provider, Service Provider, etc (as described in the draft)

And then add functionality for our newly proposed Call-Info header with purpose=nena-ProviderID.  To clarify the intent, this new purpose=nena-ProviderID is for the Telecom Provider, which is described in section 3.1.4 of the additional-data draft as "Calling or origination telecom SP", of which there can only be one.   So multiple Call-Info with purpose=nena-ProviderID would not make sense.  To help clarify, I think we should rename the purpose to be more like purpose=nena-TelecomProviderID, so that the value of the purpose helps clarify.

In the long run signaling should carry both the Call-Info with purpose=EmergencyCallData.ProviderInfo (either byR or byV) with the full XML, and then exactly one with purpose=nena-TelecomProviderID as proposed.  

Note that for the purpose=EmergencyCallData.ProviderInfo there can be multiple of those Call-Info (per the draft), so that each "provider" in the path can attach their own data (as described in the draft).  Also note that for legacy carrier where ESInet is constructing the SIP for the 911, there will probably be only one.

What do people think?

-roger.

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 23, 2014 3:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-22.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.

        Title           : Additional Data related to an Emergency Call
        Authors         : Brian Rosen
                          Hannes Tschofenig
                          Roger Marshall
                          Randall Gellens
                          James Winterbottom
	Filename        : draft-ietf-ecrit-additional-data-22.txt
	Pages           : 97
	Date            : 2014-04-23

Abstract:
   When an emergency call is sent to a Public Safety Answering Point
   (PSAP), the device that sends it, as well as any application service
   provider in the path of the call, or access network provider through
   which the call originated may have information about the call, the
   caller or the location which the PSAP may be able to use.  This
   document describes data structures and a mechanism to convey such
   data to the PSAP.  The mechanism uses a Uniform Resource Identifier
   (URI), which may point to either an external resource or an object in
   the body of the SIP message.  The mechanism thus allows the data to
   be passed by reference (when the URI points to an external resource)
   or by value (when it points into the body of the message).  This
   follows the tradition of prior emergency services standardization
   work where data can be conveyed by value within the call signaling
   (i.e., in body of the SIP message) and also by reference.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-22

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-22

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

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

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 May 2014 19:35:03 +0000

I’m confused, but I don’t think I like it.

My confusion is “dig out the value from the PIDF-LO”.

The only reason it would be there is if the access network put it there.  Otherwise, it would be in a Call-Info header.  You can’t get it in the call path if it’s provided by the access network.

But the rest of the message seems to be talking about the origination network.  Thus my confusion.

I think adding stuff to a call header just to simplify routing is misplaced.  We should add mechanism to the routing infrastructure to make it easy to base a route decision on it.

Also, basing an IETF mechanism on a NENA ID is a bad idea.

But then, I think routing based on the id of the telco is a bit suspect.  Smacks of preferential treatment.

Brian

---

From: James Winterbottom <[email-masked]>
Date: Tue, 6 May 2014 06:05:09 +1000

Hi Brian,

> The only reason it would be there is if the access network put it there.  Otherwise, it would be in a Call-Info header.  You can’t get it in the call path if it’s provided by the access network.
[AJW] if it is a single access-cal-service provider then it may all be packed into the PIDF-LO

> But then, I think routing based on the id of the telco is a bit suspect.  Smacks of preferential treatment.
[AJW] Are you suggesting that the Provider-ID be used for routing Roger? There may be stuff in the information about the caller that might aid with some kind of policy routing, but I can’t think that a provider-ID would help much there?
The only other case I can think of is the hand-off case, where the VSP that owns the customer has handed the emergency call off to someone else to deal with. In this case the Provider-ID might help if you know what a certain provider is always a go-between, then you don’t check their info first, you check the others. But the use case feels a bit thin.

Cheers
James