Comment 2267
Accepted (Resolved)
NENA-STA-012.2_AddlData_PubRvw (Revision 0)
Comment Submitted by
Delaine Arnold, ENP-Admin
2017-07-23 10:26:44

Since Nicholas Horelik (nhorelik@rapidsos.com) is on this WG, he may have already brought this up, but here is something that was reported during ICE 7 testing. If so just close this out as not an issue.

The standard allows for multiple Call-Info headers to be present in a SIP INVITE, where each one would contain a dereferencing link to a different additional data block.  It is possible and likely in certain scenarios for intermediate functional elements (e.g. an ESRP) to add more Call-Info headers when calls pass through them (e.g. if they add more provider info, or if they pull additional location info from an ECRF).  In addition, it is possible for these data blocks to also be added by value into the INVITE, either by the originator or by intermediate functional elements, or by both.  In addition, it is possible for an IS-ADR to be queried from any functional element, or by the call handling or CAD at the PSAP.

Ultimately however it is generated, the problem is that we are likely to end up at the PSAP with more than one additional data document for one or more data block types.  At the event, we saw that all PSAP implementations were only expecting one data document per data block type, and thus could only display one.  Usually they would display to the call-taker only the latest one they received, and discard the rest.

There is no clear guidance in the standards for how to handle this scenario that anyone at the event was able to cite.  I would recommend that the existing setup of flexibility in the SIP signaling be maintained, and a note or requirement be added to the standards indicating that downstream elements at a PSAP should have the ability to display multiple data blocks in one manner or another (e.g., by showing each set in a different tab or window).  I would think that this doesn't need to be too perscriptive: each vendor could handle presentation in a different way, as long as the ability to display all received information is present.

 

Submitter Proposed Solution
Mr. Karl Larsen
2017-08-28 12:30 pm EDT

Sent Nick an email including the following references to see if this satisfies his comment from ICE 7:

In the Public Review document: https://dev.nena.org/higherlogic/ws/public/download/11393/NENA-STA-012.2_AddlData_PubRvw.pdf. There are now a few places, including the paragraph starting at line 507 (Additional Data for the Call -section 3.3.1), lines 732-733 (Additional Data for the Caller - section 3.5.1) and lines 626 – 628 (Additional Data for the Location - section 3.4.1) that talk about multiple or more than one.

Nick responded fine with closing out the comment based on a review of the items. We will discuss on the next work group as well.

Ms. Delaine Arnold, ENP-Admin
2017-08-28 12:40 pm EDT

As Nick concurred that the item has been addressed via this email, I accept the WGs response.

From: Nicholas Horelik [mailto:nhorelik@rapidsos.com]
Sent: Friday, August 25, 2017 2:46 PM
To: Karl Larsen
Cc: Matt Serra
Subject: Re: NG9-1-1 Additional Data ICE7 Comment

Hi Karl, Apologies for my delay - I've reviewed each of the items you pointed out, and would be fine with a comment that this is something we discussed and addressed in the group, to close out Delaine's comment.  Nick