Quoting Henning:"At least in the US, many of the WebRTC services would be considered "interconnected VoIP", so they are indeed subject to 911 obligations."James
BTW- yeah, I know I'm picking a fight - but Jari singled this topic out as an example of how various regions of the world differ on how they handle certain applications, emergency services being one of a very short list he mentioned.
I will agree with Richard that we shouldn't focus discussion on this list on the regulatory environment. But I think there's a piece of this that goes to the heart of what WebRTC can be, and that is whether the point is to create a new infrastructure that becomes part of "interconnected VoIP" or to create a set of building blocks that allows real-time communications without that infrastructure.
I personally believe that is the latter, rather than the former, that is the promise of WebRTC. If I can make peer-to-peer, real time communications a part of any _javascript_ application downloaded into a browser, I can create imbue those applications with a far richer environment. They can be social in ways that they are not now; they can be interactive in ways which they are not now; they can be creative in ways that they are not now (at least not without limiting the experience to those with specific plugins).
Can you use that interactivity to create a telephone, which you then hook up to SIP islands or the PSTN via gateways? Sure, if that's what you want to do.
But I don't think that's the major goal, and I have argued against a focus on that interoperability as a major driver of work in WebRTC. It looks shiny, as a way to get early users and quick deployment. But there's a lot of hooks attached to that lure, and I'd personally advise anyone developing for WebRTC to focus on native WebRTC apps. Those will be the ones that wow users and drive us forward.
Again, just my personal view,
Ted Hardie