The most difficult part for any emergency calling system is location delivery. WebRTC probably doesn't have much impact on emergency calls if all the calls traverse a server of some kind and if the caller location can be looked up based on caller IP addresses, but once you have the end system involved in location determination (e.g., for mobile devices or for DHCP-delivered location), it has to know when a call is an emergency call as you otherwise end up providing location for every call, which is non-ideal from a privacy and battery perspective.
At least in the US, many of the WebRTC services would be considered "interconnected VoIP", so they are indeed subject to 911 obligations.
Henning
On May 26, 2013, at 3:57 PM, Richard Barnes < rlb@xxxxxx> wrote: Indeed, there has already been some coordination between the groups, going back about a year:
So my read of the situation is much less dire than James's. As I understand it, the upshot of the initial coordination discussions is that there's not a single, clear "RTCWEB+ECRIT" story. Instead, there are a few ways you can put them together. In the short run, without upgrading PSAPs, RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP, either at the server, or at the client using something like SIP-over-WebSockets. In the long run, PSAPs can just advertise an RTCWEB service like they would advertise a SIP service today (in LoST). Neither of these is incompatible with RTCWEB or ECRIT as they're being specified today.
I expect there are probably some ECRIT considerations that aren't naturally supported in RTCWEB. Things like real-time text come to mind. However, it doesn't seem to me that there's gross incompatibility.
--Richard
|