ietf
[Top] [All Lists]

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

2013-05-27 20:35:51
Keep in mind, though, that the binary decision is usually per site.  So if
the PSAP is web-enabled, the user can provide location to 911.gov, and not
anyone else.

That seems like a solution that's more likely to deploy than something that
requires the browser to distinguish emergency from non-emergency web apps.

--Richard


On Monday, May 27, 2013, Henning Schulzrinne wrote:

Agreed - this is not so much about standards, but developer awareness. If
we write any "how to" or similar informational documents, they should
probably contain that type of discussion.

There is a browser aspect, however: Right now, users only have a binary
choice about location disclosure, even though I suspect many users would be
fine with "location disclosure for 911 only", not "disclose my fine-grained
location for any purpose you like".

On May 27, 2013, at 1:51 PM, Richard Barnes <rlb(_at_)ipv(_dot_)sx> wrote:

Even for location delivery, there's not that much to say at the standards
layer.

For *delivery*, the story is the same as with signaling.  Either the
RTCWeb VoIP service can translate the location information to comply with
RFC 6442, or the PSAP can just build a web app that collects it however it
likes.

For *determination*, it's about the browser.  You can do browser-based
geolocation today, to "OK" quality.  Or the browser could implement the
GEOPRIV protocols to benefit from network-provided location.

All that's about implementation/deployment though.  I don't really see any
new standards there.

--Richard



On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne 
<hgs(_at_)cs(_dot_)columbia(_dot_)edu
wrote:

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.

Henning

On May 26, 2013, at 3:57 PM, Richard Barnes <rlb(_at_)ipv(_dot_)sx> wrote:

Indeed, there has already been some coordination between the groups, going
back about a year:
<http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf>
<http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt>

So my read of the situation is much less dire than James's.  As I
understand it, the upshot of the initial coordination discussions is that
there's not a single, clear "RTCWEB+ECRIT" story.  Instead, there are a few
ways you can put them together.  In the short run, without upgrading PSAPs,
RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP,
either at the server, or at the client using something like
SIP-over-WebSockets.  In the long run, PSAPs can just advertise an RTCWEB
service like they would advertise a SIP service today (in LoST).  Neither
of these is incompatible with RTCWEB or ECRIT as they're being specified
today.

I expect there are probably some ECRIT considerations that aren't
naturally supported in RTCWEB.  Things like real-time text come to mind.
 However, it doesn't seem to me that there's gross incompatibility.

--Richard




On Sat, May 25, 2013 at 10:18 AM, John C Klensin 
<john-ietf(_at_)jck(_dot_)com>wrote:



--On Saturday, May 25, 2013 10:10 +0300 Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:

...
I didn't know about the details of the emergency
communications situation. But it is always difficult to
balance getting something out early vs. compl


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