Re: [rtcweb] RTCWEB and emergency services

Ted Hardie <> Tue, 27 September 2011 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59F6121F8C18 for <>; Tue, 27 Sep 2011 12:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Iow3zi+giJaU for <>; Tue, 27 Sep 2011 12:22:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 24A5D21F8BF7 for <>; Tue, 27 Sep 2011 12:21:51 -0700 (PDT)
Received: by yxt33 with SMTP id 33so7023915yxt.31 for <>; Tue, 27 Sep 2011 12:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IpRMaSlQ637Jk7BPrWtLOer8XTPYexquhhKnVbG6j20=; b=U4qMOqI2bd0IPtjBa6FdmPRpXDRHSxp8j5o1j0qG/zFA8V8X5vZfMdh0VSbsOABwut NVUS7GumnslkiSYamNH/XxGFmX2BTBJ5zXsLJRXzaTJUZoCFPxjk3HHWceYpK4OKmO6g gM3CF0zRolkp4XyHnxS7VyJVlaTjm8NADGMKI=
MIME-Version: 1.0
Received: by with SMTP id d16mr16331794yhi.40.1317151477269; Tue, 27 Sep 2011 12:24:37 -0700 (PDT)
Received: by with HTTP; Tue, 27 Sep 2011 12:24:37 -0700 (PDT)
In-Reply-To: <BLU152-W39115E9C2A50B4A634789093F00@phx.gbl>
References: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl> <> <BLU152-W39115E9C2A50B4A634789093F00@phx.gbl>
Date: Tue, 27 Sep 2011 12:24:37 -0700
Message-ID: <>
From: Ted Hardie <>
To: Bernard Aboba <>
Content-Type: multipart/alternative; boundary="20cf3010e3c5eb046404adf139ca"
Subject: Re: [rtcweb] RTCWEB and emergency services
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Sep 2011 19:22:06 -0000


On Tue, Sep 27, 2011 at 11:59 AM, Bernard Aboba

> It should therefore be understood that the burden for implementation of
> emergency services falls principally upon the operator of the service, and
> that the role of the RTCWEB implementer is to deliver basic capabilities and
> to enable an operator to add to this functionality, rather than providing
> for every possible need natively ("I want a pony").
> Ted Hardie said:
> "Do I understand you correctly to be saying "The emergency service must
> stand up an RTCWEB server which provides downloadable javascript
> applications, rather than presuming that other javascript applications
> provide this functionality."? "
> [BA] I'm saying that the provider of the RTCWEB service

I think where we diverged was in my interpretation of your statement
"operator of the service"; I assumed you meant emergence service.  You,
however, are seeing RTC Web sites as if it they provide a voice service.

Speaking personally, I don't think that is the right model.  I can see an
emergency service provider providing an RTCWeb service as part of its
efforts, just as it may accept IMs, text messages, and other non-traditional
communications.  But assuming that any provider of an RTCWeb application
must provide a method to reach emergency services does not make sense to
me.   It takes the "voice is a service" vs. "voice is an application"
discussion back a dozen years.  Downloaded javascript from a system presumed
to be malicious is not how you want to make your 911/112 calls.

Imagine the poker site example.  Can the poker site require that emergency
services folks have a login to its system in monitor state in order to
provide this service?  Probably not even for one jurisdiction, much less
many.   The only other way to accomplish that in a closed-system approach
like the poker site is to have every site have a gateway capable of reaching
emergency services, and a break-out method to "dial an emergency number".

Even this will fail for sites that provide rendezvous but do not remain part
of the calling infrastructure post facto.  In the dating site example, two
members may initiate calling via a web site.  Once the peer-to-peer flows
are set-up, they can continue chatting *even if they lose reachability to
the rendezvous web site*.   Unlike the poker site, there is no necessary
access to the rest of the application.

Despite our re-use, it is vitally important to remember that these
applications are not phones.  I could set up a WebRTC applications called
"Subtitle" (after the old improv game) in which I get video from one player
and audio from another in order to mash them up and show the results to a
third parties.  There would not necessarily even be a facility in such an
application to get audio and video from the same party--since that would be
contrary to the point of the game.

If you must describe in the terms of telephony, please circumscribe your
terms--"For RTCWeb applications intended to provide telephony services, the
following considerations apply...."  But generalizing the whole application
space to telephony, even for the benefit of emergency services, is not where
I think we ought to go.

Speaking personally and without hats,


> is ultimately responsible for satisfying the regulatory requirements, which
> may vary by the location and functionality of the service.    If they
> utilize Javascript libraries, they need to make sure that those libraries
> can provide the required functionality.  For example, there are various
> location libraries that support the W3C Location APIs as well as potentially
> other Location APIs.  However, in general those libraries and underlying
> services were built to provide "Location Based Services" and not a "Location
> Information Service" in the sense that the term is used in IETF, NENA and
> other emergency services specifications.   However, there may be other
> libraries that *are* built to support emergency services (e.g. a library
> that supports HELD).    Also, there may be APIs available (such as the
> WebAPI proposed by Mozilla, see
> that can enable an
> HTML5 application to access the underlying telephony capabilities of the
> device on which the browser runs (e.g. a mobile handset that is capable of
> making emergency calls with location).   The service provider needs to
> understand their responsibilities and utilize the right APIs and libraries
> to satisfy them.
> ---------------------------------------
> While in the long-term it may be possible to close the gaps,  in the short
> term the gaps may be addressed via Javascript libraries implementing
> elements of the ECRIT architecture such as HELD, or even LoST.
> Ted Hardie also said:
> "It doesn't make sense to use LoST alone in the case you've described, at
> least if I understood you.  LoST takes a desired service and a location as
> inputs and discovers the service provider associated with that location.  If
> we're presuming that someone starts at a particular server, LoST must run
> prior to reaching that server.  So you'd need some sort of libraries
> provided prior to that server being reached to run LoST.  If you start from
> a known server that provides javascript libraries for discovering location
> (by pulling from DHCP or HELD, for example) and running LoST, you could then
> get to the Emergency Service Provider's RTCWEB server, but it would be
> pretty fragile."
> [BA] Richard Barnes has been developing an ECRIT client that runs in the
> browser, so I suspect he will have some observations on how LoST
> functionality could be provided.  My main point was that just because
> something is a requirement in ECRIT PhoneBCP doesn't necessarily imply that
> it needs to be provided natively in the browser.  Before making that
> determination we need to understand if the functionality could be viably
> provided another way -- such as in Javascript, via a plugin, or maybe even
> via server-side functionality.