DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

Related articles:

 

The SBC Core supports DTLS-SRTP and is extended to allow a relay mechanism that transparently passes the DTLS, SRTP, and SRTCP packets end-to-end without DTLS certification or SRTP cryptographic encryption and decryption taking place at SBC. When SBC is configured to relay DTLS-SRTP, the endpoints establish DTLS association using each other’s credentials, which are transparently passed by SBC in the SDP of the SIP signaling messages. Encryption and decryption of the SRTP and SRTCP packets take place at the endpoints based on the cryptographic credentials passed through DTLS. If media transcoding, DTMF interworking, Lawful Intercept (LI) or 'Tones and Announcements' processing is required on the session, as determined during the initial invite or offer call negotiation stage, DTLS-SRTP is not relayed.

Enable dtlsSrtpRelay on both legs of the call for DTLS/SRTP stream to be relayed.

DTLS-SRTP relay is a licensed feature and requires an SRTP license to be installed on the SBC.

This feature also adds relay support for DTLS-SCTP media streams that is not based on RTP but relayed transparently by the SBC. When the SBC is configured to relay DTLS-SCTP, the DTLS and SCTP packets are transparently passed end-to-end and the peer endpoints establish the DTLS association using each other’s credentials, which are transparently passed by the SBC in the SDP of the SIP signaling messages.

When DTLS-SCTP relay control is not enabled on both legs of the call and if DTLS-SCTP stream is received as a part of SDP with audio and/or video, the SBC rejects the DTLS-SCTP stream with port 0.

Enable dtlsSctpRelay on both legs of the call for DTLS-SCTP stream to be relayed.

When DTLS-SRTP and/or DTLS-SCTP stream requires ICE to traverse NAT, the relay mechanism is supported with ICE procedures terminated locally at SBC. DTLS-SRTP and/or DTLS-SCTP packets are transparently passed by the SBC, once ICE processing is complete.

DTLS-SCTP stream is logged in Call Detail Record (CDR) as UDP/DTLS/SCTP in fields 230/231. When a DTLS-SRTP stream is relayed, it is indicated in fields 242/243 where 1 indicates the stream is terminated and 2 indicates the stream is relayed.

Warning

When a session contains DTLS-SRTP video stream or DTLS-SCTP application stream and there is no audio stream specified, the SBC allows the session when the ingress and egress Packet Service Profiles (PSP) are configured as audio pass-through.

In case of WRTC, when ICE is part of session establishment, the relay mechanism implemented for DTLS-SRTP and DTLS-SCTP is supported independent of ICE processing.

  • If DTLS is enabled along with DTLS-SRTP relay and if a RTP call is upgraded to DTLS-SRTP, SBC terminates DTLS.
  • If both DTLS-SRTP relay and SRTP relay are enabled, and the ingress offer has included DTLS-SRTP, when the egress peer answers with RTP then allowFallback is enabled on the DTLS-SRTP and SRTP profile to fallback to RTP, else the call is rejected with 488.

  • No labels