Emergency Incident Data Document (EIDD) Transfer Protocols Primary Questions: Deliverables: Target Audience:

Transcription

1 Emergency Incident Data Document (EIDD) Transfer Protocols Mon, October 6 2:00PM 3:00PM Caribbean III Facilitated Jerry Schlesinger, Daniel Mongrain & Brian Rosen Now that the EIDD is well on its way to becoming an American National Standard, session participants will review and discuss the current status of the Emergency Incident Data Document, discuss whether Queries for specific EIDDs should be supported, and review and discuss available alternatives for transporting EIDDs from one FE to another. Primary Questions: When will the EIDD American National Standard be released and what will it look like? Should specifications/standards for query mechanisms for EIDDs be developed? In addition to EIDDs included in SIP invite, what are other transport methods that should be supported (web service, etc.)? Deliverables: Review the status of the EIDD ANS Discuss whether query mechanisms for specific EIDDs should be supported (All EIDDs related to a specific Incident Tracking ID, all EIDDs in a geographic area, All EIDDs meeting user specified criteria, etc.) and which FEs should support the queries. Review available EIDD transport mechanisms Identify candidate alternative transport mechanisms Target Audience: System Developers Communication Center Managers Telecommunicators interested in exchanging emergency incident information within and between PSAPs

2 Emergency Incident Data Document (EIDD) Transfer Protocols - NOTES Mon, October 6 2:00PM 3:00PM Caribbean III Facilitated Jerry Schlesinger, Daniel Mongrain & Brian Rosen We ll cover evolution and Current Status, Queries, and Transport Mechanisms. It s interactive feel free to speak up. What is an EIDD? Standardized format for exchanging Emergency Incident Information. Groups the data by logical data elements. Establishes the relationship between data components. Agency s current view of an incident. Not historical either all you re getting is the view of the element of what is known about the incident at that moment. This is an APCO/NENA effort. NIEM conformant National Information Exchange Model. XML Schema IEPD, too Information Exchange Packet Document. In process of becoming ANS standard. Core service applications typically communicate via SIP through the ESInet. This is a standardized, non-proprietary method for exchanging incident information. SIP and Web services are the preferred methods for exchanging data. EIDD is an electronic version of the old-time ticket.

3 EIDD Exchange Rules. Not required within a single manufacturer s system. It IS required between dissimilar manufacturers. EIDDs are not broadcast. Need to authenticate users before receiving EIDDs. EIDD contents are filtered based on User s role. EIDDs should be validated against the forthcoming EIDD ANS XML schema. Validated against the business rules included in the EIDD IEPD ANS. Significant changes to an incident require an EIDD to be issued. When are EIDDs typically exchanged within a PSAP? Call Handling to Incident Handling. Incident Handling to Dispatch. Dispatch to Incident Handling. Dispatch to Mobile Data. Mobile Data to Dispatch. All FEs to Logging Services (recorder). Most interactions between FEs involve EIDD exchanges. Typical EIDD Exchanges between PSAPs. Call transfers. Secondary PSAPs. Dispatch/Incident Handling to Dispatch in different PSAP Automatic/Mutual aid, responder status updates, etc. Major Incidents sharing incident in formation and requesting resources. Most interactions between NG9-1-1 systems involve EIDD exchanges. Other EIDD Exchanges. PSAP to Emergency Management (filtered). PSAP to News Media (highly filtered). PSAP to Towing company. CAD to RMS. Others we haven t thought of yet. Question about how the News Media will be able to interpret an EIDD. This might be a way for Smart Apps to send information to a PSAP. Glorified RSS feed. Purely XML at this point. Will depend on the transport. EIDD ANS Status. EIDD Information Document published on NENA Website (NENA-INF-005, 2/21/14). EIDD WG moved from NENA to APCO to complete the EIDD ANS process. At the time, NENA was not an SDO. SEARCH developed a NIEM conformant IEPD based on the EIDD INF. APCO WG reviewing/adjusting EIDD INF and IEPD. Identified person and vehicle data elements. Updating IEPD and XML Schema as required that s in progress. Ensuring compatibility with i3 schemas. EIDD transport not currently addressed in the EIDD ANS. ANS only defines freight train; data component is a freight car, tailored to the data it carries. IJIS and APCO EIDD Springboard. Test feasibility of EIDD IEPD. 13 vendors currently participating. Will certify vendor conformance with EIDD ANS. EIDD ICE event is to be planned. EIDD ANS public review 1 st quarter of 2015 possibly. Transport Mechanism Status. STA ( V2) has EIDD transport in a SIP transaction (as part of a call transfer) as well as a dereference mechanism for EIDD-by-reference. Brian takes over. I3 will handle transport mechanisms. That transport will not be in STA Brian has done a contribution with several mechanisms in it. Subscribe/Notify and Asynchronous Push. AP is a way to send an EIDD not necessarily requested.

4 EIDD Queries. Supported through proposed subscription filters: Incident Tracking ID current status of incident. Active incident within an agency. Active incident within a geographic area. All EIDDs for an Incident Tracking ID within a time interval. There is no explicit query that allows a list of all agencies involved with an incident. EIDD Transport in Calls. Required during a conference and/or transfer with another agency. EIDD is found in the Call-Info header with a purpose of eidd. The INVITE includes the EIDD by value (actual data) or by reference ( a link where to get the data). Reference embedded in Call s SIP and EIDD retrieved via dereferencing (HTTP GET). Embedded EIDD requires prior filtering. Dereferencing enables filtering based on real-time authentication. These mechanisms are in STA Subscribe/Notify. FEs subscribe with each other for EIDD updates. Subscribe by Incident ID to get all updates for an Incident. Subscribe for one NOTIFY per new Incident to find out about incidents. Filter mechanism for subscriber to control NOTIFYs it gets. Rate Controls and Content Controls. These mechanisms can be used together. Filtering mechanism can control things like the rate at which things are sent. Content filtering. Time filter, geographic filtering. Can also be used to say give me these sections. FE sends a notify to all subscribed systems meeting filter criteria that an EIDD is available. Two protocol bases are being discussed to provide the Subscription/Notification service: SIP SUBSCRIBE/NOTIFY EIDD included in the body of SIP messages. Web service. Asynchronous EIDD Transport. EIDDs are pushed to systems, requesting actions from the receiving entities. More complex uses a specific ladder truck with a specific ladder more nuanced response. Receiving agencies set policies on the types of asynchronous EIDDs that they will receive, if any. Proposal uses the SIP MESSAGE method. This leverages the ESRP s PRF to route the request to the most appropriate agency at that time, similar to how calls are routed. Normal generic Dispatch request just has an EIDD. Receiving Agency Use OASIS EDXL-RM 1.0 resource management mechanism for incident in which the response is not obvious. Uses the EDXL Distribution Element. EDXL message included in the SIP MESSAGE body. Mime header of application/emergencydata-exchange-language XML. OASIS has specified appropriate EDXL message types and responses. Message types and responses involved in EIDD transport specifications. Typical message types; request resource, RespondToRequest, Requisition resource, wealth of other message types.

5 Discussion PSAP to PSAP transfer SIP infrastructure makes a lot of sense. Only thing in PSAP today is Call Handling everything else doesn t implement SIP capabilities today. Craft custom parsers for this? Three dozen open source SIP stacks. RFCs have mechanisms needed for filtering. Nothing in w3c standard. Debate about creating open source programs. This is where vendors need to say if something is easier than creating a SIP stack. Jerry says on project he s on is common theme is to use Webservices. Two protocols doing the same thing is one needs to be mandatory and one is optional. Or there s a bridge element but that might be a bad choice. Subscribe/notify is not a standalone question. Element state raises the same issue. Queue state. Example about developing an application with multiple resources is easy. We opine something that is easy for Brian might not be easy for us! Question about message queues being looked at AEQD maybe? Brian says it hasn t been looked at but isn t of use to us. What about when an agency needs to expunge data? How do we handle a court order? It s saved in a logger have to create a transaction that does that. Need to record who you sent it to in case of expungement.