Developer Program - OpenScape First Response ESInet/NGCS Solution

The components in the OpenScape First Response ESInet/NGCS Solution are implement to be compliant to both the North American (NENA) and European (ETSI/EENA) standards. Projects outside North America and Europe will tend to use the ETSI/EENA standards, so the solution can be deployed anywhere in the world.

All external interfaces provided by the solution will be compliant to the applicable standards. This page will enumerate these interfaces and describe which standards apply. Internal interfaces between solution components provide by Unify/Atos will not be described here.

Incoming Emergency Call SIP Interface

All emergency calls arriving at the BCF interface to the ESInet are signaled via the Session Initiation Protocol (SIP). In North America, per the NENA standards, calls on this interface are expected to provide links to additional data structures in Call-Info headers, but the solution can handle calls without these links. Per ETSI/EENA standards the inclusion of links to additional data are optional and are only of interest to the PSAP.

The SIP interface to the NGCS solution is compliant with RFC 3261 and to the relevant sections of the NENA i3 document and ETSI TS 103 479.

This interface is represented by the dotted red line B in the diagram above.

There have been no changes to this interface in recent versions of the NGCS solution.

Incoming Emergency Call RTP Interface

The media for all emergency calls arriving at the BCF interface to the ESInet are carried using RTP, with the exception of Text to 911 calls where the message contents are carried via MSRP (Message Session Relay Protocol). Media carried via RTP include voice, video and Real-Time Text (RTT). The BCF will serve as an anchor point for all media streams entering the ESInet, where the media will be routed to the far-end PSAP (via the egress BCF) and also to the SIPREC recording server if recording is to be performed. Depending on the configuration of the network, the ingress BCF will either route the media to a media server bridge (a conference-aware configuration) or directly to the egress BCF (when ad-hoc conferencing is used).

The BCF RTP interface is compliant to RFC 3550. Note that the ability of the answering PSAP to understand the media being sent is dependent on the availability of the appropriate codecs.

This interface is represented by the dotted black line A in the diagram above.

There have been no changes to this interface in recent versions of the NGCS solution.

Outgoing Call to PSAP SIP Interface

Emergency calls leaving the egress BCF destined for a PSAP are signaled via the Session Initiation Protocol (SIP). All calls traversing this interface will have the additional SIP headers as required by the NENA and ETSI/EENA specifications (Emergency Call-ID, Incident-ID, Resource-Priority and any necessary Call-Info headers).

The outbound SIP interface from the NGCS solution is compliant with RFC 3261 and to the relevant sections of the NENA i3 document and ETSI TS 103 479.

This interface is represented by the dotted red line F in the diagram above.

There have been no changes to this interface in recent versions of the NGCS solution. In future versions of the NGCS solution, a History-Info header will be provided on all outbound calls, with details in the Reason parameter as to why the call was routed to the particular destination.

Outgoing Call to PSAP RTP Interface

The media for all emergency calls leaving the ESInet at the egress BCF interface going to a PSAP are carried using RTP, with the exception of Text to 911 calls where the message contents are carried via MSRP (Message Session Relay Protocol). Media carried via RTP include voice, video and Real-Time Text (RTT).

The egress BCF RTP interface is compliant to RFC 3550. Note that the ability of the answering PSAP to understand the media being sent is dependent on the availability of the appropriate codecs.

This interface is represented by the dotted black line G in the diagram above.

There have been no changes to this interface in recent versions of the NGCS solution.

SIP Event Package Interface

Both the NENA and ETSI/EENA standards define a set of interfaces whereby other functional elements can inform the ESRP of their operational statuses via event packages using SIP SUBSCRIBE and NOTIFY methods. The following event functions are supported:

• Queue State
• Abandoned Calls
• Security Posture
• Element State
• Service State

Note that the ESRP plays the role of the subscriber for all of the above event packages except for abandoned call notificationw where the ESRP plays the role of the notifier.

Basic SIP event package handling is supported as defined in RFC 3265. The actual event packages are defined in the NENA i3 architecture document. This interface is shown as the blue dotted line denoted with the letter 'K' in the diagram above.

The SIP event package handling is supported in the current version (V2R5) of the NGCS solution. No changes have been made to this interface in recent versions.

SIP Location Update Interface

The ETSI/EENA standard for emergency calling (TS 103 479) was updated in 2023 to identify a SIP interface between the calling user and the PSAP that can provide unsolicited location updates if a caller is in motion. Either a SIP reINVITE or a SIP UPDATE can be used to convey the updated PIDF-Lo.

This is a pass-through interface as far as the NGCS solution is concerned; the respective reINVITE or UPDATE would contain the appropriate parameters such that it belongs to the same SIP dialog as the initial call, and would pass through the BCFs and ESRP on its way to the PSAP. The appropriate SIP response would similarly pass through in the reverse direction. The NGCS components would not perform any functions on these transactions beyond normal SIP routing and transaction handling.

In addition to TS 103 479, the applicable specifications are RFC 3261 and RFC 3311.

This interface can be thought of as comprising the dotted red lines B and F in the above diagram (as well as their continuations between components internally).

This interface is newly defined and has not yet been tested in the NGCS solution. Testing will be planned for an upcoming release.

Dequeue Registration Service Interface

Both the NENA and ETSI/EENA specifications call for a web service to be provided by the ESRP such that a PSAP can register its ability to receive calls from that PSAP. Each potentially dequeueing PSAP provides a dequeue preference level to the ESRP, and the ESRP will use that preference level to determine which PSAP to send calls to.

This is a typical web service interface using HTTP, whereby the PSAP provides information about itself to the ESRP. At this time (as of OSFR V2R5) however, the solution does not support this interface.

This interface is represented in the above diagram by the line labelled 'K'.

This will be implemented in a future version of the NGCS solution.

Bad Actor Service Interface

Both the NENA and ETSI/EENA specifications call for a web service to be provided by the BCF such that a PSAP can mark a caller as a 'Bad Actor' and force special treatment to be given to any future calls from that caller (typically up to a specified time interval).

This is a typical web service interface using HTTP, whereby the PSAP provides information about the call source to the BCF. At this time (as of OSFR V2R5) however, the solution does not support this interface.

This interface is represented in the above diagram by the line labelled 'L'.

This will be implemented in a future version of the NGCS solution.

Location De-Reference SIP Interface

Location information for emergency callers is typically received as a location-URI in the initial SIP INVITE that starts the call. This location-URI must be de-referenced before it can be used to determine where the call is to be routed. This de-referencing is done by querying the Location Information Server (LIS), which is typically associated with the originating service provider.

The interface to the LIS uses the HTTP-Enable Location Discovery protocol. HELD is described in RFC 5985 and the implementation in the ESRP of the HELD query is compliant to this specification.

This interface is denoted by the dotted blue line designated 'C' in the above diagram.

There have been no changes made to this interface in recent releases.

Location to Service Translation Interface

As part of the normal emergency call routing process, the ESRP queries the Emergency Call Routing Function (ECRF) with a FindServiceRequest in order to determine which PSAP should receive the call under normal conditions. The ECRF is a geographical database of PSAP jurisdictional boundaries.

This query is performed using the Location to Service Translation (LoST) protocol. Lost is defined in RFC 5222. The ESRP supports the FindService query as specified in this RFC.

This interface is denoted by the dotted blue like marked 'E' in the diagram above. Note that the ECRF is one of the core services in an ESInet, but is provided by a third-party.

There has been no change to this interface in recent releases of the NGCS solution.

Additional Data Repository Query Interface

The NENA standards define the ability for an ESRP to query an Additional Data Repository (ADR) to retrieve data about a person making an emergency call. An ADR is normally associated with the originating service provider, and the data retrieved by the ESRP can be used in making routing decisions about the call.

The interface to the ADR is an HTTP GET, and data is retrieved in the form of XML MIMEs.

This interface is shown as a dotted blue line denoted with the letter 'D' in the diagram above.

The ETSI/EENA specifications define the use of an ADR only in the context of a PSAP, where a PSAP can retrieve information from an ADR for display on the call-taker's screen.

This interface is not currently supported in the V2R5 version of the NGCS solution. Plans are in place to support this in a future version.

Event Logging Interface

One functional element included in the OpenScape First Response Next-Generation Core Services solution is the Next-Generation Logging Service (NGLS). The NGLS implements a logging service as defined in the NENA standards; the ETSI/EENA standards do not specify a logging services so the NGLS will be primarily used in North American projects.

The NGLS supports the logging event interface as defined in the NENA i3 architecture standard. The various functional elements that comprise the NGCS solution (including third-party products) will generate log events and send them to the NGLS on this interface. The NGLS will store the received events and use this stored data to generate various reports.

This interface is denoted by the blue dotted line marked 'M' in the above diagram. Although the diagram shows this interface between the NGLS and ECRF, in fact the NGLS can receive log events from any functional element in the solution (including third-party elements and elements of PSAP solutions).

Originally, the logging interface was defined as a web service with the event data conveyed in XML format. In the latest version of the NENA i3 standard (v3, 2021) the event data is now defined using JSON. The NGLS (and the logging interface) was updated in the latest release (solution V2R5, NGLS V1R1) to support both XML format log events and JSON format log events.