Does DEC112 work in other countries?
DEC112 soon goes live, but what happens if someone is traveling abroad and wants to use the emergency chat app in other countries. Certainly, there is way how DEC112 works in other countries – read how a very simple architecture achieves this.
When developing our App and core services we used our travelling time (business or leisure) to test how well DEC112 works in other countries. Our findings are that, no matter where you are, the app works well as long as there is data connectivity. But, messages are always routed to our default PSAP as there are no PSAP mappings available outside of Austria. One approach to overcome this is to create mappings for each country stored in the Austrian ECRF, which seems to be obvious, but there is a better answer.
Assuming each country runs an ECRF and ESRP (doesn’t have to be the DEC112 open source), where both support ETSI standardized interfaces (LoST and SIP, respectively) it is only necessary to have another ECRF to build a so called LoST hierarchy. In simple terms, such an ECRF would provide mappings to national ECRFs based on national boundaries. The LoST architecture uses the term Forest Guide (FG) to define such an element, because one may consider a national LoST hierarchy as many trees providing authoritative mappings (refer to https://tools.ietf.org/html/rfc5582). In our example we have a single tree (or ECRF) per country and three countries – A, B, and C.
Such an international FG knows about national service regions (boundaries) and how to contact the respective national LoST Service (ECRF A, ECRF B, ECRF C …) as to the left of the drawing above. By the way, this concept is very similar to the Domain Name System (DNS), but let’s consider the following example:
Somebody from Country A has a configured DEC112 app, meaning that any emergency text message is sent to the local ESRP A. In the case this person uses DEC112 in the home country, ECRF A provides any national mapping and messages are accordingly forwarded.
Travelling to Country C would not change the app configuration – messages are still sent to ESRP A (arrow 1, as to the right of the drawing above), but, as ECRF A does not have a mapping requested (2) by the ESRP for the location provided (somewhere in Country C), it simply asks the Forest Guide (3). The FG responses (4) with a redirect message (iteration), telling ECRF A that ECRF C has the authoritative mapping for Country C (or the location provided in the request). As next step, ECRF A sends a request (5) to ECRF C and gets the PSAP URI of PSAP C (6), which it returns (7) to the ESRP A (recursion). Finally, ESRP A forwards (8) the message to ESRP C, which knows how to contact PSAP C (9).
The big advantage of this approach is that each country maintains its own infrastructure and authoritative mappings. The FG just redirects to national ECRFs and does not need to know about national PSAPs (and how they are organized). Further, national borders are not changing that often so there is basically little effort in running a Forest Guide and peering agreements are only necessary between ECRFs for mapping and ESRPs for international routing. The only open point remaining is: who takes the responsibility to run the Forrest Guide… Keep you updated in the next blog.
