1. Configuration Guide
  2. Security
  3. DTLS-SRTP
  4. ESBC Support for DTLS-SRTP
  5. Example DTLS-SRTP Flows

Example DTLS-SRTP Flows

The call flows below present the ESBC 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 ESBC (eg, from Alice) and egress flowing from the ESBC (eg, to Bob).

In this flow, the ESBC 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 ESBC 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 ESBC 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 ESBC as normal audio RTP over UDP.
  3. The ESBC handles the reply, up to and including the 200 OK from Bob and to Alice.

    The SDP that the ESBC sends to Alice includes:

    • The “m” attribute, indicating media transport uses DTLS-SRTP.
    • The “a=setup:passive” attribute indicating that the ESBC acts as the TLS server, receiving the DTLS connection from Alice.
    • The “a=fingerprint” attribute. This is the ESBC 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 ESBC. 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 ESBC 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 ESBC.
  6. Alice calculates the hash of the certificate and compares it against the ESBC 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 ESBC.

    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 ESBC 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 ESBC 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 ESBC 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 ESBC, verifying the client certificate.
  11. Alice send a DTLS Change Cipher Spec, Finished Message message to the ESBC,

    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 ESBC send a DTLS Change Cipher Spec, Finished Message message to Alice.

    At this point, both the ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC subsequently sends an INVITE to Bob that also includes a=sendonly.
  3. Bob replies to the ESBC with a 200 OK that includes a=recvonly.
  4. The ESBC 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 ESBC follows suit with Bob.
  8. Upon acknowledgment, Alice resumes the SRTP flow with the ESBC, which resumes the RTP flow with Bob.

Blind Call Transfer using Unattended REFER

The ESBC 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 ESBC manages the call, supporting SRTP/RTP interworking. When the callee issues a REFER, it becomes the transferor. Both the ESBC and the softswitch support the REFER, ending the original call and performing a new SIP INVITE sequence. The ESBC 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 ESBC and softswitch to establish SRTP from the caller to the ESBC and RTP from the ESBC 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 ESBC establish DTLS-SRTP media; the softswitch releases the media and the ESBC 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 ESBC 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 ESBC 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 ESBC provides this NOTIFY to the softswitch and the transferor, upon which the transferor issues a BYE to the ESBC. The BYE makes its way to the transferee through the ESBC and the softswitch.
  5. Upon receiving the BYE, the transferee issues an new INVITE sequence that traverses the ESBC, the softswitch and, reaches the REFER target. These INVITEs include one to setup DTLS-SRTP between the transferee and the ESBC, and RTP from the ESBC 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.