EOM / OCOM / OCSM Call Flow Showing Media Flows from/to Incorrect IP Addresses (Doc ID 2271213.1)

Last updated on NOVEMBER 21, 2023

Applies to:

Symptoms

The Call Flow in EOM shows Media Flows from or to IP addresses which should not belong to the call flow. Usually this issue is more visible when interim QOS reports are enabled on SBC (available only on 3900, 4600 and 6300 platforms) , and the visible effect is that at some points within the call flow there is a new Media stream to or from an incorrect IP address, sometimes as often as every 10 seconds.

How to recognize this issue?

This issue occurs when latching is disabled for specific streams. On most SBC installations, by default, latching is enabled in media-manager. However, whenever the source contacts of a stream gets changed in the SDP, for example when an ACK or a re-INVITE changes the initially negotiated SDP information, the SBC disables latching in order to accommodate the contact change. The issue referred in this article is that at this point, the SBC starts reporting incorrect random source or destination IPs in the VQ reports sent to EOM.

The situation explained above (the source IP and ports of a stream get changed after the media session was already established in the SDP, for example when an re-INVITE or an ACK changes the initially negotiated SDP information) will be further referred in this article as SDP re-negotiation.Thus, a common case where this issue occurs is on call flows with SDP re-negotiation initiated by caller or callee (so not by SBC).

Another way to confirm that this is the suspected issue is by checking the latching on the SBC: during the time the stream is established, for stream with latching disabled you should see 0.0.0.0 in the NAT table if you do the following:

a) Establish a call where the SBC is reporting incorrect IPs
b) Execute the following command: show nat by-addr <src IP> <dest IP> (you can use 0 as widcard)
c) The output previous command will output flow information with Index numbers. Choose the Index that relates to the call
d) Execute the following command: show nat by-index <start index> <end index>
*The <start index> and <end index> in step (d) above should be the index(es) output by step (b). If only one index was output by the command in step (b), then specify the same value for <start index> and <end index>

If the stream shows 0.0.0.0:0 under Src IP:Port, then it means latching is disabled for this flow, for example:

In "show nat by-addr":

SBC# show nat by-addr 0 x.xx.xx.10

Index   Prot   Intf:Vlan  Src IP:Port                   Dst IP:Port
------------------------------------------------------------------------------
196     udp    I=0/0:0    0.0.0.0:0                     x.xx.xx.10:10068
               O=0/1:0    x.yy.xx.10:30068              x.xx.x.12:6088

In "show nat by-index":

# show nat by-index 196

-------------------------------------------------------------
Total number of NAT entries = 27

-------------------------------------------------------------
--------------------------------------------------------------------------------
NAT host index (ppx flow id) 196, flowId 0xc4 :
Flow type: Unresolved non-latching media flow (MEDIA)
KEY: src info   : 0.0.0.0/0 : 0/0
KEY: dst info   : x.xx.xx.10/32 : 10068/15
KEY: ingres info: slot/port 0/0 (intf 0),  vlan 0,  proto udp(17)
 
RES:  src result: sa x.yy.xx.10 : 30068
RES:  dst result: da x.xx.x.12 : 6088
RES: egress info: slot/port 0/1 (intf 1), vlan 0, l2index 3

If the current document applies, such a call should result in incorrect RTP reports.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.