ietf
[Top] [All Lists]

Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)

2013-05-28 13:25:42
I would suggest we not try to sort out on this list which sorts of Internet
services are subject to American regulations.


On Tue, May 28, 2013 at 2:20 PM, James Polk <jmpolk(_at_)cisco(_dot_)com> wrote:

At 11:58 AM 5/28/2013, Ted Hardie wrote:

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


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



<Prev in Thread] Current Thread [Next in Thread>