My Oracle Support Banner

Incomplete RTP flows in Message Flow Diagram (Doc ID 2623704.1)

Last updated on FEBRUARY 06, 2020

Applies to:

Acme Packet 4600 - Version E-Cz8.0.0 to S-Cz8.3.0 [Release E-Cz8.0 to S-Cz8.0]
Oracle Communications Session Monitor - Version 3.4.x to 4.2 [Release 3.0 to 4.0]
Information in this document applies to any platform.

Symptoms

OCOM fails to display RTP flows on incoming leg of a call. This call was received from an SBC probe.

A <-----------------------------------------SBC----------------------------------------> B

x1.x1.x1.x1 .               x2.x2.x2.x2                 x3.x3.x3.x3                       x4.x4.x4.x4

Troubleshooting steps:

Capture ipfix trace on SBC probe and decode this IPFIX trace. (Procedure listed on Document 2006842.1,  How to Print the Content of a Traffic Capture between an SBC and Palladion/Oracle Communications Session Monitor (Doc ID 2006842.1))

If we see decoded ipfix messages we can see SBC did send RTP stats for actual media flow, but since latching was enabled, source IP was set to 0.0.0.0 (until first RTP arrives on SBC)

media type: audio (1)
Calling Flow Info
inflow : 0.0.0.0:0 -> x2.x2.x2.x2:abcd
outflow: x3.x3.x3.x3:abcd -> x4.x4.x4.x4:abcd
Called Flow Info
inflow : x4.x4.x4.x4:abcd -> x3.x3.x3.x3:abcd
outflow: x1.x1.x1.x1:abcd -> x2.x2.x2.x2:abcd

However OCOM was expecting flow from negotiated media-ip, same can be seen in vsi-debug log captured while playing this ipfix packets: (Procedure to capture vsi-debug listed in Document : (Doc ID 1996114.1))

DEBUG (Thread 225fb700) (media_data.c:259 debug_print_sdp_stream) new sdp:
mediatype:0 proto:2 a(x1.x1.x1.x1:abcd) b(x2.x2.x2.x2:abcd) dir:0 DEBUG (Thread 225fb700) (media_leg_store.c:155 debug_print_ml) media leg created: type:0 a(x1.x1.x1.x1:abcd) b(x2.x2.x2.x2:abcd) leg id:3
DEBUG (Thread 225fb700) (thread_local.hh:55 T* iptego::Thread_Local<T,
M>::get() const [with T = libpldipc::rtp::MediaLegUpdate; M =
iptego::TL_def_manager]) Allocating thread specific data for
N9libpldipc3rtp14MediaLegUpdateE.

If we play pcap of this call directly (and not ipfix trace via SBC Probe), RTP flows can be seen properly. Because direct replay is different than real time ipfix replay.

 

Changes

 

Cause

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Symptoms
Changes
Cause
Solution
  
References


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