Re: [rtcweb] Playing regulator

Bernard Aboba <bernard_aboba@hotmail.com> Sat, 02 February 2013 00:54 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E521421F89EF for <rtcweb@ietfa.amsl.com>; Fri, 1 Feb 2013 16:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.427
X-Spam-Level:
X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y9SV5S5A1f6 for <rtcweb@ietfa.amsl.com>; Fri, 1 Feb 2013 16:54:39 -0800 (PST)
Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id E89FA21F89E9 for <rtcweb@ietf.org>; Fri, 1 Feb 2013 16:54:38 -0800 (PST)
Received: from BLU002-W158 ([65.55.116.73]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Feb 2013 16:54:38 -0800
X-EIP: [K85Hw0Y6rrTny/Xdg8xc3wzalqsh3th4]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU002-W158548FEBD3A36CDE7C362B93030@phx.gbl>
Content-Type: multipart/alternative; boundary="_171e8956-a83e-4810-923e-aab8e89852d0_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Fri, 01 Feb 2013 16:54:37 -0800
Importance: Normal
In-Reply-To: <510C5A40.6040600@omnitor.se>
References: <50F97303.4070906@ericsson.com> <5102FE7E.5000109@omnitor.se>, <51039976.1000600@alvestrand.no> <51098D5A.4040009@omnitor.se>, <510AF934.2030800@alvestrand.no>, <201302012243.r11MhmTi1016963@shell01.TheWorld.com>, <BLU405-EAS21443326CB0B10EFDC7E529931C0@phx.gbl>, <510C5A40.6040600@omnitor.se>
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Feb 2013 00:54:38.0369 (UTC) FILETIME=[E0736910:01CE00DF]
Subject: Re: [rtcweb] Playing regulator
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Feb 2013 00:54:40 -0000

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  

      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