Transport Protocols

When an IM session is created, the application can specify the provisioning profile to use for the session. The SIP server element in the profile contains a transport protocol attribute. The application can set this attribute to UDP, TCP, or TLS (Transport Layer Security). If the transport specified is TLS, then the signaling channel to the server is secured using the TLS protocol.

TLS is a security protocol that sits on top of TCP. The TLS protocol uses an encryption key generated by the TLS handshake protocol to encrypt the messages. This encryption key is negotiated between the client and the server and shared between them. Separate encryption keys are negotiated for each signaling connection along the route. The client authenticates the server using the TLS handshake protocol before the signaling connection is established.

The RTC Client API establishes encrypted signaling connections to the server using TLS. However, if the remote client has not specified TLS, the signaling connection from the remote client may not be encrypted. Likewise, the last leg of the signaling connection to the remote client from their server may not be encrypted. In general, if any of the servers along the route that the packet takes to the remote client do not support TLS encryption, these segments will not be encrypted and the packet will be visible to eavesdroppers on the network.

The RTC Client API also supports peer-to-peer connections. Generally, peer-to-peer connections are not encrypted because the RTC Client API does not accept incoming TLS signaling connections.

Note  It is possible for someone to intercept information by replacing the SIP server, which would result in forwarding SIP requests to erroneous servers. The application should therefore ensure that a means to authenticate the server is enabled. For the application to authenticate the server, the Kerberos authentication method should be enabled and the TLS transport type must be specified in the profile.