VoIP CC not received (IRI works, but CC connection is missing)

[mekardogan]

Hi,

In the latest version of OpenLI, VoIP intercepts do not receive CC (Call Content), while IRI (Intercept-Related Information) is received correctly.

The same configuration worked fine in the previous version, where VoIP CC was successfully received. However, after updating to the latest version:

Email and IP intercepts successfully receive both IRI and CC.
VoIP intercepts only receive IRI, but CC does not connect at all.

Observations & Issue Details:

Our configuration is set to outputhandover all.
RabbitMQ queues for both IRI and CC are created, but:
    IRI is received successfully.
    CC queue exists but remains empty (no connection established).
In the previous version, VoIP CC was working fine with the same configuration.
Email and IP intercepts work correctly, receiving both IRI and CC, but VoIP CC is missing.

Expected Behavior:

When a VoIP intercept is created, both IRI and CC should be delivered.
OpenLI should handle VoIP CC the same way it did in previous versions without any missing content.

Current Configuration

Below are our OpenLI Collector, Mediator, and Provisioner configurations:
Provisioner Configuration (provisioner-config.yaml):
clientport: 9001
clientaddr: 172.19.0.2
updateport: 8080
updateaddr: 172.19.0.2
mediationport: 9002
mediationaddr: 172.19.0.2

intercept-config-file: /etc/openli/running-intercept-config.yaml

#tlscert:
#tlskey:
#tlsca:

#restauthdb: /var/lib/openli/provauth.db
#restauthkey:

Mediator Configuration (mediator-config.yaml):
operatorid: WAND

listenport: 12009
listenaddr: 172.19.0.3

provisioneraddr: 172.19.0.2
provisionerport: 9002

mediatorid: 1

etsitls: no

#tlscert:
#tlskey:
#tlsca:

RMQenabled: true
RMQname: "openli.nz"
RMQpass: qIGmPrxkTlrmJFAy
RMQSSL: false
RMQheartbeatfreq: 30

Collector Configuration (collector-config.yaml):
operatorid: WAND
networkelementid: openli-lab
interceptpointid: col001

encoderthreads: 4
sipthreads: 4
inputs:

• uri: lo
  threads: 4
  #hasher: radius
  #filter:

etsitls: no
sipallowfromident: yes
provisioneraddr: 172.19.0.2
provisionerport: 9001

RMQenabled: true
RMQname: openli.nz
RMQpass: qIGmPrxkTlrmJFAy
RMQSSL: false
#tlscert:
#tlskey:
#tlsca:

#alumirrors: []
#jmirrors: []

Running Interface(running-intercept-config.yaml):*
email-defaultdelivercompressed: as-is
sipservers:

• ip: 172.22.0.22
  port: 5060
  radiusservers: []
  gtpservers: []
  smtpservers: []
  imapservers: []
  pop3servers: []
  agencies:
• hi3address: 172.20.0.3
  hi3port: 43000
  hi2address: 172.20.0.3
  hi2port: 42000
  agencyid: mocklea
  keepalivefreq: 60
  keepalivewait: 30
  voipintercepts:
• liid: TESTVOIP001
  authcountrycode: NZ
  deliverycountrycode: NZ
  agencyid: mocklea
  mediator: 1
  starttime: 0
  endtime: 0
  payloadencryption: none
  outputhandovers: all
  siptargets:
  • username: 7001
    ipintercepts: []
    emailintercepts: []

Other intercepts (email, IP) successfully receive data, and RabbitMQ's Message Rates section shows active messages.
However, for VoIP CC, the queue is created but remains empty (Message Rates shows no data).
This suggests that while the mediator is connecting properly, the collector is not sending any VoIP CC data to RabbitMQ.
Since the same configuration worked in the previous OpenLI version, this could be a collector-side issue.

[salcock]

One thing to try would be to reduce the number of sipthreads in your collector configuration to 1.

If you do that, do you start to see CC's for voice calls appearing again at the mediator?

[mekardogan]

I have reduced the sipthreads value to 1 in the collector configuration and restarted all OpenLI services. However, the issue persists—VoIP intercepts still do not receive Call Content (CC), while Intercept-Related Information (IRI) is received successfully.
Updated Observations:

IRI (HI2) is working fine, but HI3 (CC) data is missing only for voipintercept.
Email and IP intercepts receive both HI2 and HI3 without issues.
RabbitMQ queue for HI3 (openli.hi3) exists but remains empty when using VoIP intercepts.
When reverting to an older OpenLI version, the same configuration correctly delivers HI3 (CC) data for VoIP.
Reducing sipthreads to 1 did not resolve the issue.
pjsip set logger on confirms that RTP traffic is present, and tcpdump captures RTP packets correctly.
The OpenLI collector does not appear to be processing RTP packets for VoIP CC.

Please let me know if there are any additional settings I should check or modifications that may be required in the latest version.

[YoungDopeGeek]

maybe your issue is because the sync_thread when faced to an voip_intercept push message, it send the sync message into x2_x3 interface except sending to SIP workers. look at recv_from_provisioner function in collector_sync.c

[salcock]

maybe your issue is because the sync_thread when faced to an voip_intercept push message, it send the sync message into x2_x3 interface except sending to SIP workers. look at recv_from_provisioner function in collector_sync.c

Sorry, but this is not correct. In the case of OPENLI_PROTO_START_VOIPINTERCEPT, what actually happens is:

• first x2x3_sync_voipintercept() is called as you mention.
• then, because there is no break; afterwards, the execution "falls through" to the code in the next block of case statements (i.e. OPENLI_PROTO_ANNOUNCE_SIP_TARGET and OPENLI_PROTO_WITHDRAW_SIP_TARGET)
• which then results in a call to forward_provmsg_to_workers() using the SIP worker message queues.
• there is a break at the end of this block, so the execution breaks out of the switch block.

The __attribute__ ((fallthrough)); line at the end of the OPENLI_PROTO_START_VOIPINTERCEPT case block tells both the compiler and anyone reading the code that this is behaviour is intended by the programmer.