On Sat, May 25, 2013 at 12:10 AM, Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> 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.
regards,
Ted Hardie