- From: Wenyu DONG via GitHub <sysbot+gh@w3.org>
- Date: Sun, 26 Jun 2016 03:33:06 +0000
- To: public-webrtc@w3.org
warnard has just created a new issue for
https://github.com/w3c/webrtc-pc:
== Introducing Closely-Associated Services (CAS) into WebRTC ==
<html>
<head>
<meta charset="utf-8">
<title>Introducing Closely-Associated Services (CAS) into
WebRTC</title>
</head>
<body>
<h1><strong>Introducing Closely-Associated Services (CAS) into
WebRTC</strong></h1>
<p><strong>Contributor: </strong></p>
<p> DONG Wenyu, <a
href="mailto:dongwenyuyj@chinamobile.com">dongwenyuyj@chinamobile.com</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>
<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>
<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
accordingly.</p>
<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’s comments on a specific
ID.<br>
</p>
<p>Consequently, the following extension of specification is
needed.</p>
<h2>2.1 Extension to RTCConfiguration</h2>
<p>New members are introduced into <u><a
href="https://www.w3.org/TR/2016/WD-webrtc-20160128/#rtcconfiguration-dictionary">RTCConfiguration</a></u>.</p>
<p>dictionary RTCConfiguration {<br>
sequence<RTCCasServer> casServers;<br>
……<br>
};</p>
<p>The ‘<u>casServers</u>’, of type sequence
<<u>RTCCasServer</u>>, 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<DOMString>) urls;<br>
required (DOMString or sequence<DOMString>) mediaTypes;<br>
DOMString or sequence<DOMString> conditions;<br>
DOMString priority;<br>
};</p>
<p>Among <u>RTCCasServer</u> ‘s members</p>
<ul>
<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
server.</li>
<li><u>priority</u>: It represents the priority of this CAS
server.</li>
</ul>
<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>
<p><u><a
href="https://www.w3.org/TR/2016/WD-webrtc-20160128/#rtcpeerconnectionstate-enum">RTCPeeerConnectionState</a></u>
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%">
<tr>
<td width="56%" valign="top"><p>Basic communication‘s
RTCPeerConnectionState</p></td>
<td width="43%" valign="top"><p>CAS media</p></td>
</tr>
<tr>
<td width="56%" valign="top"><p>New</p></td>
<td width="43%" valign="top"><p>Permitted to be played</p></td>
</tr>
<tr>
<td width="56%" valign="top"><p>Connecting</p></td>
<td width="43%" valign="top"><p>Permitted to be played</p></td>
</tr>
<tr>
<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’s
audio/video</p></td>
</tr>
<tr>
<td width="56%" valign="top"><p>Disconnected</p></td>
<td width="43%" valign="top"><p>Permitted to be played</p></td>
</tr>
<tr>
<td width="56%" valign="top"><p>Failed</p></td>
<td width="43%" valign="top"><p>Quit playing</p></td>
</tr>
<tr>
<td width="56%" valign="top"><p>Closed</p></td>
<td width="43%" valign="top"><p>Quit playing</p></td>
</tr>
</table>
<p> </p>
<p> </p>
<p> </p>
</body>
</html>
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