AudioCodes Mediant 800 User Manual page 231

CHAPTER 15 Media
DTLS support is important for deployments with WebRTC. WebRTC requires that media channels
be encrypted through DTLS for SRTP key exchange. Negotiation of SRTP keys through DTLS is
done during the DTLS handshake between WebRTC client and peer. For more information on
WebRTC, see WebRTC.
In contrast to SDES, DTLS key encryption is done over the media channel (UDP), not signaling.
Thus, DTLS-SRTP is generally known as "secured key exchange over media". DTLS is similar to
TLS, but runs over UDP, whereas TLS is over TCP. Before the DTLS handshake, the peers
exchange DTLS parameters (fingerprint and setup) and algorithm types in the SDP body of the SIP
messages exchanged for establishing the call (INVITE request and response). The peers
participate in a DTLS handshake during which they exchange certificates. These certificates are
used to derive a symmetric key, which is used to encrypt data (SRTP) flow between the peers. A
hash value calculated over the certificate is transported in the SDP using the 'a=fingerprint'
attribute. At the end of the handshake, each side verifies that the certificate it received from the
other side fits the fingerprint from the SDP. To indicate DTLS support, the SDP offer/answer of the
SIP message uses the 'a=setup' attribute. The 'a=setup:actpass' attribute value is used in the SDP
offer by the device. This indicates that the device is willing to be either a client ('act') or a server
('pass') in the handshake. The 'a=setup:active' attribute value is used in the SDP answer by the
device. This means that the device wishes to be the client ('active') in the handshake.
a=setup:actpass
a=fingerprint: SHA-1 \4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
DTLS cipher suite reuses the TLS cipher suite. The DTLS handshake is done for every new call
configured for DTLS. In other words, unlike TLS where the connection remains "open" for future
calls, a new DTLS connection is required for every new call. Note that the entire authentication and
key exchange for securing the media traffic is handled in the media path through DTLS. The
signaling path is used only to verify the peers' certificate fingerprints. DTLS messages are
multiplexed onto the same ports that are used for the media.
➢
To configure DTLS:
1. In the TLS Context table (see
with the DTLS version (TLSContexts_DTLSVersion).
2. Open the IP Groups table (see
SIP entity, assign it the TLS Context for DTLS, using the 'DTLS Context' parameter (IPGroup_
DTLSContext).
3. Open the IP Profiles table (see
the SIP entity, configure the following:
● Configure the 'SBC Media Security Mode' parameter (IPProfile_
SBCMediaSecurityBehavior) to SRTP or Both.
● Configure the 'Media Security Method' parameter (IPProfile_SBCMediaSecurityMethod)
to DTLS.
● Configure the 'RTCP Mux' parameter (IpProfile_SBCRTCPMux) to Supported.
Multiplexing is required as the DTLS handshake is done for the port used for RTP and
thus, RTCP and RTP must be multiplexed onto the same port.
● Configure the ini file parameter, SbcDtlsMtu (or CLI command configure voip > sbc
settings > sbc-dtls-mtu) to define the maximum transmission unit (MTU) size for the DTLS
handshake.
●
●
Configuring TLS Certificate
Configuring IP
Configuring IP
The 'Cipher Server' parameter must be configured to "ALL".
The device does not support forwarding of DTLS transparently between endpoints.
Mediant 800 Gateway & E-SBC | User's Manual
Contexts), configure a TLS Context
Groups) and for the IP Group associated with the
Profiles) and for the IP Profile associated with
- 191 -