Symmetric Latching
Symmetric latching, or forced HNT, ensures that symmetric RTP/RTCP is used for a SIP endpoint. Symmetric RTP/RTCP means that the IP address and port pair used by an outbound RTP/RTCP flow is reused for the inbound flow. The IP address and port are learned when the initial RTP/RTCP flow is received by the Oracle Communications Session Border Controller. The flow's source address and port are latched onto and used as the destination for the RTP/RTCP sourced by the other side of the call. The IP address and port in the c line and m line respectively in the SDP message are ignored.
If your network is configured with nested realms in order to separate signalling from media, make sure that the symmetric latching feature is enabled on the signaling realm.
Note:
This description is applicable to RTCP only when you also enable the HNT RTCP option in the media-manager configuration. Do not enable symmetric latching on core-facing interfaces.SIP Pre-emptive Symmetric Media Latching
The Oracle Communications Session Border Controller (SBC) supports symmetric media latching within a realm. However, when two SBCs are in different realms and both realms are configured for symmetric latching, then both will wait for received media packets from the other before transmitting, which results in dropped calls. This feature lets the user configure the SBC to transmit its RTP packets pre-emptively to the peer SDP connection address and then to re-latch the peer RTP source address after receiving the first RTP packet from that peer.
In a call forwarding scenario where a media server (MS) behind Network Address Translation (NAT) is between two SBCs, both SBCs will detect NAT, so both will wait to receive RTP packets before latching to the RTP source address. This feature prevents this by adding the new value pre-emptive to the configuration option parameter symmetric-latching in the configuration element realm-config. When the value is set to pre-emptive, the SBC sends the RTP packets to the received SDP connection address without waiting on the latch. Once the RTP packets are received from the peer endpoint, the SBC detects the NAT address mapping; if there is a change in the RTP source address, the SBC re-latches to the new RTP source address. Subsequent RTP packets are then sent to the peer RTP source address. This is also the behavior when there is an UPDATE or reINVITE with the SDP message.