• SightCall Video PaaS Security

The SightCall Platform is composed of two platform layers: the Core platform and the Real-­time Platform. Real-­time servers are distributed around the globe in datacenters with strict physical access policies. SightCall uses dedicated servers to achieve predictable real­‐time performance.

The figure to the left illustrates the authentication and communication flows in a partner application built using SightCall. One mobile client and one WebRTC client are shown for example purposes. In other configurations, clients may be constructed using browsers that do not support WebRTC by using the SightCall Driver.

For each client application connecting to the cloud, SightCall runs a corresponding gateway (WebRTC, Driver, Mobile) in the real-time platform. The use of the Gateway components in the real-time platform provides a degree of security. For WebRTC applications, the Gateway receives signaling commands via WSS (WebSocket secure) and acts as a reverse proxy to Web Service and SIP layers of the SightCall core. Mobile and SightCall Driver applications use different gateways with signaling commands sent over TLS. Imposing the gateway between client applications and the SightCall Cloud ensures a level of isolation from the sensitive information on the VPN.

Security considerations influence the design of the system throughout. All communication between servers of the SightCall Cloud are performed over VPN. The authentication web-service of the SightCall core is run in a VM (Virtual Machine) separate from the SIP Server VM. Firewalls are established between the two.


69% of CIOs cite security as their principle concern with cloud services.

Encrypting the Media

SightCall uses DTLS-SRTP for securing audio and video media. This is the same protocol required by the WebRTC standard and implemented by Chrome. With DTLS-SRTP (Datagram Transport Layer Security, Secure Real-time Transport Protocol) the cryptographic key exchange for securing the media takes place in the media plane and on the same port (the RTP port) as the media packets.

SightCall platforms include WebRTC-enabled browsers, the SightCall Driver and iOS and Android SDKs. By definition, a WebRTC-enabled browser implements DTLS-SRTP. SightCall custom platforms implement WebRTC standards, including the use of DLTS-SRTP for securing media with AES 256-bit keys. SightCall conference bridges employ the same level of encryption for multi-party calls.


Embedding SightCall requires a partner to implement two authentication components: on the client and one on their server. In the client (mobile or JavaScript), the partner must implement a method that fetches an authentication token from their back-end. On the back-end, the partner must implement a proxy method that verifies the identity of the client and forwards a token request to SightCall.

By externalizing the authentication process, SightCall avoids maintaining a database of user credentials. Instead, each partner can implement the authentication scheme they wish using the credentials that are appropriate for their application.

Each HTTPS connection from the Partner back-end to the SightCall Web Service is protected by using a pinned SSL Certificate, specific to the partner. User authentication on the SightCall side is implemented using OAuth2 in a multi-tenant architecture.

The use of pinned client certificates on the partner platform ensures that the only hosts connecting to the SightCall Web Service are those that are explicitly allowed. This, coupled with our VPN ensures isolation of SIP services from Web services.


72% of businesses have adopted the cloud. Within 3 years, that number will reach a staggering 91% of businesses.

Security is Key

From the beginning, SightCall has considered security as part of its fundamental architecture.

By partitioning the Core and the Real-time services, SightCall provides another degree of reliability and security. The Real-time servers face the Internet, and provide a high level of isolation between its own components. Core services are protected by VPN on the Real-time side, and by pinned client certificates on the Web Services side. The result is that the authenticity of each server talking to the core is fully verified using strong security techniques.