DTLS-SRTP

The Oracle Communications Session Border Controller (SBC) supports Datagram Transport Layer Security (DTLS) to establish SRTP media traffic over UDP. You configure DTLS-SRTP security profiles and apply them to the realms that include end stations that request this security. The SBC uses DTLS within the context of SRTP (DTLS-SRTP) per RFC 5764. This DTLS-SRTP feature provides for secure media, supports the same transfer scenarios supported for SDES-SRTP, and also supports unattended transfer, and music on hold scenarios.

DTLS operation on the SBC is equivalent to SDES operation. It provides security against common evesdropping, tampering and message forgery. DTLS can operate over UDP. The use of UDP can eliminate some delay associated with connection protocols.

DTLS-SRTP differs from previous attempts to secure media traffic where the authentication and key exchange protocol, such as with Multimedia Internet KEYing (MIKEY) RFC3830, is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints with only a cryptographic binding of the media keying to the SIP/SDP communication.

DTLS-SRTP Overview

RFC 5763 specifies using DTLS with SRTP, called DTLS-SRTP. Within this architecture, DTLS, based on TLS, provides key management, negotiation of parameters, and secure data transfer. SRTP provides confidential message authentication and replay security. Combining these protocols as SRTP-DTLS establishes fully secure SRTP flows.

Key exchange via text-based SDP is unacceptable in that malicious network elements can easily eavesdrop and obtain plaintext keys, compromising the privacy and integrity of the encrypted media stream. Consequently, the SDP exchange must be protected by a security protocol.

While the SRTP framework provides encryption and authentication procedures and defines the set of default cryptographic transforms required for RFC compliance, it does not specify a key management protocol to securely derive and exchange cryptographic keys. Similar to SDES deployment, these missing functions need to come from another mechanism. DTLS-SRTP, defined by RFC 5763 and RFC 5764 can provide this means of implementing key management for SRTP.

On the SBC, DTLS-SRTP operation begins with the caller issuing a SIP INVITE with SDP parameters that requests a DTLS exchange between the end stations. The callee processes the SIP signaling and SDP request, ultimately issuing a SIP 200 OK to the caller, which is acknowledged. At this point, the DTLS server begins a DTLS handshake sequence between the media endpoints, within which the end stations confirm each others' identity and establish the cryptography to be used for each flow. Once confirmed, the end stations begin exchanging SRTP media.

DTLS-SRTP secures flows between itself and both the caller and callee. The architecture establishes a client-server relationship. Mutual authentication is required. Although it supports features such as early media, the architecture supports an active station tearing down the call if authentication from the other side fails.

The architecture also uses certificates as a means of confirming identity for both the signaling and media flows. These certificates can be self-signed and do not refer to an authority for confirmation. Instead, the end stations hash the certificates and create a fingerprint for use by the opposing end station to verify that the same end-station performing the signaling is also the source of the media. Finally, the architecture establishes the crypto-suite and exchange keys to be used to encrypt and decrypt each flow.

SBC Support for DTLS-SRTP

The SBC aligns with the applicable standards to support DTLS-SRTP, including RFC 5763 and RFC 5764. Alignment with these standards defines much of the SBC behavior with respect to supporting DTLS for SRTP.

The SBC supports broad, standards-based requirements including:

  • Authenticating the endpoints using fingerprints
  • DTLS Extension to Establish Keys for the SRTP
  • Support of the "use_srtp” extension without an MKI value defined
  • Support for multiple media sessions from an endpoint, such as audio and video, with separate DTLS session establishment exchange per media session
  • Using information within SIP/SDP sessions to identify DTLS-SRTP sessions
  • Send DTLS alert message if the system terminates the call because it does not support any of the SRTP protection profiles offered by the client.

Important SBC behavior related to DTLS-SRTP includes:

  • If the peer’s DTLS certificate matches the peer’s a=fingerprint If the validation is successful, then the system stops the dtls-complete-timeout. If this validation fails, the system terminates the media session.
  • Whenever the dtls-complete-timeout expires, the system terminates the media session.
  • The system drops any SRTP/SRTCP packets it receives before it has processed the DTLS-SRTP keys.
  • The system rejects an SDP media session offer that includes "a=fingerprint" but does not include the a=setup attribute.
  • The system must have a dtls-srtp-profile on any realm that must be able to process or generate an SDP offer for DTLS-SRTP. For example, if there is no profile at the ingress, the system rejects the request with a 503, service unavailable message.
  • The system provides both ingress and egress interworking support between DTLS-SRTP and RTP or SDES-SRTP.

Within the context of the DTLS setup procedure, the SBC utilizes the following over the specified paths:

  • Signaling Path
    • Recognizing and signaling the use of DTLS in the SDP m-line over the signaling path by the parameter "UDP/ TLS/RTP/SAVP"
    • Specifying the server role to setup the media path using in "a=setup:passive" SDP
    • Presenting the fingerprint of the end station in the SDP a=fingerprint line
    • Specifying the media path using the IP address and the port exchanged in the offer/answer SDP in the “c=” and “m=” lines
  • Media Path
    • Specifying the use of DTLS-SRTP with the use_srtp extension
    • Providing its certificate for verification within the Hello exchange
    • Using the cipher suite negotiated in the client and server Hello exchange to encrypt/decrypt the handshake messaging
    • Complying with DTLS requirement for mutual authentication
    • Using the negotiated encryption and decryption keys to encrypt/decrypt the media

The SBC supports the following SRTP encryption and authentication algorithms using the DTLS-SRTP protection profiles defined in RFC 5764:

  • AES_CM_128_HMAC_SHA1_80 — Using the SRTP_AES128_CM_HMAC_SHA1_80 profile
  • AES_CM_128_HMAC_SHA1_32 — Using the SRTP_AES128_CM_HMAC_SHA1_32 profile
  • AEAD_AES_256_GCM

Configuring DTLS-SRTP

You configure DTLS-SRTP on the SBC by setting up dtls-srtp-profile sub-element, within media-security.

dtls-srtp-profile configuration includes:

  • name—The name of this profile, which you enter to the dtls-srtp-profile parameter on a realm-config.
    ORACLE(dtls-srtp-profile)#name MyDtlsProfile
  • tls-profile—The name of the tls-profile profile you use within this dtls-srtp-profile.

    On each realm that has a configured dtls-srtp-profile, the SBC includes the session attribute a=fingerprint in SDP offers. This fingerprint is the output of a hash function calculated over the certificate that the SBC presents during the DTLS handshake. You configure this certificate within a tls-profile and apply it to the dtls-srtp-profile.

    Note:

    This session-level fingerprint attribute applies to both audio and video sessions for this realm, used when the SBC functions as an offerer and answerer for both DTLS connections.
  • dtls-completion-timeout—Compliant with RFC 6347, this timeout establishes the time for the full DTLS handshake completion, consolidating timeouts for all the handshake messages. The SBC starts this timer when it receives an answer SDP from the callee, and before sending an answer back to the caller. If the DTLS handshake is completed successfully within the configured dtls-completion-timeout value, the SBC cancels the timer. If the DTLS handshake is not completed successfully within the timeout, the SBC tears down the media flows as part of flow guard timer processing and clears the call by sending a BYE request to both legs.

    The SBC restarts this timer for any new DTLS association.

  • preferred-setup-role—Specifies the role the SBC should perform for DTLS handshakes. The system only allows for the passive setting, which establishes itself as a server.
  • crypto-suite—Specifies the SRTP encryption and authentication algorithms the SBC offers for this flow's media. This setting is not associated with the identity verification fingerprint.

After creating you profile, you apply it to the applicable realm-config. 

ORACLE(realm-config)#dtls-srtp-profile MyDtlsProfile

Note:

This version of the SBC requires successful rtcp-mux (RTCP multiplexing) negotiation during DTLS/SRP negotiations. As such, you must enable the dtls-srtp-profile parameter on each realm for which you have configured a dtls-srtp-profile. 
ORACLE(realm-config)#rtcp-mux enabled

The SBC does not support non-rtcp-mux flows and rejects calls that do not include successful rtcp-mux negotiation.

Related Configuration

Related configuration that impacts DTLS operation includes:

  • When you need different SRTP B2BUA termination by the system on both ingress and egress realms, such as SDES-SRTP and DTLS-SRTP on opposite sides, you must configure a media-sec-policy on both the ingress and egress realms.
    • For DTLS-SRTP at an ingress realm and SDES-SRTP at the egress realm, you must configure an applicable media-sec-policy and a dtls-srtp-profile on the ingress realm. In addition:
      • Ingress media-sec-policy—Set mode to any and protocol set to none
      • Egress media-sec-policy—Set mode to srtp, and protocol set to sdes.
    • For SDES-SRTP at an ingress realm and DTLS-SRTP at the egress realm, you must configure an applicable media-sec-policy and a dtls-srtp-profile on the egress realm. In addition:
      • Ingress media-sec-policy—Set mode to srtp, and protocol set to sdes.
      • Egress media-sec-policy—Set mode to any and protocol set to none
    • A media-sec-policy is not required when both sides are DTLS-SRTP.
  • If the SBC receives an SDP answer with 2 m-lines that includes DTLS and any other protocol, such as SDES, for the same media type, it terminates the SIP session, clearing the call by sending BYE with reason header with cause code “488 Not Acceptable Here”.
  • If you configure SDES on a realm, the SBC always includes the session attribute a=crypto in the SDP offer it sends.
  • The SBC accepts only DTLS messages for the port number on which it advertises SRTP/SRTCP for media flows that:
    • had DTLS offered by the peer
    • had DTLS accepted by the peer
    • the SBC has offered DTLS has but has not yet received an SDP answer

Example DTLS-SRTP Flows

The call flows below present the SBC handling DTLS-SRTP signaling within the context of SIP calls and DTLS media security setup signaling. Note that these flows begin with ingress flowing to the SBC (eg, from Alice) and egress flowing from the SBC (eg, to Bob).

In this flow, the SBC acts as a B2BUA supporting Alice as a DTLS server and Bob as an RTP leg end point. This call flow assumes that the end points are not behind a NAT and no error is encountered during negotiation. The description does not cover the SIP signaling that sets up RTP with Bob. The flow diagram does not include some of the SIP signaling for brevity.

This image shows the system supporting a call with DTLS-SRTP towards the caller and RTP towards the callee.

The call flow begins with Alice setting up a DTLS-SRTP call to Bob, with the SBC acting as B2BUA between them. Steps 1 through 3 take place on the SIP signaling paths; the remaining steps take place on the media path.

  1. Alice signals, using the “m” line, that media transport uses DTLS-SRTP. The “a=setup:active” attribute indicates that Alice is the DTLS client and, therefore, initiates the DTLS connection for the media key exchange.

    In addition, Alice calculates the hash of its certificate and populates it in the “a=fingerprint” attribute. 

    INVITE sip:2001@192.168.123.16:5060 SIP/2.0
Via: SIP/2.0/udp 192.168.123.2:5060;branch=z9hG4bK-2
From: 1001 <sip:1001@test.example.com>;tag=1001
To: 2001 <sip:2001@test.example.com>
...

c=IN IP4 172.16.123.9
t=0 0
**m=audio 11000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=rtcp-mux
**a=sendrecv
**a=fingerprint: SHA-1 49:27:AF:1D:BA:94:2B:00:E9:33:0A:9E:3A:B5:93:6D:EF:11:E4:55
**a=setup:active
  2. The SBC sends an INVITE to Bob. The RTP does not contain any security parameters because Bob's realm does not use DTLS over SRTP or SDES. Bob's end station negotiates the connection with the SBC as normal audio RTP over UDP.
  3. The SBC handles the reply, up to and including the 200 OK from Bob and to Alice.

    The SDP that the SBC sends to Alice includes:

    • The “m” attribute, indicating media transport uses DTLS-SRTP.
    • The “a=setup:passive” attribute indicating that the SBC acts as the TLS server, receiving the DTLS connection from Alice.
    • The “a=fingerprint” attribute. This is the SBC certificate hash, used to identify the key that it presents during the ensuing DTLS handshake to authenticate itself to the peer. This handshake uses the media path. 
    SIP/2.0 200 OK
Via: SIP/2.0/udp 192.168.123.2:5060;branch=z9hG4bK-2
From: 1001 <sip:1001@test.example.com>;tag=1001
To: 2001 <sip:2001@test.example.com>;tag=2001
...

c=IN IP4 192.168.123.16
t=0 0
**m=audio 10000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000
**a=setup:passive
**a=fingerprint:sha-1 AF:F2:99:EF:BF:9D:24:B4:1F:F4:87:83:47:5A:F1:09:1F:2F:89:A1
  4. With the SIP signaling setup, Alice begins the DTLS signaling across the media path by sending a DTLS Client Hello to the SBC. The media path is between the IP address and the port exchanged in the offer/answer SDP in the “c=” and “m=” attributes respectively.

    The Hello includes the “use_srtp” extension which contains the SRTP protection profile preferred by Alice.

  5. The SBC responds by sending a DTLS Server Hello to Alice. This Hello includes:
    • The “use_srtp” extension.
    • The DTLS Certificate message that contains the system's certificate. This certificate includes the which public key of the SBC.
  6. Alice calculates the hash of the certificate and compares it against the SBC fingerprint sent in the answer SDP. This comparison confirms that the party involved in the signaling path is same as the party involved in the media path, thereby authenticating the SBC.

    Note:

    The cipher suite negotiated in the Hello exchange protects the DTLS handshake message, not the media. Media is protected by the negotiated SRTP protection profile.

    At this point, all aspects of the Server Hello are done.

  7. The SBC sends Alice a DTLS Server Key Exchange message, including a Certificate Request, based on the key exchange algorithm negotiated in the DTLS cipher suite.
  8. Alice sends the SBC a DTLS Certificate, Client Key Exchange, based on the key exchange algorithm negotiated in the DTLS cipher suite. This message establishes a pre-master secret between the client and server.
  9. The SBC calculates the hash of the certificate and compares it against Alice's fingerprint sent in the answer SDP. This confirms that the party involved in the signaling path is same as the party involved in the media path, thereby authenticating Alice.
  10. Alice send a DTLS Certificate Verify message to the SBC, verifying the client certificate.
  11. Alice send a DTLS Change Cipher Spec, Finished Message message to the SBC,

    The client sends these messages to signal the transition. Ensuing TLS control messages are protected by the negotiated DTLS cipher suite. Since the use_srtp extension is negotiated, all application data is assumed to be RTP/RTCP packets and are protected by SRTP. Also it serves as an indication that the key exchange and authentication process with the peer entity is successful.

  12. The SBC send a DTLS Change Cipher Spec, Finished Message message to Alice.

    At this point, both the SBC and Alice are in receipt of the SRTP keying material, have calculated the SRTP keys using the TLS master as an input parameter to the SRTP KDF. Both stations start encrypting media using SRTP between the address and ports specified in the SDP negotiation.

Music on Hold

The SBC supports DTLS media flows during hold and music on hold scenarios within the context of SIP signaling. In the example below, the callee has already established an SRTP flow across the media plane, in this case using the SBC as the UAS. The diagram condenses the DTLS negotiation, covered above, using a single line.

This image shows the system supporting a call with DTLS-SRTP with music on hold.

Alice initiates the music on hold scenario using the SDP sendonly parameter. The SBC maintains DTLS-SRTP flows until Alice issues the sendrecv parameter, upon which the SRTP and RTP call media resumes.

  1. Alice sends a new INVITE to the SBC on the signaling plane using the a=sendonly parameter to signal the hold, and the fingerprint to validate it as the same end station that setup the SRTP flow.. 
    SIP/2.0 200 OK
Via: SIP/2.0/udp 192.168.123.2:5060;branch=z9hG4bK-2
From: 1001 <sip:1001@test.example.com>;tag=1001
To: 2001 <sip:2001@test.example.com>;tag=2001
...

c=IN IP4 192.168.123.16
t=0 0
m=audio 10000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000
**a=sendonly
**a=fingerprint:sha-1 AF:F2:99:EF:BF:9D:24:B4:1F:F4:87:83:47:5A:F1:09:1F:2F:89:A1
  2. The SBC subsequently sends an INVITE to Bob that also includes a=sendonly.
  3. Bob replies to the SBC with a 200 OK that includes a=recvonly.
  4. The SBC then replies to Alice the with a 200 OK that includes a=recvonly and its fingerprint.
  5. At this point, Alice restarts the SRTP flow with music as the media.
  6. To remove the hold, Alice sends another INVITE that includes a=sendrecv and its fingerprint.
  7. The SBC follows suit with Bob.
  8. Upon acknowledgment, Alice resumes the SRTP flow with the SBC, which resumes the RTP flow with Bob.

Blind Call Transfer using Unattended REFER

The SBC supports the referral of DTLS media flows that use SIP REFER. In the example below, the caller reaches the softswitch. which directs the call to the callee. In this case, the SBC manages the call, supporting SRTP/RTP interworking. When the callee issues a REFER, it becomes the transferor. Both the SBC and the softswitch support the REFER, ending the original call and performing a new SIP INVITE sequence. The SBC also performs a new DTLS-SRTP negotiation, which results in a new SRTP/RTP interworking call. The diagram condenses the DTLS negotiation using a single line.

This image shows the system handling a REFER from one DTLS-SRTP flow to another.

This scenario uses SIP REFER to establish a new SRTP flow to the refer target.

  1. The scenario begins with a caller using the SBC and softswitch to establish SRTP from the caller to the SBC and RTP from the SBC to the callee. This setup uses DTLS-SRTP as previously described, with the SDP m=audio and a=fingerprint triggering the DTLS negotiation.
    INVITE sip:1002@192.168.240.250:5061 SIP/2.0
Via: SIP/2.0/tls 192.168.240.236:5060;branch=z9hG4bK-4
From: 1001 <sip:1001@ccenter.example.com:5060>;tag=1001
To: 1002 <sip:1002@ccenter.example.com:5061>
...
m=audio 11000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=fingerprint: SHA-1 49:27:AF:1D:BA:94:2B:00:E9:33:0A:9E:3A:B5:93:6D:EF:11:E4:55

    The caller and the SBC establish DTLS-SRTP media; the softswitch releases the media and the SBC establishes RTP media with the callee.

  2. The callee decides to transfer the call, issuing a SIP REFER. The caller becomes the transferor and the callee becomes the transferee.
    REFER sip:1001@192.168.240.250:5061;transport=tls SIP/2.0
Via: SIP/2.0/tls 192.168.240.240:5060;branch=z9hG4bK-8
To: 1001 <sip:1001@ccenter.example.com>;tag=1001
From: 1002 <sip:1002@ccenter.example.com>;tag=1002
Call-id: 1-192.168.240.236
CSeq: 1 REFER
Refer-To: sip:1003@192.168.240.243:5060
Referred-By: <sip:1002@192.168.240.240:5060>
  3. After the SBC and the softswitch have accepted the REFER, the transferee gets the REFER and issues its own 202 Accepted message. Subsequently, the transferee issues a NOTIFY to the SBC that includes a subscription to the REFER. 
    NOTIFY sip:1002@192.168.240.250:5061;transport=tls SIP/2.0
Via: SIP/2.0/tls 192.168.240.236:5060;branch=z9hG4bK-10
From: 1001 <sip:1001@ccenter.example.com:5060>;tag=1001
To: 1002 <sip:1002@ccenter.example.com:5061>;tag=1002
Call-id: 1-192.168.240.236
CSeq: 2 NOTIFY
Event: refer
Max-Forwards: 70
Subscription-State: active;expires=120
  4. The SBC provides this NOTIFY to the softswitch and the transferor, upon which the transferor issues a BYE to the SBC. The BYE makes its way to the transferee through the SBC and the softswitch.
  5. Upon receiving the BYE, the transferee issues an new INVITE sequence that traverses the SBC, the softswitch and, reaches the REFER target. These INVITEs include one to setup DTLS-SRTP between the transferee and the SBC, and RTP from the SBC to the target.
  6. The transferee initiates another NOTIFY sequence that terminates at the transferor, and notifies that the REFER subscription now includes the target. This verifies to the transferor that the REFER was successful.
  7. The call flow ultimately shows the transferee tearing down the call with BYE/200 OK sequences.

DTLS-SRTP Configuration

DTLS-SRTP configuration on the SBC consists of the following steps.

  1. Identify the valid ciphers that use can use on the endpoint(s). You must set the cipher-list on tls-profile to match the endpoint(s), or set the list to ALL.
  2. Create one or more TLS Security Policies that specify key exchange protocols and protocol-specific profiles.
  3. Create one or more DTLS-SRTP profiles, which specify parameter values negotiated during the offer/answer exchange.
  4. Assign a TLS Security Policy to your DTLS-SRTP profile.
  5. Assign your DTLS-SRTP profile to a realm.
Configure DTLS-SRTP

A DTLS-SRTP profile specifies the parameter values offered or accepted during DTLS negotiation.

To configure DTLS-SRTP profile parameters:

Create one or more TLS Security Policies that specify key exchange protocols and protocol-specific profiles.
  1. From superuser mode, use the following command sequence to access dtls-srtp-profile configuration mode. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# media-security
ORACLE(media-security)# dtls-srtp-profile
ORACLE(dtls-srtp-profile)#
  2. Use the required name parameter to provide a unique identifier for this dtls-srtp-profile instance.

    name enables the creation of multiple dtls-srtp-profile instances.

  3. Use the required tls-profile parameter to assign the TLS profile you created for this dtls-srtp-profile instance.
  4. Use the required dtls-completion-timeout parameter to specify a time limit to the DTLS handshake.
    Values range from 0 (Default) to 999999 seconds.
  5. Define the system as a server using the preferred-setup-role parameter.
    • passive—Proposes that the SBC perform the server role.
  6. Use the crypto-suite parameter to select the encryption and authentication algorithms accepted or offered by this dtsl-srtp-profile.

    Allowable values are:

    • SRTP_AES128_CM_HMAC_SHA1_80 (default)—Enables support for the AES/128 bit key for encryption and HMAC/SHA1-180-bit digest for authentication.
    • SRTP_AES128_CM_HMAC_SHA1_32—Enables support for the AES/128 bit key for encryption and HMAC/SHA1-132-bit digest for authentication.
    • SRTP_AEAD_256_GCM
  7. Use done, exit, and verify-config to complete configuration of this DTLS profile instance.
  8. Repeat Steps 1 through 8 to configure additional DTLS-SRTP profiles.
Assign the DTLS-SRTP Profile to a Realm

DTLS-SRTP profiles become active on the SBC when you apply them to a realm-config.

To assign a media-security-policy to a realm:

Create one or more dtls-srtp profiles.
  1. From superuser mode, use the following command sequence to access realm-config configuration mode. While in this mode, you assign an existing dtls-srtp-policy to an existing realm. 
    ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)# select
identifier:
1. access-1
...
...
selection: 1
ORACLE(realm-config)#
  2. Use the dtls-srtp-profile parameter to assign the policy to the target realm.
  3. Use done, exit, and verify-config to complete assignment of the media-security-policy to the realm.

Reporting on DTLS-SRTP Statistics

The use of DTLS-SRTP generates specific traffic detail that you can review from the SBC ACLI.

The show security command produces a wide array of security-related statistics, including DTLS-SRTP status and issues. The most applicable information associated with DTLS-SRTP operation presented by show security includes the following:

  • show security dtls-srtp < all | realm_id >—Displays system-wide SRTP session counts. The show security command is covered in the Viewing ETC NIU Statistics section of the Maintenance and Troubleshooting Guide.

The show security dtls-srtp can provide system-wide or realm-specific statistics on DTLS-SRTP traffic, as shown below. When you run the command without any arguments, the system displays DTLS-SRTP status on each realm. The output below indicates that there are not any active sessions on either realm. When you add the all argument, the system displays traffic statistics for each realm. You can narrow this output by specifying realm_ID. 

ORACLE# show security dtls-srtp
17:40:07 - 133
core        Idle
peer        Idle
ORACLE# show security dtls-srtp all
17:40:10 - 136 Realm = core
                               –----Lifetime----
                     Recent      Total      PerMax
Packets Recv              0          3          2
Handshake Complete        0          1          1
Handshake Error           0          0          0
Fingerprint Error         0          0          0
Timeout                   0          0          0
UnsupportedSrtpProfile    0          0          0
KeyMaterialExportError    0          0          0
KeyApplyOnFlowError       0          0          0
InternalError             0          0          0
17:40:10 - 136 Realm = core

                               –----Lifetime----
                     Recent      Total      PerMax
Packets Recv              0        122         22
Handshake Complete        0          5          5
Handshake Error           0          0          0
Fingerprint Error         0          0          0
Timeout                   0          0          0
UnsupportedSrtpProfile    0          0          0
KeyMaterialExportError    0          0          0
KeyApplyOnFlowError       0          0          0
InternalError             0          0          0

In addition, the show datapath command can display statistics related to DTLS-SRTP. This command, however, is extremely complex and can produce sensitive and high overhead output. Oracle recommends you contact technical support for assistance with the show datapath command.