Restricted Media Latching
The restricted media latching feature lets the Oracle® Enterprise Session Border Controller latch only to media from a known source IP address, in order to learn and latch the dynamic UDP port number. The restricting IP address’s origin can be either the SDP information or the SIP message’s Layer 3 (L3) IP address, depending on the configuration.
About Latching
Latching is when the Oracle® Enterprise Session Border Controller listens for the first RTP packet from any source address/port for the destination address/port of the Oracle® Enterprise Session Border Controller. The destination address/port is allocated dynamically and sent in the SDP. After it receives a RTP packet for that allocated destination address/port, the Oracle® Enterprise Session Border Controller only allows subsequent RTP packets from that same source address/port for that particular Oracle® Enterprise Session Border Controller destination address/port. Latching does not imply that the latched source address/port is used for the destination of the reverse direction RTP packet flow (it does not imply the Oracle® Enterprise Session Border Controller will perform symmetric RTP).
Restricted Latching
The Oracle® Enterprise Session Border Controller restricts latching of RTP/RTCP media for all calls within a realm. It latches to media based on one of the following:
- SDP: the IP address and address range based on the received SDP c= connect address line in the offer and answer.
- Layer 3: the IP address and address range based on the received L3 IP address of the offer or answer. This option is for access registered HNT endpoints. If the L3 IP address is locally known and cached by the Oracle® Enterprise Session Border Controller as the public SIP contact address, that information could be used instead of waiting for a response. The Oracle® Enterprise Session Border Controller might use the L3 IP address restriction method for all calls regardless of whether the endpoint is behind a NAT or not, for the same realms.
Symmetric Latching
A mode where a device’s source address/ports for the RTP/RTCP it sends to the Oracle® Enterprise Session Border Controller (ESBC) that are latched, are then used for the destination of RTP/RTCP sent to the device.
After allocating the media session in SIP, the ESBC sets the restriction mode and the restriction mask for the calling side as well as for the called side. It sets the source address and address prefix bits in the flow. It also parses and loads the source flow address into the MIBOCO messages. After receiving the calling SDP, the ESBC sets the source address (address and address prefix) in the appropriate flow (the flow going from calling side to the called side). After receiving the SDP from the called side, the ESBC sets the source address in the flow going from the called side to the calling side.
The ESBC uses either the address provided in the SDP or the layer 3 signaling address for latching. You also configure the ESBC to enable latching so that when it receives the source flow address, it sets the address and prefix in the NAT flow. When the NAT entry is installed, all the values are set correctly. In addition, sipd sends the information for both the incoming and outgoing flows. After receiving SDP from the called side sipd, the ESBC sends information for both flows to the MBCD so that the correct NAT entries are installed.
Enabling restricted latching may make the ESBC wait for a SIP/SDP response before latching, if the answerer is in a restricted latching realm. This is necessary because the ESBC does not usually know what to restrict latching to until the media endpoint is reached. The only exception could be when the endpoint’s contact/IP is cached.
Relationship to Symmetric Latching
The current forced HNT symmetric latching feature lets the Oracle® Enterprise Session Border Controller assume devices are behind NATs, regardless of their signaled IP/SIP/SDP layer addresses. The Oracle® Enterprise Session Border Controller latches on any received RTP destined for the specific IP address/port of the Oracle® Enterprise Session Border Controller for the call, and uses the latched source address/port for the reverse flow destination information.
If both restricted latching and symmetric latching are enabled, the Oracle® Enterprise Session Border Controller only latches if the source matches the restriction, and the reverse flow will only go to the address/port latched to, and thus the reverse flow will only go to an address of the same restriction.
- Symmetric latching is enabled.
If symmetric latching is enabled, the Oracle® Enterprise Session Border Controller sends the media in the opposite direction to the same IP and port, after it latches to the source address of the media packet.
- Symmetric latching is disabled.
If symmetric latching is disabled, the Oracle® Enterprise Session Border Controller only latches the incoming source. The destination of the media in the reverse direction is controlled by the SDP address.
Example 1
A typical example is when the Oracle® Enterprise Session Border Controller performs HNT and non-HNT registration access for endpoints. Possibly the SDP might not be correct, specifically if the device is behind a NAT. Therefore the Oracle® Enterprise Session Border Controller needs to learn the address for which to restrict the media latching, based on the L3 IP address. If the endpoint is not behind a NAT, then the SDP could be used instead if preferred. However, one can make some assumptions that access-type cases will require registration caching, and the cached fixed contact (the public FW address) could be used instead of waiting for any SDP response.
Example 2
Another example is when a VoIP service is provided using symmetric-latching. A B2BUA/proxy sits between HNT endpoints and the Oracle® Enterprise Session Border Controller, and calls do not appear to be behind NATs from the Oracle® Enterprise Session Border Controller’s perspective. The Oracle® Enterprise Session Border Controller’s primary role, other than securing softswitches and media gateways, is to provide symmetric latching so that HNT media will work from the endpoints.
To ensure the Oracle® Enterprise Session Border Controller’s latching mechanism is restricted to the media from the endpoints when the SIP Via and Contact headers are the B2BUA/proxy addresses and not the endpoints’, the endpoint’s real (public) IP address in the SDP of the offer/answer is used. The B2BUA/proxy corrects the c= line of SDP to that of the endpoints’ public FW address.
The Oracle® Enterprise Session Border Controller would then restrict the latching to the address in the SDP of the offer from the access realm (for inbound calls) or the SDP answer (for outbound calls).
Restricted Latching using Address and Port
You can configure the system to latch all media flows within a realm to both the externally provided address and port when you set the restricted-latching mode to sdp-ip-port. When configured to this setting, the system latches to media based on the IP Address received in the SDP c= connect address line, and the port in the mline in the offer and answer. This differs from standard latching in that the port is left unassigned by the ESBC. This feature allows the ESBC to better support multiple RTP streams from different ports using the same IP address, such as within forking scenarios.
When configuring latching to sdp-ip-port, the ESBC supports:
- Latching to IP and port within early media scenarios and call establishment phases
- Re-latching when an SDP update received in a 200 OK is different than the one received in a provisional response
- Re-latching to media based on IP and port within reINVITE/UPDATE
scenarios, when the media is updated after call establishment including:
- Updating the latching after the 200 OK when the media is updated by reINVITE/UPDATE scenarios
- Updating the latching within call transfer scenarios involving forking.
- Maintaining latching established during early media stages when the 200 OK does not include SDP
- Maintaining latching established by the most recent provisional response when the 200 OK does not include SDP
Note:
If you downgrade to a version that does not support this feature, the system changes the restricted-latching setting to none. Upgrades and downgrades to system with feature compatibility retain your setting.Related Configuration
If you have enabled rtcp-mux in conjunction with this feature, the system installs un-collapsed flows for RTP and RTCP that include IP and port in both the east and west realms. This is true if you have enabled rtcp-mux and this feature on one or both of these realms. In these cases, the system installs these uncollapsed flows on both realms and supports only the following two port assignments for RTCP:
- RTP port
- RTP port + 1
The table below presents the way the ESBC assigns and handles RTCP differently, based on restricted-latching configuration and RTCP input.
| restricted-latching Configurations | RTCP sent from UAC mline (RTP) even port to ESBC RTP port (even port) | RTCP from UAC mline port (RTP) to ESBC RTP+1 port (odd port) | RTCP from UAC mline port+1 (UAC odd port) to ESBC RTP port (even port) | RTCP from UAC mline port+1 (odd port) ESBC RTP+1 port (odd port) |
|---|---|---|---|---|
|
UAC realm— sdp UAS realm— disabled Media is sent from UAC |
RTCP is forwarded to RTP port of the UAS via ESBC egress even port | RTCP is forwarded to RTP+1 port towards UAS from egress odd (RTP+1) port of ESBC | RTCP is forwarded to RTP even port of UAS from egress even ESBC port | RTCP is forwarded to RTP+1 port towards UAS from ESBC odd port (RTP+1) |
|
UAC realm— sdp-ip-port UAS realm— disabled Collapsed flows installed |
RTCP is forwarded to RTP port of UAS via ESBC egress even port | RTCP is forwarded to RTP+1 port towards UAS from egress odd (RTP+1) port of ESBC | RTCP is forwarded to RTP even port of UAS from egress even ESBC port | RTCP is forwarded to RTP+1 port towards UAS from ESBC odd port (RTP+1) |
In addition, when you enable this feature the ESBC installs fully qualified NAT flows. This effectively disables latching on the IP and port within RTP media. As a result, you should not enable this feature in conjunction with features that require explicit RTP packet based latching. For example, this feature effectively overrides dynamic-latching.
Reporting on the Feature
For UAC to UAS call when the feature is enabled on both the realms, the show nat in-tabular command displays the NAT flow similar to the output below. Note the assigment of port 0 in the first output below, In this case, restricted-latching is set to sdp.
ORACLE# show nat in-tabular
Index Prot Intf:Vlan Src IP:Port Dst IP:Port
------------------------------------------------------------------------------
2 udp I=0/0:300 192.168.204.100:0 192.168.204.124:10000
O=0/0:100 172.16.204.124:10000 172.16.204.100:11000
3 udp I=0/0:100 172.16.204.100:0 172.16.204.124:10000
O=0/0:300 192.168.204.124:10000 192.168.204.100:10000Note the assigment of port 10000 instead of 0 in the second outut below, In this case, restricted-latching is set to sdp-ip-port.
ORACLE# show nat in-tabular
Index Prot Intf:Vlan Src IP:Port Dst IP:Port
--------------------------------------------------------------------
2 udp I=0/0:300 192.168.204.100:10000 192.168.204.124:10000
O=0/0:100 172.16.204.124:10000 172.16.204.100:11000
3 udp I=0/0:100 172.16.204.100:11000 172.16.204.124:10000
O=0/0:300 192.168.204.124:10000 192.168.204.100:10000The ESBC installs these fully qualified flows on offer-answer completion, before it receives the RTP.
Call Flows Supporting Restricted Latching to Address and Port
A key problem resolved by latching on IP and port is the handling of multiple streams created by a single external device, such as an Enhanced Communications Network Application Server (ECN AS) forking an INVITE. Without this feature, the system implements restricted latching such that the latching is dependent on the external device, which may adversely impact which RTP stream (or streams) get played back to the caller.
Parallel Ringing before Answer
Consider a scenario wherein an ECN AS uses parallel forking to route a call via the ESBC to several users. The ECN AS hides the multiple early dialogs from the ESBC and forwards only one of them. There are, however, multiple RTP streams created from the Media Gateway (MGW) towards the ESBC, one for each branch. The best way to setup such a call would result in the caller receiving only the RTP in the 18x SDP response from the ECN AS.
When you configure restricted-latching to sdp-ip-port, the ESBC can also handle SDP changes, including RTP target and source. If the initial SDP becomes invalid within this forking scenario, the ECN AS would update the ESBC with subsequent SDP. This update could come in an UPDATE with SDP or a new 18x with SDP, depending on the environment's support for 100rel/PRACK. The ESBC would handle these changes, including changing the callee.
When you set restricted-latching to sdp, the system successfully blocks RTP streams from different addresses. But if there are multiple RTP streams coming from different ports on a single IP address, the system admits all of these. This can result in the calling party hearing a mixed early media stream. When set to sdp-ip-port, however, the ESBC latches based on the IP and port in the SDP from the ECN AS, thereby limiting the audible RTP to a single flow.
Note:
The AS updates the SDP only if a called party was selected during the answer phase other than the called party that was selected during alerting phase. Therefore, it is important that the ESBC performs latching and re-latching based on IP address and port from the SDP. This way, the AS is also aware of which called party media stream is active.Note:
If the final 200 OK for the INVITE does not contain SDP, the ESBC stays latched to the most recent IP/port received in a 18x during the early media stage.In the call flow below, you have configured restricted-latching to sdp-ip-port on the UAS realm. The called stations could be behind the Media Gateway (MGW) interfacing the PSTN/PLMN) or multiple IP’s, and served by a Media Gateway Controller (MGC).
Parallel Ringing and Re-Latching before Answer Based on an UPDATE
If an UPDATE comes from the ECN before the call is answered, the ESBC is able to re-latch to a new RTP stream, as shown below. In the call flow, the ESBC latches to SDP_2, forwarding only that RTP. The MGC, however, issues a 18x requesting SDP_3 before the call is answered. Upon receiving this UPDATE, the ESBC re-latches to SDP_3. Subsequently, the call is answered and RTP_3 media proceeds without issue.
Latching during Answer
At the end of the signaling, the ECN AS sends a 200 OK that often has the SDP that the ESBC must forward to the calling party. Without enhanced restricted latching, the ESBC latches to the first RTP stream that arrives after the 200 OK. This RTP stream may not be the same RTP stream identified in the SDP of the 200 OK, resulting in silence at the caller.
When you set restricted-latching to sdp, the ESBC admits any RTP stream from the IP in the SDP. When you set restricted-latching to sdp-ip-port, the ESBC controls the latching using both IP and port received in the 200 OK SDP. This setting ensures that the correct RTP stream gets forwarded.
Note:
Note: If the SDP is not updated after the early media stages, the 200 OK may not include any SDP. Therefore, it is important that the AS knows the media stream onto which the ESBC has latched. This requires enhanced restricted latching.In the call flow below, you have configured restricted-latching to sdp-ip-port on the UAS realm. The called stations could be behind the Media Gateway (MGW) interfacing the PSTN/PLMN) or multiple IP’s, and served by a Media Gateway Controller (MGC).
Latching after 200 OK in Case of reINVITE/UPDATE
Applicable scenarios include media re-negotiation after the call is answered are supported. These scenarios may happen when the ECN AS uses parallel forking to redirect or transfer the call after answer.
When you set restricted-latching to sdp, the ESBC admits streams from the same IP, which could be multiple streams if multiple endpoints are behind the gateway. Subsequently, the ESBC forwards all RTP streams it receives from, in this case, an MGW.
Depending on the calling party’s client, the calling party would hear either a mix of ringback tones, silence, or a single ringback tone. When you set restricted-latching to sdp-ip-port, the ESBC latches the media based on the IP and port in the reINVITE/UPDATE received after the call has been established. This results in the ESBC forwarding only the RTP stream identified in the SDP from ECN AS to the calling party.
In the call flow below, you have configured restricted-latching to sdp-ip-port on the UAS realm. The called stations could be behind the Media Gateway (MGW) interfacing the PSTN/PLMN) or multiple IP’s, and served by a Media Gateway Controller (MGC).
