Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - real-time text

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Feb 2013 16:39:00 -0800

Harald said:
"I object to requiring interworking with emergency services."

[BA] The concrete question is "what would such a requirement consist of?" beyond the use cases 
and requirements that are already in the document. 

Martin and I examined how WebRTC stacks up against PhoneBCP in draft-aboba-rtcweb-ecrit, 
and the most obvious gap (location) appears to be more in the balliwick of IETF GEOPRIV/W3C 
location APIs than WebRTC. 

Lots of stuff that *might* be useful in emergency services (e.g. SIP or XMPP-based instant 
messaging,  XMPP or data-channel based realtime text, video, etc.) looks like it could be 
implemented in WebRTC without adding any more native functionality, use cases or requirements.  
Just because we don't have a use case or requirement, doesn't mean it can't be done.  For
example, there is no use case for "playing an imaginary xylophone with your fingers" or 
"projecting a stream on a spinning TV", but it seems to be possible.

---

From: Ted Hardie <[email-masked]>
Date: Sat, 2 Feb 2013 18:55:48 -0800

> and requirements that are already in the document.

No, the concrete question is whether the requirement to interwork with
emergency services will constrain the design.  As you are well aware,
emergency services proceeds at a very different pace than much other
work, and imposing that constraint could be very limiting indeed.
Creating *a service* using WebRTC that connects to emergency services
is certainly feasible, because it can mimic other services that
already interwork; requiring that *all* services using WebRTC do so is
a non-starter.

Spoken as a long time watcher of ecrit, geopriv, and rtcweb, but not
as a chair or company rep, just to be clear.

regards,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Feb 2013 11:05:27 -0800

On 2 February 2013 18:55, Ted Hardie <[email-masked]> wrote:
> emergency services will constrain the design.

I think that Bernard was addressing that question directly.  Namely:
we do not need to constrain the design for it to be possible to
provide emergency services.

Of course, that is the communication needs of emergency service, not
necessarily the letter of regulation.  That might require some
compromise on the part of the emergency services (in the form of
gateways or other changes to how they accept "calls").  I'm highly
sympathetic to the view that emergency services should not be regarded
as special.  The argument goes: "If emergency services are special,
how do I know that the special parts work when I need them?  They
aren't used all the time."

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 3 Feb 2013 11:33:31 -0800

Martin said:

"I'm highly sympathetic to the view that emergency services should not be regarded as special.  The argument goes: "If emergency services are special, how do I know that the special parts work when I need them?  They aren't used all the time."

[BA] Exactly.   If all of the emergency services functionality that we need isn't already covered by mainstream WebRTC use cases and requirements, the answer isn't to change the use cases.   Even use cases that we expect to be frequently utilized will have bugs.   So why would anyone want to risk their life on non-mainstream use cases that are much less likely to be extensively used and tested?

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 04 Feb 2013 00:14:29 +0100

> [BA] Exactly.   If all of the emergency services functionality that we need isn't already covered by mainstream WebRTC use cases and requirements, the answer isn't to change the use cases.   Even u…
(changed subject line to emergency service access )

Right, the emergency calls need to be as mainstream as possible.
But there are RFCs about how emergency calls are expected to appear, and 
they require a couple of "special" actions from the client and service 
provider.
Since next generation emergency services are now planned based on these 
RFCs it is best to make sure rtcweb based systems can comply.

It is mainly:
-provide location
-use SIP
-use supported codecs for audio, video and real-time text
-either client or server use urn:service:sos.... addressing

In order to test if it really works, a method for testing is specified 
in RFC 6443, requesting automatic loopback of a couple of RTP packets, 
and an opportunity to verify that the right emergency service was reached.
(I am a bit afraid that the load of these test calls will be 
overwhelming for the network resources compared to real calls, and might 
need a rethinking, but they at least do not load any operational human 
call taker. So, the mechanisms you ask for are there.)

It is true with all features in rtcweb that they are not required to be 
used in all application implementations. But they need to be described 
and included in the support from the browsers and APIs.

Thus, for emergency services, I assume that we would need to specify 
protocol elements and API:s for approximately the following:

-Mark call as emergency call ( From application to browser )
-Provide location with the call
-Provide urn: address ( possibly, can also be handled by server )
-Provide call-back address
-Provide user modality and language preferences and capabilities.

This is not much and not much to vary between countries. If variations 
between countries are needed, they should be concentrated in the server.

/Gunnar

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Feb 2013 04:31:26 +0100

All of the mentioned features except loopback belong in signalling, not in rtcweb.

Gunnar Hellstrom <[email-masked]> wrote:

>
>> Martin said:
>>
>> "I'm highly sympathetic to the view that emergency services should
>not be regarded as special.  The argument goes: "If emergency services
>are special, how do I know that the special parts work when I need
>them?  They aren't used all the time."
>>
>> [BA] Exactly.   If all of the emergency services functionality that
>we need isn't already covered by mainstream WebRTC use cases and
>requirements, the answer isn't to change the use cases.   Even use
>cases that we expect to be frequently utilized will have bugs.   So why
>would anyone want to risk their life on non-mainstream use cases that
>are much less likely to be extensively used and tested?
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Feb 2013 09:03:34 -0500

> provide emergency services.
"the design" is not clear here.  If you mean:  it must be possible for
a WebRTC system to be built that connects with emergency services,
then we already agree.  If you mean *all WebRTC applications* must be
buit to interwork with emergency services then we disagree.  There are
clear use cases for games, chat roulette-style casual encounter
systems, and similar that do not have any need for PSTN gateways and
for which emergency services should not be expected.  We can discuss
it more in person at the meeting, but I don't see any reason to
revisit this decision.

Again, my personal view.

Ted

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Feb 2013 09:41:17 -0500

> Right, the emergency calls need to be as mainstream as possible.

For devices that make phone calls, this is a sensible statement.  But
we're not building phone-in-a-browser.  It's entirely possible to use
RTCWEB to set up a data channel between two consenting peers where
there is no audio, no video, and no real time text but, say, games
play exchanges.  And in cases where there are audio and video streams,
there is no requirement that this be a general facility.  Look, for
example, at the puzzlible application here:
http://cargocollective.com/mimmijostell/PROTOTHON-PROJECTS.  Expecting
that this is useful to contact emergency services doesn't make sense
to me personally.

> Since next generation emergency services are now planned based on these RFCs
> it is best to make sure rtcweb based systems can comply.
>
> It is mainly:
> -provide location

If you would like several months entertainment, please go back to the
ECRIT and GEOPRIV mailing lists and read up on how little emergency
services like trusting user generated location.  Then you might
consider working through how exactly we're going to get what they
would consider trustable location through browser chrome and into
javascript *that we know many come from an untrustable server* in a
way that doesn't provide a very nice attack surface indeed.

> -use SIP

In this case, that would have to be "know where there is a trustable
SIP gateway", right, since there is no requirement to use SIP in
WebRTC?

> In order to test if it really works, a method for testing is specified in
> RFC 6443, requesting automatic loopback of a couple of RTP packets, and an
> opportunity to verify that the right emergency service was reached.
> (I am a bit afraid that the load of these test calls will be overwhelming
> for the network resources compared to real calls, and might need a
> rethinking, but they at least do not load any operational human call taker.
> So, the mechanisms you ask for are there.)
>
> It is true with all features in rtcweb that they are not required to be used
> in all application implementations. But they need to be described and
> included in the support from the browsers and APIs.
>

If you would like to describe how to build an emergency service WebRTC
app, I see know problem in your doing so.  But requiring all
applications have this facility simply misses the point of the
technology.  To repeat myself, we are not building a technology for
creating phones in browsers.

Still speaking personally,

regards,

Ted Hardie