On May 27, 2013 10:56 AM, "Henning Schulzrinne" <hgs@xxxxxxxxxxxxxxx> 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".
>
WebRTC is just a website in many respects.
I would like to see telcos get out of this starngely engineered and regulated world and just be a "dumb pipe" for smart emergency services
And, in its place, the relevant emergergency response stakeholders deblvelop 911.gov and when i need help i go to 911.gov and have a webrtc call to my relevant emergency agency, or sip://help@xxxxxxx .
And like root CA certs, the location disclosure is already approved by the browser vendors (giving user choices is not advised in emergencies)
CB
> On May 27, 2013, at 1:51 PM, Richard Barnes <rlb@xxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxx> 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@xxxxxxx> wrote:
>>>>>
>>>>>
>>>>>
>>>>> --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko
>>>>> <jari.arkko@xxxxxxxxx> 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. 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,
>>>>>
>>>>> James will probably have a different answer and perspective, but
>>>>> I suggest that retrofits of security-sensitive features are so
>>>>> often problematic to make "always" not much of an exaggeration.
>>>>>
>>>>> I don't think there is any general solution to the "early vs.
>>>>> complete" tradeoff [1], nor, as long as we keep trying to deal
>>>>> with things as collections of disconnected pieces rather than
>>>>> systems, to the issues created by WGs with significant overlaps
>>>>> in either scope or technology. What I think we can do is to be
>>>>> particularly vigilant to be sure that the two WGs are tracking
>>>>> and frequently reviewing each other's work. At least RTCWEB
>>>>> and ECRIT are in the same area, which should make that
>>>>> coordination easier than it might be otherwise.
>>>>>
>>>>> john
>>>>>
>>>>>
>>>>> [1] Watch for a note about this that I've been trying to
>>>>> organize for about two weeks and hope to finish and post this
>>>>> weekend.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>