Introducing Closely-Associated Services (CAS) into WebRTC

[warnard]

<title>Introducing Closely-Associated Services (CAS) into WebRTC</title>

Introducing Closely-Associated Services (CAS) into WebRTC

Contributor:

DONG Wenyu, dongwenyuyj@chinamobile.com, China Mobile

1. Introduction

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.

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.

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.

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.
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.

2. Specification

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.

Consequently, the following extension of specification is needed.

2.1     Extension to RTCConfiguration

New members are introduced into RTCConfiguration.

dictionary RTCConfiguration {
             sequence<RTCCasServer>   casServers;
             ……
};

The ‘casServers’, of type sequence <RTCCasServer>, represents a list of candidate servers that provide CAS services.

2.2     RTCCasServer

The RTCCasServer has the following members:

dictionary RTCCasServer {
required (DOMString or sequence<DOMString>)  urls;
required (DOMString or sequence<DOMString>)  mediaTypes;
DOMString or sequence<DOMString>   conditions;
DOMString                         priority;
};

Among RTCCasServer ‘s members

• urls: It represents the URL(s) of the CAS server.
• mediaTypes: It represents which type(s) of media this CAS server will generate, so the JavaScript App can know how to display the media..
• conditions: It comprises a series of regular expressions, representing what range of WbRTC IDs can be generated by this CAS server.
• priority: It represents the priority of this CAS server.

2.3     ICE and Media Negotiation

Like basic audio/video communication, a CAS service needs to perform similar ICE and media negotiation.

2.4     RTCPeerConnectionState–based Co-ordination

RTCPeeerConnectionState plays an essential role in co-ordination of CAS services and basic communication. A typical situation is illustrated as follows:

Basic communication‘s RTCPeerConnectionState	CAS media
New	Permitted to be played
Connecting	Permitted to be played
Connected	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
Disconnected	Permitted to be played
Failed	Quit playing
Closed	Quit playing

 

 

 

[alvestrand]

No support for the idea detected on the list.