W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2016

[webrtc-pc] Introducing Closely-Associated Services (CAS) into WebRTC

From: Wenyu DONG via GitHub <sysbot+gh@w3.org>
Date: Sun, 26 Jun 2016 03:33:06 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-162310570-1466911985-sysbot+gh@w3.org>
warnard has just created a new issue for 

== Introducing Closely-Associated Services (CAS) into WebRTC ==
<meta charset="utf-8">
<title>Introducing  Closely-Associated Services (CAS) into 

<h1><strong>Introducing  Closely-Associated Services (CAS) into 
<p><strong>Contributor: </strong></p>
<p> DONG Wenyu, <a 
  China Mobile</p>
<h1>1. Introduction </h1>
<p>In  future, when WebRTC audio/video communication is as popular as 
traditional  telephone-call today, harassing or malicious calls seem 
to be inevitable,  possibly bringing undeserved negative reputation to
 WebRTC. It is due to  extremely low cost, rich media capability and 
difficulty to apply lawsuits to  peer users in WebRTC scenarios.</p>
<p>  People  can rely on some applications to deal with such thorny 
dilemma. For traditional  phone-calls, services have been proven 
effective like Customized Ring-back Tone  (basically in-bound 
audio/video) and Customized Phone-call Signature (basically  out-bound
 texts). When receiving strange phone-calls, such services can provide
  users with real-time warning about the peer numbers, helping users 
decide  whether the incoming calls are malicious and thus simply 
reject them.<br>
<p>Similarly,  for WebRTC, such scenarios are also applicable. When a 
WebRTC user A receives  an incoming-call request from another user B, 
it will be helpful if user A can  get extra information about B, so as
 to decide whether to answer this call or  just reject it. Similarly, 
user B will be happier if he/she can learn more  about user A before 
starting talking, for example if A is in annual leave, B  may refrain 
from talking about business.<br>
<p>Let  nominate such services as CAS (Closely-Associated Services) of
 WebRTC. Aside  from reminding of malicious incoming calls, CAS 
services can serve other  purposes like advertising.<br>
  Necessary  technical mechanism is prerequisite to implement CAS of 
WebRTC, requiring  extension of WebRTC APIs, since the rendering of 
CAS media and basic  communication audio/video are closely 
interleaved. Once the basic communication  is established, normally 
the browsers should suspend CAS media rendering and  enable basic 
communication media. The switching should take place at only  specific
 connection state transitions and should be finished in mili-seconds,
  so delicate co-ordination of signaling and protocols has to be 
designated.  Consequently, WebRTC APIs are recommended to extend 
<h1>2. Specification </h1>
<p>CAS  services of WebRTC require cloud-based servers. After all, it 
is impossible for  browsers to preserve all possible WebRTC user IDs 
in the world and related CAS  information much of which consists of 
rich media, let alone dynamically  generated information like newly 
activated WebRTC IDs, newly customized CAS  media by CAS service 
owners or the ID owners, or the public&rsquo;s comments on a  specific
<p>Consequently,  the following extension of specification is 
<h2>2.1     Extension to RTCConfiguration</h2>
<p>New  members are introduced into <u><a 
<p>dictionary RTCConfiguration {<br>
              sequence&lt;RTCCasServer&gt;    casServers;<br>
<p>The &lsquo;<u>casServers</u>&rsquo;,  of type sequence 
&lt;<u>RTCCasServer</u>&gt;, represents a list of candidate  servers 
that provide CAS services.</p>
<h2>2.2     RTCCasServer</h2>
<p>The <u>RTCCasServer</u> has the following members:</p>
<p>dictionary RTCCasServer {<br>
  required (DOMString or sequence&lt;DOMString&gt;)  urls;<br>
  required (DOMString or sequence&lt;DOMString&gt;)  mediaTypes;<br>
  DOMString or sequence&lt;DOMString&gt;    conditions;<br>
  DOMString                          priority;<br>
<p>Among <u>RTCCasServer</u> &lsquo;s members</p>
  <li><u>urls</u>: It represents the URL(s) of the CAS server.</li>
  <li><u>mediaTypes</u>: It represents which type(s) of media this CAS
 server will  generate, so the JavaScript App can know how to display 
the media..</li>
  <li><u>conditions</u>: It comprises a series of regular expressions,
 representing what  range of WbRTC IDs can be generated by this CAS 
  <li><u>priority</u>: It represents the priority of this CAS 
<h2>2.3     ICE and Media  Negotiation</h2>
<p>Like  basic audio/video communication, a CAS service needs to 
perform similar ICE and  media negotiation.</p>
<h2>2.4     RTCPeerConnectionState–based Co-ordination</h2>
 plays an  essential role in co-ordination of CAS services and basic 
communication. A  typical situation is illustrated as follows:</p>
<table border="1" cellspacing="0" cellpadding="0" width="100%">
    <td width="56%" valign="top"><p>Basic communication&lsquo;s 
    <td width="43%" valign="top"><p>CAS media</p></td>
    <td width="56%" valign="top"><p>New</p></td>
    <td width="43%" valign="top"><p>Permitted to be played</p></td>
    <td width="56%" valign="top"><p>Connecting</p></td>
    <td width="43%" valign="top"><p>Permitted to be played</p></td>
    <td width="56%" valign="top"><p>Connected</p></td>
    <td width="43%" valign="top"><p>Stop playing, unless JS App 
explicitly requires CAS media    to be played (in a smaller size or on
 a upper layer) together with basic    communication&rsquo;s 
    <td width="56%" valign="top"><p>Disconnected</p></td>
    <td width="43%" valign="top"><p>Permitted to be played</p></td>
    <td width="56%" valign="top"><p>Failed</p></td>
    <td width="43%" valign="top"><p>Quit playing</p></td>
    <td width="56%" valign="top"><p>Closed</p></td>
    <td width="43%" valign="top"><p>Quit playing</p></td>

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/715 using your GitHub account
Received on Sunday, 26 June 2016 03:33:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC