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 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.