Emergency-Call-Handling Integration
Solving a Customer Problem Across Systems, Vendors and Responsibility Boundaries
SIP • Cisco CUCM • Mobile Applications • Wi-Fi • APIs • Interoperability • Location Assistance • Solution Architecture
Some of the most interesting technical problems don't belong entirely to any one product. This project began when a large healthcare customer was modernizing its emergency-call-handling environment. Our mobile communications application was one component in a much larger architecture involving the customer's wireless network, enterprise communications platform and specialized emergency communications systems. The question sounded simple: What should happen when a mobile user places an emergency call? The answer crossed multiple systems, multiple vendors and an important responsibility boundary.
Start With the Boundary
The first thing to establish was what our application was — and what it was not. The application provides mobile communications functionality inside healthcare environments. It is not a 911, E911 or NG911 system in any way. That distinction mattered throughout the project. We could provide useful information and integrate with systems responsible for emergency communications, but we should not imply that the application itself performed functions belonging to those systems. The architectural problem therefore became:
How can the mobile communications environment assist the customer's emergency-call-handling architecture without assuming responsibility that belongs elsewhere?
Understanding the Environment
The customer was evaluating technologies from multiple emergency communications vendors. I participated in technical discussions with the customer, the vendors and our internal engineering teams to understand how the different architectures worked and what each required from us.
This was not simply a question of whether an API existed. We needed to understand:
- where the call originated
- how the call would be routed
- what location information was available
- how that information could be transported
- which system could interpret it
- which system was responsible for the final emergency-handling decision
Three practical approaches emerged.
Three Possible Architectures
Option 1 — Move the Emergency Call to Cellular
The simplest approach was to move the call out of the application and place it through the phone's native cellular calling environment. This had an important advantage: emergency calling then remained within the cellular ecosystem and the emergency-calling capabilities already associated with it. The tradeoff was that the call left the application's SIP communications environment. As a fallback architecture, however, it provided a practical solution that could be implemented relatively quickly.
Option 2 — Hand the Call to Another Application
Another possibility was to hand the emergency call to a specialized application provided by an emergency communications vendor. That application could then assume responsibility for its portion of the emergency workflow. This could provide tighter integration with the vendor's platform, but it also introduced dependencies on another application, another user experience and another integration path.
Option 3 — Keep the Call on SIP and Provide Location Assistance
The third approach kept the call within the SIP communications architecture. The challenge was location. A mobile device connected to hospital Wi-Fi does not inherently provide the same emergency-location model as a traditional fixed telephone. However, the mobile application could obtain useful network information, including the device's IP address and the BSSID of the wireless access point to which it was connected. Those values could help downstream systems associate the device with a physical area when the customer's infrastructure had the information necessary to make that association. The challenge was getting that information through the communications path in a useful and vendor-neutral way.
The Customer's Direction
The customer ultimately wanted a combination of approaches. Cellular calling could provide a practical fallback while the more integrated architecture was developed. For the longer-term solution, the goal was to keep the call within the SIP environment while making useful location-assistance information available to downstream systems. That required cooperation across several independent technology domains. No single vendor controlled the complete call path.
A Vendor-Neutral Interface
We wanted to avoid designing the mobile application around one emergency communications vendor's proprietary format. Instead, engineering added support for placing selected location-assistance information into configurable SIP headers. The exact header names could be configured for the deployment. The mobile application could provide available network information, and the communications path could preserve or transform that information as required by the customer's environment.
Conceptually, the flow became:
- Mobile SIP Client
- SIP signaling containing location-assistance information
- Communications Platform / Enterprise PBX
- Customer Emergency-Call-Handling Infrastructure
This kept the mobile side relatively generic. The downstream environment remained responsible for interpreting the information and using it appropriately.
Building the MHVG Side
For deployments using MHVG, I developed the functionality required to handle the new signaling. MHVG could identify the configured SIP information, preserve it as the call moved through the system and, where necessary, present it in the form expected by the next communications component (SIP INVITE headers). This was intentionally configurable. The goal was not to hard-code one customer's emergency architecture into the communications platform. It was to provide a reusable integration mechanism. That made the feature useful beyond the original project.
Cisco CUCM Integration
Other deployments used endpoints registered directly with Cisco Unified Communications Manager rather than MHVG. That required a different implementation path. I worked with SIP Normalization Scripts using Lua in CUCM to manipulate the signaling as required while preserving the same architectural concept. The Lua scripts are also in use when deployment uses MHVG, tied to the SIP trunk.
The technology changed; the interface principle did not. The mobile application supplied useful information. The communications infrastructure transported it. The customer's emergency systems remained responsible for the functions they were designed to perform.
Implementation Took Time
Complex integrations involving multiple companies rarely move at the speed of a single engineering team. The cellular fallback could be implemented in a matter of months. The specification for the SIP-based approach was developed early, and support could then be added to the communications platform and mobile application. Other parts of the customer ecosystem moved on their own development and deployment schedules. From the initial discussions through the broader implementation, the project unfolded over roughly two years. That is an important part of solution architecture that diagrams rarely show.
A technically sound solution must also survive:
- different product roadmaps
- different release schedules
- vendor dependencies
- customer testing
- security and operational reviews
- real-world deployment constraints
Acting as the Technical Bridge
My role was not limited to implementing one component. I spent considerable time acting as the technical intermediary between the customer, emergency communications vendors, internal engineering, enterprise communications infrastructure and the mobile application. Each participant naturally understood its own system best. The difficult part was understanding enough of all of them to see the complete path. That meant asking questions such as:
- Where does this information originate?
- Which system can modify it?
- What survives each SIP hop?
- What does the next platform expect?
- Who owns the location data?
- What happens when a component is unavailable?
- Which system should be responsible for what?
Customer-Facing Architecture Is More Than Product Knowledge
This project is a good example of why I enjoy customer-facing technical architecture. Knowing your own product is necessary. It isn't sufficient. A customer does not experience a product in isolation. They experience a complete system made from networks, applications, communications platforms, identity systems, security controls, vendor products and operational processes. When something crosses those boundaries, someone has to understand enough of the complete architecture to help everyone arrive at a workable solution.
In this project, the answer wasn't simply:
Add a SIP header.
The actual solution required understanding the emergency communications problem, evaluating alternative architectures, defining responsibility boundaries, designing a generic integration mechanism, implementing portions of it across different communications platforms and helping multiple organizations understand how the pieces fit together.
The Result
The resulting architecture provided several useful capabilities:
- A practical cellular fallback
- Vendor-neutral SIP location-assistance signaling
- Support within MHVG
- Integration with Cisco CUCM
- Flexibility for different downstream systems/vendors
- A clear boundary between communications assistance and emergency-call-handling responsibility
The technical mechanism was relatively small; the architecture around it was not. That distinction is what made the project interesting.