Emergency communications over LTE and IMS: Unresolved issues and risks

As emergency calls move to newer technologies like Long-Term Evolution (LTE), several potential technical problems have been identified. They can happen for various reasons, such as the configuration of the mobile network, limitations in the user’s device or how call information is handled during transmission. Another key issue is the lack of proper, real-life testing before emergency systems are put into use. In many cases, mobile networks, user devices, and PSAP systems are not tested together. As a result, serious problems may only be discovered during actual emergencies, which creates risks for users. Regular and complete testing of all parts of the emergency communication system is essential to detect and fix these issues before they affect people in real-life situations.

This blogpost provides a summary of the most important issues EENA members have reported. Its purpose is to support ongoing improvements in emergency communications. By sharing these insights, EENA hopes to contribute to a constructive dialogue between network operators, public authorities, standardisation experts and other stakeholders.

If these challenges are not properly addressed, there is a risk that emergency calls may not function as expected in certain situations. This could limit access to 112 services, affect the ability of PSAPs to reach callers or determine their location and reduce the effectiveness of response efforts. Our aim is to help ensure that emergency services remain accessible, reliable and fully functional across all networks and scenarios.

VoLTE roaming incompatibility may prevent emergency calls while abroad

Emergency calls over LTE may not function reliably when users are roaming, due to the limited availability and inconsistent implementation of VoLTE roaming across mobile networks. In some cases, this lack of compatibility can prevent travellers from reaching 112 in a foreign country, particularly in networks that do not provide fallback to older voice technologies. This issue has previously been raised by EENA in the context of cross-border emergency communications, but challenges remain. Ensuring that VoLTE roaming supports emergency services effectively requires coordinated efforts between mobile operators, public authorities and emergency service providers. Without such alignment, access to emergency assistance while abroad cannot be fully guaranteed.

Unavailability of PSAPs to callback the person in an emergency

• PSAPs can’t callback without the caller’s number: Some emergency calls made from mobile phones over VoLTE or Wi-Fi include the caller’s phone number (MSISDN) only in a SIP field called the P-Asserted-Identity (PAI). However, some PSAP systems are still configured to rely solely on the FROM field, which may not contain the caller’s number. If the PSAP cannot read the PAI field and the call drops, it may be impossible to call the person back. Updating PSAP systems to correctly process the PAI field is essential to ensure reliable identification and callback capabilities for all IP-based emergency calls.
  
• International roaming – anonymous emergency calls: Most mobile networks use S8 Home Routing (S8HR), which means that when someone is roaming, their data and calls go back to their home network. However, emergency calls are different as they use Local Breakout (LBO), which allows the call to go directly to the local PSAP. When a roaming phone tries to make an emergency call, it first tries to connect and authenticate with the visited network. But if there is no connection between the visited and home networks for IMS, the authentication fails. In this case, the call is still allowed and sent as an anonymous IMS emergency call, as defined by 3GPP rules. This works as a backup, but it has some problems. If mobile networks do not have proper agreements or if the phone is not correctly set up, the call might not work. Also, in this unauthenticated state, the phone cannot send SMS, so services like AML over SMS won’t work. And because the call is anonymous, the PSAP cannot call the person back if the call drops. One possible solution could be to give the phone a temporary number for a short time, so the PSAP can try to call back.

• Limited Service State (National roaming): In Limited Service State (LSS), a mobile phone is not attached to a network for regular service but can attempt to connect in “emergency mode.” It should search for any available network that allows emergency calls, regardless of the user’s operator. Some LTE networks support unauthenticated IMS emergency calls in this state, but others may require IMS registration before accepting the call. If the network does not support emergency IMS procedures without registration, the call may fail. In addition, emergency features such as location transmission (for example, via AML) typically do not work in LSS, since they require data or SMS services and a registered SIM.

• SIP transition breaks PSAP callback identity presentation: When emergency services move to SIP-based networks, such as VoLTE or other IP systems, some unexpected problems can appear. One issue is that calls made by PSAPs to users using “112” as the caller ID are sometimes rejected by Session Border Controllers (SBCs) in mobile networks. This did not happen in older circuit-switched systems, where such calls were usually accepted without problems. These rejections often happen inside the network and are not visible to PSAP staff, which makes it hard to detect and fix the issue. In SIP, many networks use strict rules to check the “From” or “P-Asserted-Identity (PAI)” fields in order to stop fraud or identity spoofing. Since “112” is a short code and not a full subscriber number, can be rejected because it does not meet the requirement for a valid E.164 number or a properly authenticated identity.
  
• Callbacks not accepted on non-smart phones: An issue has been identified with some mobile phones (e.g. LG-B200E) which do not allow users to answer incoming calls from short numbers like “112”. While the call rings and appears on the screen, the user is prevented from accepting it, with a message like “Not allowed to approve.” This represents a serious problem for emergency callbacks, especially if the PSAP uses “112” as the visible caller ID. The issue may be limited to certain device models or firmware versions, but it highlights the need to test device compatibility and work with manufacturers to ensure emergency numbers are always reachable. Other non-smart phones may face similar callback issues. This may disproportionately affect elderly users or those in economically disadvantaged groups who rely on older or simpler devices.

The root cause of this issue is not yet confirmed, but several technical factors may be involved. Some older or entry-level mobile phones may include firmware restrictions that block answering calls from short codes, such as “112”, especially if these are interpreted as system or service numbers rather than valid caller IDs. In some cases, operator-specific configurations or regional software customisations could introduce unintended blocking behaviour. Additionally, non-smartphones often lack full support for SIP and modern emergency call handling standards, which may lead to inconsistencies in how such calls are processed or displayed.

Next-Generation routing fails without emergency identifiers

In some cases, the IMS network replaces the emergency service URN (for example, urn:service:sos.ecall) with a normal SIP URI before the call reaches the PSAP. This change creates problems for Next-Generation 112 systems, which use the URN to decide how to route the call based on the type of emergency service. When the URN is removed, ESInet systems cannot perform smart or function-based routing. One possible fix is to keep the URN in the SIP Request-URI and use the PSAP’s SIP address in the Route header. This method follows the rules in RFC 3261, works with IMS networks and keeps the URN available for correct routing by ESInet.

SMS to 112 not reaching the PSAP

Some problems may arrive when people try to send SMS to 112 over LTE networks. In some cases, the message does not reach the PSAP, depending on how the mobile network operator (MNO) handles SMS in emergency situations. It is not always clear whether the messages are being blocked, lost or sent to the wrong destination. This creates a serious concern for users who depend on SMS to ask for help, especially people who cannot make voice calls. We are looking for information on how different countries or operators manage SMS to 112 when using LTE-only networks. You can reach out to Cristina Lumbreras at [email protected] to share any information on this matter.

Conclusion

Emergency communications over LTE, IMS and other IP-based technologies have introduced important benefits, but also serious challenges. Our findings show that current networks and devices do not yet guarantee reliable emergency calling in all situations.

Problems such as missing caller identification, blocked callbacks, roaming failures, device incompatibility and the removal of routing information (like URNs) show that LTE and IMS emergency systems are still not fully mature. These issues affect both domestic and international users and can prevent people from receiving help when they need it most.

Another concern is the lack of complete testing before emergency systems are put into real use. Devices, networks and PSAPs are often not tested together, especially for roaming, callback handling and SIP identity verification. This makes it likely that problems will only appear during real emergencies, putting users at risk.

These findings are intended as a contribution to current technical and policy discussions in the field of emergency communications. EENA acknowledges the complexity of the systems involved and the important progress that has already been made by the industry and standardisation community. However, some challenges remain at the level of implementation, testing and coordination. We believe that sharing practical experience from the field can help all stakeholders better understand these issues and work together on sustainable solutions.

Before retiring legacy systems, public authorities, mobile operators and emergency service providers must work together to ensure the new technologies meet the same or better levels of accessibility, resilience and functionality. Emergency communications must never be compromised during the digital transition.

References

3GPP TS 23.167 – IP Multimedia Subsystem (IMS) Emergency Sessions

3GPP TS 24.229 – IP Multimedia Call Control Protocol based on SIP and SDP

RFC 3261 – SIP: Session Initiation Protocol, IETF

RFC 5031 – A Uniform Resource Name (URN) for Emergency Services, IETF

GSMA VoLTE Implementation Guide – Version April 2024 ETSI TS 126 269 V18.0.0 (2024-05) – LTE; IMS emergency calls; eCall support