Hi Sergey
Thank you for your reply.
if(is_method("REGISTER")) { sl_send_reply("100", "Checking your credentials"); } else { sl_send_reply("100", "Attempting to connect your call"); }
I left auto_inv_100 to 1 but I am now experimenting with calling t_reply before doing the held lookup and that looks promising at the moment.
According to RFC5985 (https://www.rfc-editor.org/rfc/rfc5985.html) HELD request can contain "responseTime" attribute with values "emergencyRouting" and "emergencyDispatch". With high probability, your LIS server will get the first HELD request with "responseTime=emergencyRouting". That means do not require high accuracy of user location. In my opinion, you send the location of the last base station where the user registered last time. This a fast response.
And when the call is delivered to PSAP, your LIS server will receive a second HELD request with "responseTime=emergencyDispatch". On the second request, you need to return the real mobile user location. But at this time the call is answered and the location may be evaluated for several seconds.
We operate fixed line, no mobile service. So we know the exact location (postal address + building identifier (EGID)) at the time of the call.
It's also not about routing. Calls to the nearest PSAP are source-routed. So if a customer dials 112 we translate this to the nearest PSAP operating emergency service 112.
I'm just anticipating what could go wrong or cause delays in the chain to find out the best way to react to such issues.
Kamailio => HTTP => HELD-Server(inhouse) => HTTP => LIS-Server
PS: What I could not find in the Swiss NG112 documentation: If transmitting the location to the LIS server fails. Is the Geolocation header just ommited? Or is there a way to tell the PSAP there was a failure transmitting the location to the LIS Server?
Mit freundlichen Grüssen
-Benoît Panizzon-