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