Audio/Video encryption in Live Guide

When transmitting audio and video over the Internet you can choose whether the transmission should be encrypted or not as well as the level of encryption used. 

This is set from Settings > Security > A/V encryption.

The options are None, Low or High.

Which option to choose depends on the type of data you are transmitting and may impact the transmission speed: selecting None is the fastest transmission while selecting High is the most secure transmission. So if your operators are discussing, for example, financial details or financial transactions with customers you might want to set the encryption to High whereas, for example, details about items on a webshop might not require encryption.

Transmission is encrypted on both ends, that is both on the operator side and on the customer side.

The None option corresponds to the usage of basic RTMP protocol.

RTMP is a TCP-based protocol that uses port number 1935 by default, maintains persistent connections, and allows low-latency communication. To deliver streams smoothly and transmit as much information as possible, it splits streams into fragments, and their size is negotiated dynamically between the client and server while sometimes it is kept unchanged: the default fragment sizes are 64-bytes for audio data, and 128 bytes for video data and most other data types. Fragments from different streams may then be interleaved and multiplexed over a single connection. With longer data chunks the protocol thus carries only a one-byte header per fragment, so incurring very little overhead. However, in practice, individual fragments are not typically interleaved. Instead, the interleaving and multiplexing is done at the packet level, with RTMP packets across several different active channels being interleaved in such a way as to ensure that each channel meets its bandwidth, latency, and other quality-of-service requirements. Packets interleaved in this fashion are treated as indivisible and are not interleaved on the fragment level. Streamed content is encrypted by the Flash Media Server "on the fly", so that there is no need to encrypt the source file (a significant difference from Microsoft’s DRM). 

The Low option corresponds to the usage of RTMPE protocol, which wraps the RTMP session in a lighter-weight encryption layer by removing the need to acquire an SSL Certificate, to make it more practical for high-traffic sites to serve encrypted content.

RTMPE makes use of well-known industry-standard cryptographic primitives, consisting of Diffie-Hellman key exchange and HMACSHA256, generating a pair of RC4 keys, one of which is then used to encrypt the media data sent by the server (the audio or video stream), whilst the other key is used to encrypt any data sent to the server. RTMPE causes less CPU-load than RTMPS on the Flash Media Server.

The High option corresponds to the usage of the RTMPS protocol. In this case, the underlying RTMP session is simply wrapped inside a normal SSL session. It is generally understood that the SSL handshake at the beginning of a session is very computationally intensive, and therefore the High option is the most CPU-intensive.