HMU Support for RTP to SRTP Interworking
The Oracle® Enterprise Session Border Controller (ESBC) supports Real-Time Transport Protocol (RTP) to Secure Real-Time Transport Protocol (SRTP) interworking Function by monitoring and correcting unexpected changes to session continuity information. You can enable the hide-egress-media-update parameter on the applicable realm.
RFC 3350 does not require RTP to maintain sequential packet sequence numbering. In contrast, STRP does not allow significant packet sequence number changes or resets to zero. To compensate for this, the ESBC can detect such changes and calculate and transmit the correct values to the SRTP end station when needed.
When configured to support RTP to SRTP interworking, the HMU function latches previous Synchronization Source (SSRC) sequence numbers and timestamps from RTP packets and watches for changes to ensuing sequence numbers on an ongoing basis. Sequence number changes the HMU function acts on include resets to zero and jumps downward. The HMU logic performs calculations on the latched sequence number, and populates the egress packet with a new sequence number that the SRTP end station can recognize as valid. When the sequence number in the RTP changes and the HMU is disabled, the ESBC cannot support RTP to SRTP interworking and cannot forward the packets.
SRTP considers downward sequence number changes greater than 127 as indicating the packet is a replay packet that should be discarded. The HMU function monitors for sequence number decreases greater than 127 and resets to zero. When the ESBC detects such a change, it invokes the HMU logic that sets the prescribed values in the SRTP traffic before egress.
Note:
Configuration on the ingress realm differs from standard HMU configuration, which you configure on the egress realm. Similarly, bi-directional HMU is not relevant for RTP to SRTP interworking.For example, consider configuring for single-ended SRTP sessions between a core (unencrypted) realm and a peer (encrypted) realm. To do this, you configure the core realm media security policy (inbound and outbound) to RTP mode. In addition, you configure the peer realm media security policy (inbound and outbound) to SRTP mode. After the ESBC establishes the session flows through signaling, it applies the media security policy to ingress RTP packets from the inbound realm and transmits them through the outbound realm as SRTP.
The following call flow depicts the ESBC using HMU to support RTP to SRTP interworking. The call sets up normally with RTP and SRTP interworking properly. The RE-INVITE from UE #1 triggers the HMU logic, which manages the RTP packet sequence numbers and prevents the SRTP leg from dropping media packets, or eventually, the call.