Subject: [Ecrit] Feedback against Additional Call Data from NENA Additional Data WG

From: Matt Serra <[email-masked]>
Date: Mon, 2 Apr 2012 20:41:02 -0500

To the IEFT ECRIT WG:

Below is an additional set of feedback collected through NENA's Additional Data Work Group.  We ask that these comments be considered against the most current Additional Call Data draft (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-03).  Much of this feedback stems from our analysis of mapping between the proposed Additional Call Data format, and legacy ALI data formats.

1. 	Main Telephone Number

The data structure addCallSub lacks a mechanism to distinguish the specific "Main Telephone Number" designation of a main number appearing in the subscriber's data.  The addCallSub's vCARD structure may specify multiple telephone numbers, and elements are defined in the vCARD schema for conveying parameters.  However, no specific parameter values are defined that adequately describe"main telephone number" as conveyed in some emergency calling scenarios.

1.1 Legacy Context: Main Telephone Number is a data element supported in North American legacy emergency calling scenarios.  When a legacy call is gatewayed into an i3 ESInet, this number may be populated in additional call data by an LNG.

1.2	Suggested IANA registered values for XML vCARD RFC 6350/6351 ref. http://www.iana.org/assignments/vcard-elements/vcard-elements.xml

1.2.1	Property/Parameter: RFC 6350 and RFC 6351, vcard/tel/parameters/type/text
1.2.2	Values: Main

1.3	Suggested changes to draft-ietf-ecrit-additional-data: Require use of the IANA registered 'tel' parameter values when a more than one 'tel' element is populated in a vCARD.

2.	Convey Service Provider

The data structure addCallSvcInfo needs a mechanism to convey identity information describing the provider of the calling service that is offered to the end user (which may be different than the provider of the data as defined in draft-ietf-ecrit-additional-data-03 section 4).

2.1	Legacy context
Data Provider (CPS) and Access Provider (CPF) are data elements supported in North American legacy calling.  When a legacy call is gatewayed into an i3 ESInet, both of these providers should be represented in the additional call data populated by an LNG.

2.2	Suggested changes to draft-ietf-ecrit-additional-data

2.2.1 Add the following fields to the addCallSvcInfo data structure described in Section 5, using equivalent descriptions given in Section 4 addDataProviderInfo as a template:

* Service Provider String
* Service Provider ID
* Service Provider Contact URI
* Service Provider Language (s) Supported
* vCARD of Service Provider

2.2.2 Add the fields to the addCallSvcInfo and addDataProviderInfo data structure to describe the following concepts, where the new fields are conditional, provided only when Provider information exists for both "service" and "data":

* Relationship (between data and service provider)
* Either an Implicit (fixed order) or Explicit (numbered) sequence of escalation.

3.	Service Delivered by Provider to End-User

The description of Service Delivered by Provider to End-User notes " There can be more than one value returned." However the XML defines a 'maxOccurs="1"' restriction on the SvcDelByProvider element.

3.1 	Suggested changes to draft-ietf-ecrit-additional data:  remove "maxOccurs" restriction on this field.

4.	Additional data not authorized (by-value conveyance)

There is no mechanism defined in draft-ietf-ecrit-additional-data-03 to convey (by value) the semantic that additional data was attempted to be obtained from the authoritative data provider, but none provided due to access limitations.  When additional data is conveyed by reference, this indication could be served by status codes defined for the dereference protocol (e.g. HTTP 403 Forbidden).  But since these dereference protocol status codes are not included when additional data is conveyed by value, the semantic that access to additional data is not authorized is lost.

4.1	Legacy context:  An Anonymous Call indication is defined for North American calling scenarios, which is often used in association with the calling devices of dignitaries or other sensitive callers/devices.  This condition is not indicative of an error condition, and the indication of an anonymous call conveys that the data is not provided by intent.

4.2	Suggested changes to draft-ietf-ecrit-additional-data

This function is served by fields in the PPI and PAI.  We recommend an informative statement be added to the Introduction to clarify this.  For example, one might say:  "In regions where callers can elect to suppress certain personally identifying information, the network or PSAP functionality can inspect privacy flags within the identity header to drive what information is passed, stored, or displayed to comply with local policy or law."

5.	Participants

The following members of the NENA Additional Data Work Group contributed to this input, as well as the input submitted on February 22, 2012:

Ric Atkins, Brian Dupras, Roya Esfandi, Mark Fletcher, Karl Larsen, Roger Marshall, Crystal McDuffie, Kathy McMahon, Christian Militeau, Michelle Peterson, Ira Pyles, Brian Rosen, Matthew Serra, Jeff Torres, Hannes Tschofenig, Daniel Zacek

Regards,

Matthew A. Serra, ENP
NENA Additional Data Work-Group Chair

Sr. Director, Product Management 
Rave Mobile Safety | Smart911
Mobile:  201.245.1557
[email-masked]