At 11:58 AM 5/28/2013, Ted Hardie wrote:
On Sat, May 25, 2013 at 12:10 AM, Jari Arkko
<<mailto:jari.arkko@xxxxxxxxx>jari.arkko@xxxxxxxxx> wrote:
James:
> did you know that you have a audio/video realtime interactive
communications WG churning out proposals and solutions that is
*actively* ignoring "emergency communications" in its entirety? No?
Look at RTCweb, which will become a dominant form of interactive
communications between humans in the near future. You have an
equally active WG in the same area that is addressing emergency
communications (ECRIT) that is further along/mature in its
documents (i.e., they've already produced the bulk of their RFCs,
specifically RFC 6443 and 6881).
>
> Given that young people already think contacting a local
emergency call center (PSAP) can or should be achievable through
SMS, IM, twitter and Facebook... just how long does anyone think it
will be before calling 911/112/999 will be requested or mandated
through WEBrtc/RTCweb?
>
> Waiting will only make it more painful to retrofit it into the
future RFCs produced by RTCweb.
I knew that WebRTC is happening fast, including implementations
coming out before standards. I don't think everyone have yet
realised the full impact this technology will have.
I didn't know about the details of the emergency communications
situation. But it is always difficult to balance getting something
out early vs. complete. I know how much pressure there is on the
working groups to keep up with things actually happening in the
browsers and organisations setting up to use this technology. Do you
think the retrofit will be problematic, and do you have a specific
suggestion about what should be included today?
Jari
I'm replying here, rather than down thread, because I believe it's
important to tackle two different statements here: one James' and one Jari's.
The first is James' that RTCWEB is ignoring Emergency
Services. Perhaps by "actively ignoring" James means that the
working group considered emergency services and made a decision he
did not agree with, which is that the baseline capabilities already
allows a PSAP or other emergency service to provide a WebRTC
application that would work to connect you to its emergency
responders, and that this was enough.
As context, it's very important to recognize that the WebRTC efforts
in the IETF and W3C *are not building a telephone into a
browser*. We could have done that in a few weeks. The groups
*are* creating building blocks that allow a javascript application
within a browser or mobile context to add peer-to-peer audio, video,
or data channels to whatever *its* application happens to be. That
application can be a game (we often use a poker game as an example
here), a puzzle (there's an example where you compete with a peer in
unscrambling a tiled video feed), or a pure data exchange (where
neither audio or video are passed).
In that context, the group considered two questions:
can you use the WebRTC building blocks to create an application to
talk to emergency responders?
should every application be required to have the ability to talk to
emergency responders?
It gave the answer to the first one as "yes", and I am convinced
that any emergency responder that wished to create such an
application could do so with the existing building blocks. A set of
emergency responders could even create and distribute one that was
highly generalized and took advantage of LoST's facilities to be
useful in many locations.
To the second question, the working group answered "no". There are
applications of WebRTC which are not general-purpose communications,
including some applications where there will be no audio or video at
all. Requiring that a puzzle should provide you 911 service because
it happens to provide have live video is not really
sensible. Fundamentally, making every application also be a
generalized telephony application with ECRIT support makes no more
sense here than it would for desktop applications; you could equally
require a text processor connected to the network to support texting
emergency responders--after all, it has the UI facilities and the
user's attention, right?
The second statement is Jari's, which seems to imply that the
implementations coming out before standards is a problem in the
WebRTC case. The implementers in this case are also very active
contributors to both the IETF and W3C efforts, and they are feeding
implementation experience into the process. That's a good thing,
since it is coming along with a willingness to change
implementations to match group consensus. That won't last forever,
obviously, but we have that now and should continue to take
advantage of it while we do.
That's my personal take, in any case, as someone who has been
actively involved in both efforts.
Ted - this view (I believe) doesn't reconcile with the view stated by
Henning's yesterday.
(truth be told, it's hard to separate Henning's stated views from his
official title and his official organization, given that he writes
the types of regulations the IETF community merely reads (about)...
"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."
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.
regards,
Ted Hardie