On Tue, May 28, 2013 at 11:20 AM, James Polk <jmpolk(_at_)cisco(_dot_)com>
wrote:
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