ANSWERING OR RELEASING EMERGENCY CALLS FROM A MAP DISPLAY FOR AN EMERGENCY SERVICES PLATFORM
A method and system of emergency call management is provided. Emergency calls received at an emergency service platform (ESP) through one or more communication networks are associated with location information. The location information is identified to a map server through an i3 event logging protocol to be displayed on graphical map displays at operator positions. An operator of an operator position can then select a call from the graphical map display and an associated responder client will request that the emergency call be routed by the ESP to the operator or a secondary responder agency. The operator position are associated with a public safety access point (PSAP) associated with the incoming emergency calls.
This application is a continuation-in-part of U.S. patent application Ser. No. 13/627,417 filed Sep. 26, 2012, which claims the benefit of U.S. Provisional Patent Application No. 61/539,455, filed Sep. 26, 2011, the disclosures of which are hereby incorporated by reference in their entirety for all purposes.
TECHNICAL FIELDThe present disclosure relates to emergency service platforms and in particular to call control integration with map display systems.
BACKGROUNDThe National Emergency Number Association (NENA) had defined a protocol for the evolution of the North American 9-1-1 system, and is addressing the challenge with a system design called “Next Generation 9-1-1” or NG9-1-1 is the evolution of Enhanced 9-1-1 to an all-IP-based emergency communications system. This technical specification, commonly referred to as i3, is the first version of the NG9-1-1 system design to accommodate an increasing volume and diversity of information that can be made available to assist emergency services.
The i3 protocol references several types of originating networks that could be used to deliver calls to an public safety access point (PSAP) Emergency services Internet Protocol Network, including legacy circuit-switched networks (wireline or wireless). Networks that are not IP based that are coupled to the PSAP must undergo mediation via a gateway to convert the incoming signaling to session initiated protocol (SIP). In addition, functionality must be applied to legacy emergency calls to acquire location information and use the information obtained in call setup signaling to route a call to the public safety answering point. Mapping information has been traditional utilized to enable an operator to identify a location of a call once it has been assigned to the position. However traditional call assignment algorithms can be inefficient when an incident occurs that generate clusters of calls all related to the same event as emergency calls that are not related to the incident may not be responded to in a timely matter.
Accordingly, systems and methods that enable improved emergency call management remains highly desirable.
Further features and advantages of the present disclosure will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
In accordance with an aspect of the present disclosure there is provided a method of emergency call management, the method comprising: receiving an emergency call at an emergency service platform (ESP) providing an interface to one or more communication networks; receiving location information associated with the emergency call; identifying the location of the emergency call on a graphical map display; receiving a selection of the emergency call from a plurality of emergency calls displayed on the graphical map display; determining one or more secondary responder agencies for the selected emergency call; receiving a selection of a secondary responder agency from the one or more secondary responder agencies; and initiating a transfer of the selected emergency call to one of the one or more secondary responder agencies.
In accordance with another aspect of the present disclosure there is provided a system of emergency call management, the system comprising: an emergency service platform (ESP) interfacing to one or more communications networks for receiving emergency calls originating from the one or more communications networks; a map server for receiving location information from the ESP associated with the receive emergency calls; and a public safety access point (PSAP) coupled to the ESP and map server, the PSAP comprising one or more operator positions; each operator position comprising: a graphical map display for receiving mapping data from the map server and receiving a selection of an emergency call on the display; and a responder client coupled to the graphical map display for receiving identification of the selected emergency call and for requesting from the ESP that the emergency call be directed to one of the one or more secondary responder agencies.
In accordance with yet another aspect of the present disclosure there is provided A non-transitory computer readable memory containing instruction for emergency call management, the instructions when executed by a processor performing the method comprising: receiving an emergency call at an emergency service platform (ESP) providing an interface to one or more communication networks; receiving location information associated with the emergency call; identifying the location of the emergency call on a graphical map display; receiving a selection of the emergency call from a plurality of emergency calls displayed on the graphical map display; determining one or more secondary responder agencies for the selected emergency call; receiving a selection of a secondary responder agency from the one or more secondary responder agencies; and initiating a transfer of the selected emergency call to one of the one or more secondary responder agencies.
Although the following discloses example methods and apparatus including, among other components, software executed on hardware, it should be noted that such methods and apparatus are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware, or in any combination of hardware, software, and/or firmware. Accordingly, while the following describes example methods and apparatus, persons having ordinary skill in the art will readily appreciate that the examples provided are not the only way to implement such methods and apparatus.
It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Also, the scope of the teachings provided herein is not considered to be limited to the specific description of the embodiments provided herein. Embodiments are described below, by way of example only, with reference to
The ESP 102 receives communications from the various networks and converts the communications to a SIP based communication session with communication workstations 110, 112, 114, 116. Each position provides an operator client 110a for providing call management, identification and dispatch related to the selected emergency call. The map display 110b provides location information to identify the position of the particular emergency call or active or incoming emergency calls assigned to the PSAP 100. Each PSAP 100 will have multiple responders or operators 110, 112, 114, 116 for receiving and managing calls. In traditional system calls are assigned to operator positions based upon queue order. When a significant event occurs multiple calls may be received for the same event and be clustered in a geographical area. The disclosed system and method enable identification of incoming emergency calls on map displays 110b, 112b, 114b, 116b, and enable the operator to select specific calls on the map display which are transferred to their associated operator client 110a, 112a, 114a, 116a of the operator position by the emergency services platform 102. Calls can be assigned an incident identifier which can be displayed on the map display enabling easier identification incidents and related calls and to help in identifying call clusters related to the same incident.
The i3 event logging port is based on a web services (http post) and is strongly influenced by the logging services proposed in the NENA i3 functional specifications (008-003 Detailed Functional and Interface Specification for the NENA i3 Solution—Stage 3). Since not all of the events are relevant to answering/releasing calls from a map, a subset of the perceived relevant events are described here.
Operator Login EventThe Operator login event indicates that an operator has used a workstation to log into the ESP. Note that there may be me more than one login event when a workstation is equipped with multiple audio devices. Also, a logout event is also available to track the status of user agents.
This event looks like this:
This event is useful to compute which “agent”, in the <agent> field, is logged in at what “workstation”, which identifies a physical location of the operator in the <workstation> field. The “agent” value is also useful to correlate subsequent action of an agent, such as answering or releasing a call to a workstation.
The start call event indicates a new incoming call into the ESP: this event might not have the location of the caller.
This event looks like this:
The call identifier <callidentifier> is used to associate subsequent events to the call.
The location field <location> in the StartCall event, is most often empty or contains only a “.” This is because not many networks or devices are capable of sending the location (PIDF_LO) of a caller within the SIP INVITE. In those cases or if the location is only a reference, the ESP obtains the location of a caller by performing a HELD query to a LIS (location information system) or LLIS (legacy information system). In those cases, the MAP system can obtain the location from the HELD response event as shown below.
Note: Location related events will occur only for Call Type NG911.
When a call has not been received with location information or with location by reference, this event contains the call's location. The held field <held> contains the HELD response which contains the PIDF-LO which can be used to locate the call.
The answer event indicates that a call has been answered. When the call is answered by an operator using an ESP workstation, the <agent> field identifies that agent. In other cases, the agent field is empty or contains a “.” In these cases, the event should be ignored by the MAP system.
Indicates that a call has been terminated (all call legs have been released).
Since the ESP can act as a conference bridge, the call model implemented in the ESP, is one that allows for several participants to be partaking into a call. Each participant is represented by a call leg. A call is identified by a unique callIdentifier and the call legs are identified by unique mediaLabels.
By using other LogEvents then the ones described in this document, it is possible for a MAP system to track calls at the call leg level and provided information such as abandon calls status.
Each CCI positions equipped with the proper plugin, listens for HTTP POST requests on port 2069 (the port can be modified by configuration).
When an HTTP POST request is received by a CCI position, the sender can expect an HTTP response in all cases except in the case of a socket error.
A response is any one of HTTP 200 Ok, HTTP 400 Bad Request, and HTTP 500 Internal Server Error.
Three types of requests currently exist; the content types of the HTTP POST requests are expected to be “text/xml” with the following xml bodies:
When an operator is equipped with the Call Control Interface plugin, the state of the external link is provided on the operator screen. To maintain the state of the link “Ok” a Heartbeat requests must be received within 10 seconds of each other. That value can be modified by configuration.
Used to answer a specific call; the call identified by the callIdentifier tag received in the Start Call event must be used.
A call release request is used to release a call using the call leg identified by the callIdentifier tag received in the Start Call event.
eventType
Sent for every incoming call.
The Received SDP is sent for every VoIP incoming, transferred or outbound call. This event will only be provided in the phase 2 of the logging service development.
The HELD query is sent every time the system does an Held query. Note, the HELD queries performed for the purpose of a manual ALI query or for re-bids.
The HELD response is sent every time the system receives a Held query response.
The ECRF query is sent Sent every time the system does an ECRF/LoST query.
The ECRF response is sent every time the system receives a LoST response.
The VPC query is sent every time the system does a VPC query.
The VPC response is sent every time the system receives a VPC response.
The SRDB query is sent every time the system does an SRDB dip.
The SRDB response is sent every time the system receives a response from the SRDB.
The ALI query is sent every time the system does an ALI query. This event will only be provided in the phase 2 of the logging service development.
The ALI response is sent every time the system receives an ALI response. This event will only be provided in the phase 2 of the logging service development.
Sent for every outbound calls that have been has a consequence to the system receiving an inbound call. The outbound call could be towards a remote system or phone device or another type of device capable of handling a call or towards an operator position.
The answered call message is sent every time a call is answered.
The transferred call message is sent for every transfer or conference attempt.
The Hold call leg message is sent every time a call leg is placed on hold.
Sent every time a call leg is retrieved form hold
The Set Mute message is sent every time a call leg is muted.
The Remove Mute message is sent every time a call leg is unmuted.
The Set Privacy message is sent every time a call leg is set to privacy mode.
The Remove Privacy message is sent every time a call leg is removed from privacy.
Send every time two conversations or conferences are merged together. In following logs, the callIdentifier1 or callIdentifier2 can be used to reference any action to the call or call legs. Same applies to IncidentIdentifiers. This event can only occur on systems equipped with operator positions.
Send every time an outbound call is done by an operator. This event will only occur on systems equipped with operator positions.
Sent every time a call leg ends i.e. the media stream is terminated.
Sent at the end of a call when all call legs or media stream have been terminated.
The Login message is sent every time an operator logs in. This event can only occur on systems equipped with operator positions.
The Logout message is sent every time an operator logs out. This event can only occur on systems equipped with operator positions.
As per the i3 specs, a timestamp is represented by an ISO 8601 time point. An example of a timestamp is 2015-08-21T12:58.03.01Z. All time within the ESInet is represented as UTC (Zulu) time.
agencyOrElement
As per i3 specs, this tag should contain the domain name of an Agency (PSAP) or system (ESRP). For example esrp.state.pa.us. This tag is configurable as a string of characters (30 characters max.) in the incoming call policies.
callIdentifier
As per the i3 spec, the first element in the first ESInet which handles a call assigns the Call Identifier. The form of a Call Identifier is a URI consisting of the string “_CI_”, a unique string, the “@” character, and the domain name of the element that first handled the call.
For example: “_CI_a56e556d871@esrp.state.pa.us”. The unique string must be unique for each call the element handles over time. The length of the unique string must be between 10 and 30 characters.
If the NENA i3 Callldentifier is not received in the incoming call signalling, we use our internal session id number prefixed with “_CI_” and suffixed with @“agencyOrElement”.
incidentIdentifier
As per the i3 spec, a real world occurrence such as a heart attack, car crash or a building fire for which one or more calls may be received is an Incident. Examples include a traffic accident (including subsequent secondary crashes), a hazardous material spill, etc. Multiple Calls may be associated with an Incident. An Incident may include other Incidents in a hierarchical fashion. The form of an Incident Tracking Identifier is a URI consisting of the string “_II_”, a unique string, the “@” character, and the domain name of the entity that first declared the incident. For example: “_II_a564w443112z@esrp.state.pa.us”. The unique string must be unique for each Incident the element handles over time. One way to create the unique string is to use a timestamp with a suffix that differentiates multiple Incidents if they could be created by an element in the same instant. Implementations using multiple physical devices to implement a redundant element may need an additional component to guarantee uniqueness. Incident Tracking Identifiers are globally unique. By definition, there is an Incident associated with every call. As a practical matter, there is at least one call associated with every Incident, except those incidents declared by an agent (such as a policeman observing a traffic incident). Incident Tracking Identifiers may be assigned to a call prior to determining what real world incident it actually belongs to.
If the NENA i3 incidentIdentifier is not received in the incoming call signalling, the session id number is used prefixed with “_II_” and suffixed with @“agencyOrElement”.
mediaLabel
A call on a B2BUA or on a conference bridge is constituted of at least 2 call legs, one for the caller and one for the called party. For a 3 party conference call, it is made of 3 call legs.
The i3 specs calls for the mediaLabel to be taken from the SDP Label Attribute (RFC4574). Because SDP mediaLabels are only unique within an SIP session when acting as B2BUA, this form of mediaLabel cannot be used to uniquely identify a call leg.
The i3 definition of a mediaLabel has been extended to uniquely identify each of the call legs and also to apply to non-VoIP call legs.
The form of a Media Label is a URI consisting of the string “_ML_”, the internal session id number, the “@” character, and the domain name of the element that first handled the call. For example: _ML_a56e556d871@esrp.state.pa.us”. The unique string is provided by the internal session id number prefixed with “_ML_” and suffixed with @“agencyOrElement”.
For VoIP calls only, a copy of the headers in the received INVITE message. This element will only be provided in the phase 2 of the logging service development.
incomingCallPolicy
Name of the Incoming Call Policy line that was used to process the call.
callType
Designates the type of call the call treatment that will be applied to the call. The following values exist:
-
- E911: Legacy call received from a CO or a VoIP provider.
- SR911: Legacy call received from a selective router capable of performing Selective and/or Fixed transfers.
- NG911: A location routing query (LoST) will be performed on the call.
- AdminEmergency: The call will ring as an admin call but the all of the 911 functions except i3 transfer queries are available.
- Admin: Administrative call treatment is applied.
signallingType
Type of signalling used for this call leg.
Physical location of the bearer circuit that is used for the call leg (Shelf, Slot, Span, Channel).
circuitId
Number representing the physical location of the bearer circuit that was used for the call leg (Shelf, Slot, Span, Channel).
trunkId
Trunk group id of the bearer channel that was used for the call leg.
ANI is Automated Number Identification. It is the telephone number of the calling party (phone number of the station originating the call).
aniDomain
For VoIP call legs only, it contains the telephone number and IP address or DNS of a VoIP device from which the call is originating.
DNIS is Directory Number Identification Service. For an inbound call leg, it is the telephone number that was dialled by the origination station. For an outbound call leg, it is the targeted station's telephone number. For outbound calls, this number can also be an ESRN used in i2 IP calls.
PaniPseudo ANI is sometimes called ESRK for Emergency Service Routing Key. Normally associated to cellular emergency calls, it is a 10 digit number that uniquely identifies call. It is used to correlate the emergency services call with an emergency service zone and a record containing the location information for the call. A selective router uses this number to route the call and a PSAP to query the ALI database.
For non-cellular call legs and non-VoIP call legs, this field can be identical ani field or may be left empty.
calerName
A name associated to the calling device. This service is not always available. The service requires to be supported by the signalling method by which the call reached the system and it requires to be enabled by the incoming call service provider
Note that on legacy 911 trunks (CAMA trunks) this information is not available.
For VoIP calls, it contains the entire SDP (RFC2327 Session Description Protocol) which is a description of the media that is received in a SIP INVITE.
heldDomain
Address that was used to make an HELD query or address from which an HELD response was received. Normally this address should be the address of a LIS or a Legacy LIS.
heldPurpose
Purpose for which an HELD query is performed. The following values are possible:
-
- InitialLocation; HELD query was performed to get the initial location of a call i.e. the call was receive w/o any location information.
- Dereferencing; HELD query was performed to obtain location of a call which was received with a location reference. This value will only be provided in the phase 2 of the logging service development.
- Manual; HELD query was performed upon the request of an operator. This value will only be provided in the phase 2 of the logging service development.
- AutoRebid; HELD query was automatically performed to update the location of a moving caller. This value will only be provided in the phase 2 of the logging service development.
A URI identifying the device for which a location is required or a uri that can be used to find the location of a device (deferring). For legacy calls tel URIs will be used.
responseCode
Context dependent response code; in the case of HELP, LoST and VPC queries are HTTP response codes or an error message string. For endMedia and end call, they are release cause as per Q.850
Contains the XML portion of the HELD response. Normally it should contain the following elements:
ecrfDomain
Address that was used to make an LoST query or address from which an LoST response was received. Normally the specified address maps to an ECRF.
As per the i3 specs, all SIP-based emergency calls pass location information either by value (PIDF-LO) or by reference (Location URI) plus a “Service URN” to an Emergency Services Routing Proxy (ESRP) to support routing of emergency calls. The ESRP passes the Service URN and location information via the LoST interface to an Emergency Call Routing Function (ECRF), which determines the next hop in routing a call to the requested service. The ECRF performs the mapping of the call's location information and requested Service URN to a “PSAP URI” by querying its data and then returning the URI provided. Using the returned URI and other information (time-of-day, PSAP state, etc.), the ESRP then applies policy from a Policy-based Routing Function (PRF) to determine the appropriate routing URI.
When a call is not received with a service-urn, the service-urn is provided by the incoming call policies.
ecrfPurpose
Purpose for which a LoST (ECRF) query is performed. The following values are possible:
-
- routing; a LoST query to an ECRF is performed to get routing information.
- transfer a LoST query to an ECRF is performed to get transfer information.
Specifies the location for which a LoST query is attempted i.e. the location for which routing or transfer information is to be retrieved. The location can be in civic or geodic format.
LoSTContains the XML portion of the LoST/ECRF response
vpcDomain
Address that was used to make a VPC query as per NENA 12 or address from which a VPC response was received.
An Emergency Services Routing Number is a 10-digit number that is returned by a VoIP Positioning Center and that is to be used to route the call.
EsqkAn Emergency Services Query Key is digit string that is returned by a VoIP Positioning Center and that uniquely identifies an ongoing emergency services call. It is used to correlate the emergency services call with the a record containing the location information for the call. It is to be used by a PSAP to query the ALI database.
EsnAn Emergency Service Number is a three to five digit number representing a unique combination of emergency service agencies (Law Enforcement, Fire, and Emergency Medical Service) designated to serve a specific range of addresses within a particular geographical area, or Emergency Service Zone (ESZ). The ESN facilitates selective routing and selective transfer, if required, to the appropriate PSAP and the dispatching of the proper service agency (ies).
aliLink
An name (string of characters) that identifies a link or a set of link going to an ALI database (could be virtual link when IP is used).
aliResponse
Contains the raw response received from an ALI database truncated at 512 characters.
Contains the resulting destination address (after outgoing call policy treatment) for a routed call.
ReasonA text string <reason> for choosing that route. It can take the following values:
-
- normal; initial (top priority) route
- overflowMax; when the maximum number of calls on a previous route was exceeded.
- overflowNone: no operators are available on that route.
- alternate: a failure as occurred on the previous route.
- recording: a recording leg is being created.
A text string that identifies the route that was chosen.
AttemptNumber of attempts made on this route.
PriorityThe priority assigned to this route based on the routing policies.
aniTranslated
Contains the ANI of the outbound call after outgoing call policy treatment (see ani).
dnisTranslated
Contains the DNIS of the outbound call after outgoing call policy treatment (see dnis).
callerNameTranslated
Contains the Caller Name of the outbound call after outgoing call policy treatment (see callerName).
transferTarpet
Identifies the transfer target after outgoing call policy treatment.
outboundTarpet
Identifies the outbound call target after outgoing call policy treatment.
voiceQOS
For VoIP calls, provides quality indicators for the call leg that was terminated.
-
- medialpSourceAddr; bearer (audio stream) source IP address of the call leg.
- medialpDestAddr; bearer (audio stream) destination IP address of the call leg.
- mediaUdpRtpSourcePort; bearer (audio stream) source port address of the call leg.
- mediaUdpRtpDestPort; bearer (audio stream) destination port address of the call leg.
- mediaNumOfIpPktRxed; number of IP packets received on bearer (audio stream) port used for the call leg.
- mediaNumOfIpPktTxed; number of IP packets transmitted on bearer (audio stream) port used for the call leg.
- mediaNumOfIpErroredPktRxed; number of IP packets received with an error on bearer (audio stream) port used for the call leg
- mediaNumOfRtpPktRxed; number of RTP packets received on bearer (audio stream) port used for the call leg.
- mediaNumOfRtpPktTxed; number of RTP packets transmitted on bearer (audio stream) port used for the call leg.
- mediaNumOfRtpPktLost; number of RTP received packets lost on bearer (audio stream) port used for the call leg.
- mediaNumOfRtpPktDiscarded; number of RTP received packets discarded (late arrival, too far out of sequence, error, . . . ) on bearer (audio stream) port used for the call leg.
- mediaRtpJitter; amount of RTP jitter for the received packets on bearer (audio stream) port used for the call leg.
- mediaRtpLatency; amount of RTP delay for the received packets on bearer (audio stream) port used for the call leg.
- mediaNumOfRtcpPktRxed; number of RTCP packets received on bearer (audio stream) port used for the call leg.
- mediaNumOfRtcpPktTxed; number of RTCP packets transmitted on bearer (audio stream) port used for the call leg.
- mediaFarEndPacketLostPercentage; percentage of packet lost declared by the far end of the bearer (audio stream) port used for the call leg. Requires RTCP.
- mediaFarEndCumulativePacketLost; number of packet lost declared by the far end of the bearer (audio stream) port used for the call leg. Requires RTCP.
- mediaFarEndInterarrivalJitter; amount of RTP jitter declared by the far end of the bearer (audio stream) port used for the call leg. Requires RTCP.
User name of the logged agent.
agentRole
Role that was assigned to the agent when the log in occurred.
tenantGroup
Identifies the Tenant Group to which the operator physical position pertains to. This may not be provided or it could be left empty in some system where only one tenant exits.
operatorId
An index that is assigned to the operator's physical position.
Host name of an operator workstation.
Although certain methods, apparatus, and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. To the contrary, this patent covers all methods, apparatus, computer readable memory, and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
Each element in the embodiments of the present disclosure may be implemented as hardware, software/program, or any combination thereof. Software codes, either in its entirety or a part thereof, may be stored in a non-transitory computer readable medium or memory (e.g., as a RAM, ROM, for example a non-volatile memory such as flash memory, CD ROM, DVD ROM, Blu-ray™, a semiconductor ROM, USB, or a magnetic recording medium, for example a hard disk). The program may be in the form of source code, object code, a code intermediate source and object code such as partially compiled form, or in any other form. The software is executed by one or more processors using instructions for performing system and method for risk assessment, anonymization strategy and dataset anonymization. The dataset may be stored locally or remotely on network based storage. The dataset may be saved as a new dataset or portion thereof.
It would be appreciated by one of ordinary skill in the art that the system and components shown in Figures may include components not shown in the drawings. For simplicity and clarity of the illustration, elements in the figures are not necessarily to scale, are only schematic and are non-limiting of the elements structures. It will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims.
Claims
1. A method of emergency call management, the method comprising:
- receiving an emergency call at an emergency service platform (ESP) providing an interface to one or more communication networks;
- receiving location information associated with the emergency call;
- identifying the location of the emergency call on a graphical map display;
- receiving a selection of the emergency call from a plurality of emergency calls displayed on the graphical map display;
- determining one or more secondary responder agencies for the selected emergency call;
- receiving a selection of a secondary responder agency from the one or more secondary responder agencies; and
- initiating a transfer of the selected emergency call to one of the one or more secondary responder agencies.
2. The method of claim 1 wherein identifying the location information comprises providing location information from the ESP to a map server by a National Emergency Number Association (NENA) i3 event logging protocol to provide location and status information associated with the emergency call, the map server providing mapping data to the graphical map display based upon the received location information.
3. The method of claim 2 wherein the selection of the emergency call from the graphical map display further comprises communicating, via a call control interface to the responder client, a call identifier associated with the selected emergency call.
4. The method of claim 3 wherein receiving the selection of the selected emergency call comprises the responder client requesting to the ESP to transfer the emergency call to the one of the one or more secondary responder agencies based on the call identifier associated with the emergency call.
5. The method of claim 4 wherein the ESP routes the emergency call to the associated one of the one or more secondary responder agencies and updates status information associated with the emergency call to the map server.
6. The method of claim 5 graphical map display provides a geographical map and identifies a plurality of emergency calls wherein a particular emergency call can be selected and identified to the operator position.
7. The method of claim 1 wherein one or more emergency calls are associated with an incident identifier.
8. The method of claim 7 wherein an incident having more than one associated emergency call has a common identification characteristics on the graphical map display based upon the incident identifier.
9. The method of claim 2 wherein the ESP is associated with multiple public safety access points (PSAP), each PSAP associated with one or more operator positions wherein the ESP determines the PSAP assigned to the received emergency call and routes the call to the determined PSAP.
10. The method of claim 9 where the ESP routes the emergency call to the determined PSAP based upon one or more of: location information associated with the emergency call, the incoming network, an incoming trunk, communications protocol, and an originating identification number.
11. The method of claim 10 wherein the map server receives identification of the PSAP associated with the emergency call via the i3 event logging protocol and displays the emergency call information on the graphical map displays of the operator positions associated with the determined PSAP.
12. The method of claim 1 wherein the receiving location information is provided by automatic location information or radio resource location services protocol (LCS protocol).
13. The method of claim 1 wherein the call is transferred to the operator position when the emergency call is selected.
14. The method of claim 1 wherein determining the one or more secondary responder agencies for the selected emergency call further comprises querying an emergency call routing function to determine the one or more secondary responder agencies.
15. The method of claim 1 wherein the secondary responder agencies is selected from the group comprising:
- a police service;
- a fire service; and
- an emergency medical service.
16. A system of emergency call management, the system comprising:
- an emergency service platform (ESP) interfacing to one or more communications networks for receiving emergency calls originating from the one or more communications networks;
- a map server for receiving location information from the ESP associated with the receive emergency calls; and
- a public safety access point (PSAP) coupled to the ESP and map server, the PSAP comprising one or more operator positions; each operator position comprising: a graphical map display for receiving mapping data from the map server and receiving a selection of an emergency call on the display; and a responder client coupled to the graphical map display for receiving identification of the selected emergency call and for requesting from the ESP that the emergency call be directed to one of the one or more secondary responder agencies.
17. The system of claim 16 wherein displaying the location information comprises providing location information from the ESP to the map server by a National Emergency Number Association (NENA) i3 event logging protocol to provide location and status information associated with the emergency call, the map server providing mapping data to the graphical map display of each operator position based upon the received location information.
18. The system of claim 17 wherein the selection of the emergency call from the graphical map display further comprises communicating, via a call control interface to the responder client, a call identifier associated with the selected emergency call.
19. The system of claim 18 wherein receiving the selection of the selected emergency call comprises the operator position requesting the ESP transfer the emergency call with the call identifier associated with the emergency call.
20. The system of claim 19 wherein the ESP routes the emergency call to the selected one or the one or more secondary responder agencies and updates status information associated with the emergency call to the map server.
21. The system of claim 16 wherein the graphical map display provides a geographical map and identifies a plurality of emergency calls wherein a particular emergency call can be selected and identified to the operator position.
22. The system of claim 16 wherein the ESP is associated with multiple PSAPs, each PSAP associated with one or more operator positions, wherein the ESP determines the PSAP associated with a received emergency call and routes to the determined PSAP.
23. The system of claim 22 where the ESP routes the emergency call to the determined PSAP based upon one or more of: location information associated with the call, the incoming network, an incoming trunk, communication protocol, and an originating identification number.
24. The system of claim 16 wherein the map server receives identification of the PSAP associated with the emergency call via the i3 event logging protocol and displays the emergency call information on the graphical map displays of the operator positions associated with the determined PSAP.
25. The system of claim 16 wherein the call is transferred to the operator position when the emergency call is selected.
26. The system of claim 16 wherein the emergency service platform transfers the emergency call to an operator position using a session initiated protocol (SIP).
27. The system of claim 16 wherein the emergency service platform queries an emergency call routing function to determine the one or more secondary responder agencies.
28. The system of claim 16 wherein the secondary responder agencies is selected from the group comprising:
- a police service;
- a fire service; and
- an emergency medical service.
29. A non-transitory computer readable memory containing instruction for emergency call management, the instructions when executed by a processor performing the method comprising:
- receiving an emergency call at an emergency service platform (ESP) providing an interface to one or more communication networks;
- receiving location information associated with the emergency call;
- identifying the location of the emergency call on a graphical map display;
- receiving a selection of the emergency call from a plurality of emergency calls displayed on the graphical map display;
- determining one or more secondary responder agencies for the selected emergency call;
- receiving a selection of a secondary responder agency from the one or more secondary responder agencies; and
- initiating a transfer of the selected emergency call to one of the one or more secondary responder agencies.
Type: Application
Filed: Dec 1, 2014
Publication Date: Mar 26, 2015
Patent Grant number: 9426304
Inventors: Daniel Biage (Gatineau), Gilles Ferland (Kingston)
Application Number: 14/556,852
International Classification: H04M 11/04 (20060101); H04W 64/00 (20060101); H04M 3/54 (20060101); H04W 4/22 (20060101);