Re: [rtcweb] Playing regulator

+1

http://transition.fcc.gov/cgb/dro/cvaa.html

I hope you enjoy being amateur telecom lawyers.  Some of us are getting
pretty good at it. 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Bernard Aboba
Sent: Friday, February 01, 2013 7:55 PM
To: Gunnar Hellstrom; rtcweb@ietf.org
Subject: Re: [rtcweb] Playing regulator

While we didn't go into it in any depth in the document, there does seem to
be a distinction between scenarios in which the application developer has
little control over the endpoint (e.g. bring your own device), versus
scenarios in which the application developer has some say or influence on
what the capabilities of the endpoints are.

In the former case, the application may have to function even in a browser
environment where WebRTC is not available, whereas in the latter case, the
application developer can ensure that a set of required capabilities are
available.  The "telephony terminal" case seems more in the latter category
than the former. 

For example, a vendor developing a "telephony terminal" could choose the
browser they wanted to embed in the device, and might even have access to
the browser source code, so as to be able to add codecs and other
capabilities.   In that case, the performance and extensibility of the code
base will be an important consideration, since that will determine how much
work will be involved to add capabilities and what the options are for
accomplishing this (e.g. native code required vs. Javascript). 

  _____  

Date: Sat, 2 Feb 2013 01:13:52 +0100
From: gunnar.hellstrom@omnitor.se
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Playing regulator

It is easy to imagine applications of WebRTC where the users will not have
any expectation that they could use it for emergency services. 
E.g. a web page only providing access to a specific company's customer
service.
So, each application does not need to provide this access.

However, the platform has apparent ambitions to be possible to use for
telephony like applications, with an opportunity to call by address or
number,
E.g  

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#
section-4.3.1> 4.3.1. Telephony terminal 

In at least that case, there will be an expectation from users, and a
requirement from regulators in many countries to be able to provide
emergency service access.

So, the topic belongs here in some way.

I withdrew it from the total conversation addition, because it is a general
function. I hope it will be possible to find a suitable place and general
wording for it, and there indicate that it is valid for all media, including
audio, video and real-time text.

Gunnar

  _____  

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288

On 2013-02-02 00:28, Bernard Aboba wrote:

With regulations in flux, it is not easy to predict the extent of the
obligation, beyond what exists for an "interconnected VoIP" service today.
For example, we have a text to 911 proceeding ongoing as well as quite a few
others. In order to examine what the Issues might be, Martin and I put
together the following document:

http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit

Comments welcome.

On Feb 1, 2013, at 14:44, "Dale R. Worley" <worley@ariadne.com> wrote:

Can you explain this?  I suspect that you have a specific meaning, but
as I read it, it sounds like "I see no objection if WebRTC does not
interwork with emergency services."  If WebRTC does not interwork with
emergency services, the regulators will crush it.

Dale
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________ rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb