Issue with IP/VoIP Interception and `etsilive` Format Recognition in OpenLI Setup

[laaurii00]

Hello OpenLI team,

I am currently working with an OpenLI deployment composed of four virtual machines: LEA, Provisioner, Collector, and Mediator (configured with mediatorid: 1). All OpenLI components were installed via RPM packages (https://github.com/OpenLI-NZ/openli/wiki/Installing-via-RPM) and are configured to communicate internally using classic TLS. The Provisioner exposes port 8080 for communication with the LEA.

The actual Provisioner, Collector and Mediator configuration is:
Provisioner:

    clientaddr: Provisioner_ip_enpXs0
    clientport: 9001
    mediationaddr:  Provisioner_ip_enpXs0
    mediationport: 9002
    updateaddr:  Provisioner_ip_enpXs0
    updateport: 8080
    
    tlscert: /etc/openli/provisioner-crt.pem
    tlskey: /etc/openli/provisioner-key.pem
    tlsca: /etc/openli/ca-crt.pem
    
    intercept-config-file: /etc/openli/running-intercept-config.yaml
    voip-ignorecomfort: no

Collector:

      operatorid: WAND
      networkelementid: openli
      interceptpointid: col001
      encoderthreads: 2
      RMQenabled: false
      RMQname: "openli.nz"
      RMQpass: "XXX"
      
      inputs:
        - uri: enpXs0
          threads: 2
          hasher: radius
      
      provisioneraddr:  Provisioner_ip_enpXs0
      provisionerport: 9001
      
      etsitls: yes
      tlscert: /etc/openli/collector-crt.pem
      tlskey: /etc/openli/collector-key.pem
      tlsca: /etc/openli/ca-crt.pem
      

Mediator:

      operatorid: WAND
      mediatorid: 1
      provisioneraddr:  Provisioner_ip_enpXs0
      provisionerport: 9001
      listenaddr:  Mediator_ip_enpXs0
      listenport: 12009
      
      etsitls: yes
      
      tlscert: /etc/openli/mediator-crt.pem
      tlskey: /etc/openli/mediator-key.pem
      tlsca: /etc/openli/ca-crt.pem
      
      RMQenabled: true
      RMQname: "openli.nz"
      RMQpass: "XXXX"
      RMQSSL: false
      RMQheartbeatfreq: 0
      RMQinternalpass: "XXX"

The LEA has been configured with the following parameters:

[
  {
    "agencyid": "LEA_VM",
    "hi3address": "LEA_ip_enpXs0",
    "hi2address": "LEA_ip_enpXs0",
    "hi3port": "3030",
    "hi2port": "2020",
    "keepalivefreq": 300,
    "keepalivewait": 30
  }
]

The ipinterface and voipinterface are configured as follows:

[
  {
    "liid": "TEST1",
    "authcc": "SP",
    "delivcc": "SP",
    "agencyid": "LEA_VM",
    "mediator": 1,
    "outputhandovers": 0,
    "payloadencryption": "none",
    "user": "roger",
    "accesstype": "fiber",
    "radiusident": "any"
  }
]

[
  {
    "liid": "TEST1",
    "authcc": "SP",
    "delivcc": "SP",
    "agencyid": "LEA_VM",
    "mediator": 1,
    "outputhandovers": 0,
    "payloadencryption": "none",
    "siptargets": [
      {
        "username": "steve",
        "realm": "myrealm.com"
      }
    ]
  }
]

However, when attempting to activate IP or VoIP interception, I encounter the following issues:

1. When trying to monitor HI2 and HI3 traffic using tracepktdump:

   sudo tracepktdump etsilive:LEA_ip_enpXs0:3030
   sudo tracepktdump etsilive:LEA_ip_enpXs0:2020

   I receive the error:

   trace_create: Unknown format (etsilive)
   

2. If I instead capture traffic using tcpdump:

   sudo tcpdump -i any host LEA_ip_enpXs0 and port 2020 -w captH2.pcap
   sudo tcpdump -i any host LEA_ip_enpXs0 and port 3030 -w captH3.pcap

   and then replay it using pcaps (This pcaps are from the laboratory):

   sudo tracereplay /pcap/tcpsip_voip.pcap ring:enpXs0
   sudo tracereplay /pcap/staticip.pcap ring:enpXs0

   nothing is received or processed.

Questions:

• What is required to enable support for the etsilive format in tracepktdump?
• Are there additional packages or configurations needed?
• What changes, if any, are required in the configuration files of the Collector, Mediator, or Provisioner to enable proper IP and VoIP interception?

Thank you very much for your support.

Best regards.

[salcock]

What is required to enable support for the etsilive format in tracepktdump?

The error message suggests that tracepktdump is running against a version of libtrace that was not compiled with libwandder support. Have you installed libtrace manually on the host where you are running tracepktdump at any point (even prior to installing it via an rpm package)?

What is the output if you run:

ldd `which tracepktdump`

?

Are there additional packages or configurations needed?

No, you just need to resolve the issue with the version of libtrace that is being used by your mock agency.

What changes, if any, are required in the configuration files of the Collector, Mediator, or Provisioner to enable proper IP and VoIP interception?

None that I can see at the moment. The reason you do not see any packets in your tcpdump pcaps is because the OpenLI mediator won't emit intercept records if the agency has not established a valid connection to the mediator.

When you use tracepktdump (or other libtrace tools) to receive etsilive: input, the tool connects to the mediator over TCP and the mediator will then send intercept records to the client over that socket.

tcpdump, by contrast, is simply passively sniffing the interface. It does not establish the necessary connection, and if there is no TCP connection to the mediator established, then there will be no packets for it to sniff.

[laaurii00]

Hello OpenLI team,
Thank you for your quick reply.

I solved the etsilive format problem by reinstalling libwandder, wandio and libtrace from the Github repository. The problem was that it was not exporting openssl dependent libraries (libssl.so) properly. Now, the Agency//LEA accepts:

sudo tracepktdump etsilive:LEA_ip_enpXs0:3030
sudo tracepktdump etsilive:LEA_ip_enpXs0:2020

However, when I start listening through HI2 and HI3 ports, it accepts the etsilive format and the Agent VM remains dormant waiting to suck traffic, but nothing is intercepted from the pcap emitted from the collector VM:

sudo tracereplay /pcap/tcpsip_voip.pcap ring:enpXs0
sudo tracereplay /pcap/staticip.pcap ring:enpXs0

The collector replay is:

May 14 08:16:11 Collector openli-collector[107749]:    ...done.
May 14 08:16:11 Collector systemd[1]: Started openli-collector.service - OpenLI collector daemon.
May 14 08:16:12 Collector openlicollector[107757]: OpenLI: received IP intercept from provisioner (LIID STATIC002, authCC NZ, start time 0, end time 0)
May 14 08:16:12 Collector openlicollector[107757]: OpenLI: intercepting static IP range 10.1.18.217/32 for LIID STATIC002, AuthCC NZ
May 14 08:16:12 Collector openlicollector[107757]: OpenLI: received IP intercept from provisioner (LIID TEST1, authCC SP, start time 0, end time 0)
May 14 08:16:12 Collector openlicollector[107757]: OpenLI: adding new VOIP intercept TEST1 (start time 0, end time 0)
May 14 08:16:12 Collector openlicollector[107757]: OpenLI: collector received new SIP target for LIID TEST1.

The mediator reply is:

May 14 10:26:47 Mediator openlimediator[109943]: OpenLI Mediator: Connected to provisioner at LEA_ip_enpXs0:9001
May 14 10:26:47 Mediator openlimediator[109943]: OpenLI Mediator: Disconnecting from provisioner.
May 14 10:26:48 Mediator openlimediator[109943]: OpenLI mediator: SSL Handshake complete for connection to provisioner
May 14 10:26:50 Mediator openlimediator[109943]: OpenLI mediator: SSL Handshake complete for connection to provisioner
May 14 10:26:51 Mediator openlimediator[109943]: OpenLI mediator: SSL Handshake complete for connection to provisioner
May 14 10:26:51 Mediator openlimediator[109943]: OpenLI Mediator: Connected to provisioner at LEA_ip_enpXs0:9001
May 14 10:26:51 Mediator openlimediator[109943]: OpenLI Mediator: Disconnecting from provisioner.
May 14 10:26:52 Mediator openlimediator[109943]: OpenLI mediator: SSL Handshake complete for connection to provisioner
May 14 10:26:52 Mediator openlimediator[109943]: OpenLI Mediator: Connected to provisioner at LEA_ip_enpXs0:9001
May 14 10:26:52 Mediator openlimediator[109943]: OpenLI Mediator: Disconnecting from provisioner.

What could be the error in the interception of the traffic? Could it be a port error? VM connectivity?

[salcock]

Your mediator is never successfully authenticating with the provisioner, because of the problem that you are having in #107 .

Without a stable connection, the mediator will never be able to know where to send intercepted traffic to.

Fix that problem, and then your mediator should be able to receive traffic from the collectors and forward it to your agencies.

[laaurii00]

Hello OpenLI team,

First of all, thank you very much for resolving the port-related issue. I hadn’t noticed that configuration error, and thanks to your help, I now have connectivity between the different components of OpenLI.

I would now like to better understand the execution order in the interception process, specifically for the VoIP and Static IP cases. I’ve been running some tests and observed behavior that raises a few questions:

VoIP Interception Configuration:

If I configure the VoIP intercepts while the HI2 and HI3 ports are already listening, I do receive a response from HI2, such as:

ETSILI:   Payload:
ETSILI:     hI1-Operation:
ETSILI:       liActivated: ...

This means the LEA correctly receives the HI1 notification sent by the provisioner through the HI2 port. However, if I start all three OpenLI services with the VoIP intercept already configured, and the HI2 and HI3 ports are listening on the LEA, I do not receive any data when I run (from the collector.): sudo tracereplay /pcap/tcpsip_voip.pcap ring:enpXs0

Static IP Interception Configuration:

In this case, I also receive a response from HI2:

ETSILI:   Payload:
ETSILI:     hI1-Operation:
ETSILI:       liActivated: ...

and subsequently:

ETSILI:   Payload:
ETSILI:     iRIPayloadSequence:
ETSILI:       IRIPayload: ...

Additionally, on the HI3 port I receive the following (extract from captured message):

Fri May 16 11:30:32 2025
Capture: Packet Length: 364/364 Direction Value: -1
ETSILI: pS-PDU:
ETSILI:   PSHeader:
  ...
  interceptionPointID: col001
  ...
ETSILI:   Payload:
ETSILI:     cCPayloadSequence:
ETSILI:       CCPayload:
         ...
         iPPackets: ...
IP: Header Len 20 Ver 4 DSCP 00 ECN 0 Total Length 244
IP: Id 4885 Fragoff 0 DONT_FRAG

Configuration Details:

VoIP Intercept:

[{
  "liid": "TESTVOIP001",
  "authcc": "SP",
  "delivcc": "SP",
  "agencyid": "LEA_VM",
  "mediator": 1,
  "outputhandovers": 0,
  "payloadencryption": "none",
  "siptargets": [{
    "username": "steve",
    "realm": "myrealm.com"
  }]
}]

SIP Server:

[{
  "ipaddress": "10.100.50.65",
  "port": "5060"
}]

Static IP Intercept:

[{
  "liid": "STATIC001",
  "authcc": "SP",
  "delivcc": "SP",
  "agencyid": "LEA_VM",
  "mediator": 1,
  "outputhandovers": 0,
  "payloadencryption": "none",
  "user": "roger",
  "accesstype": "fiber",
  "radiusident": "any",
  "staticips": [{
    "iprange": "10.1.18.217/32",
    "sessionid": 101
  }]
}]

(All of this has been done based on the training laboratory.)

---

Is there an error in the VoIP interception configuration? I can't see any different from the laboratory's guidelines
Could you help me understand whether this behavior is expected?
Is there a specific order or condition that must be met for the intercept activation to work correctly?

Thank you in advance for your attention and support.

[salcock]

The LIActivated and LIModified messages are only sent in response to a change in the intercept configuration that has been pushed to a running provisioner, such as via the REST API or a configuration reload. Configuration changes that happen while the provisioner is not running will not produce these messages.

So if the intercept is already configured, and you then start the OpenLI components, no LIActivated message will be sent. However, your intercept should still be active and you should still receive HI2 and HI3 records for any voice calls that commence after the collector has begun sniffing traffic.

Note that, in the case of a voice call, the username and realm that you specify in the siptargets portion of your intercept configuration must match a username and realm that appear in the SIP INVITE. The steve@myrealm.com target that is included in your configuration will only intercept successfully IF your collector actually captures a call where steve@myrealm.com is a party to the call and that identity appears either in the To: portion of the SIP INVITE or in one of the trusted identity headers found in the INVITE (e.g. P-Asserted-Identity).

By default, OpenLI does NOT trust the From: header in SIP INVITEs as this can easily be spoofed.

[laaurii00]

I'm working with the tcpsip_void.pcap file provided in the training lab, attempting to simulate a VoIP interception. Based on previous comments, I analyzed the SIP INVITE messages in the .pcap to identify the To: field and determine the appropriate target for interception.

I found that the To: field contains the address 0800000000@tls.example.com, so I added this target to the configuration using the REST API. The resulting configuration is as follows:
Configured VoIP interception:

[
  {
    "liid": "TESTVOIP001",
    "authcc": "SP",
    "delivcc": "SP",
    "agencyid": "LEA_VM",
    "mediator": 1,
    "outputhandovers": 0,
    "payloadencryption": "none",
    "siptargets": [
      { "username": "12345678910" },
      { "username": "0800000000", "realm": "tls.example.com" },
      { "username": "12345678910", "realm": "tls.example.com" }
    ]
  }
]

However, I’m still not receiving any intercepted traffic. Since I’m working with the .pcap file from the lab, could you please advise if there’s anything I might be missing in the voipintercept configuration to make this work correctly?

Thank you in advance for your help.

[salcock]

The VoIP intercept configuration looks OK to me at first glance.

Have you also made sure that 10.100.50.65 is defined in the sipservers portion of your intercept configuration? It is very important that you do this, otherwise OpenLI does not know which captured traffic it should be interpreting as SIP.

See slides 7-13 of Chapter 11 of the OpenLI tutorial for more detail on this.

[laaurii00]

Yes, it is added:
Configured with the API request:
curl -X POST -H "Content-Type: application/json" -d '{"ipaddress": "10.100.50.65", "port": "5060"}' http://provisioner:8080/sipserver
Collector confirms that it has been received and adds it:
openlicollector[1089440]: OpenLI: collector has added 10.100.50.65-5060-5060-SIP to its SIP core server list.

LEA's responce to GET sipserver and GET VoIP configurations:

Configured Sip Servers:
[ { "ipaddress": "10.100.50.65", "port": "5060" } ]

Configured VoIP interception:
[ { "liid": "TESTVOIP001", "authcc": "SP", "delivcc": "SP", "agencyid": "LEA_VM", "mediator": 1, "outputhandovers": 0, "payloadencryption": "none", "siptargets": [ { "username": "12345678910" }, { "username": "0800000000", "realm": "tls.example.com" }, { "username": "12345678910", "realm": "tls.example.com" } ] } ]

Sorry for insist, but I can't find the error in the configuration.
Thank you in advance for your help.

[salcock]

That configuration seems fine.

The next thing to confirm would be that your collector is capturing the traffic and generating IRI and CC records accordingly.

Try adding logstatfrequency: 5 to your collector configuration -- this will tell the collector to write some useful statistics to the logs every 5 minutes.

Take alook at the statistics that are written shortly after you replay your pcap into the collector.

You should see logs about the number of packets captured and dropped, as well as the number of CCs and IRIs that the collector produced.

If the captured packets are zero in the first set of logged stats after your pcap replay, then there is a problem with your replay or capture setup.

If the captured packet count is not zero, but the number of IRIs and CCs are zero, then the collector is not recognising the traffic as interceptable.

If the number of IRIs and CCs is also not zero, then the collector is working fine and the problem is further down the pipeline (i.e. in the mediator).

[laaurii00]

The collector logged metrics are:

OpenLI: Collector statistics for the last 5 minutes:
OpenLI: Packets... captured: 4672    dropped: 0   intercepted: 3950
OpenLI: Packets sent to IP sync: 0
OpenLI: Packets sent to SIP workers: 37
OpenLI: Packets sent to Email workers: 0
OpenLI: Packets sent to GTP workers: 0
OpenLI: Bad SIP packets: 0   Bad RADIUS packets: 0
OpenLI: Records created... IPCCs: 0  IPIRIs: 1  MobIRIs: 0
OpenLI: Records created... IPMMCCs: 3950  IPMMIRIs: 18
OpenLI: Records created... EmailCCs: 0  EmailIRIs: 0
OpenLI: IP intercepts added: 3  (all-time: 3)
OpenLI: IP intercepts ended: 0  (all-time: 0)
OpenLI: VOIP intercepts added: 0  (all-time: 0)
OpenLI: VOIP intercepts ended: 0  (all-time: 0)
OpenLI: Email intercepts added: 0  (all-time: 0)
OpenLI: Email intercepts ended: 0  (all-time: 0)
OpenLI: IP sessions added: 1  (all-time: 1)
OpenLI: IP sessions ended: 0  (all-time: 0)
OpenLI: VOIP sessions added: 1  (all-time: 1)
OpenLI: VOIP sessions ended: 0  (all-time: 0)
OpenLI: Email sessions added: 0  (all-time: 0)
OpenLI: Email sessions ended: 0  (all-time: 0)
OpenLI: === statistics complete ===

And I am already receiving intercept information at both IRI and CC.
IRI:

Tue Jun 10 16:25:43 2025
 Capture: Packet Length: 730/730 Direction Value: -1
 ETSILI: pS-PDU:
 ETSILI:   PSHeader:
 ETSILI:     li-psDomainId: 0.4.0.2.2.5.1.17
 ETSILI:     lawfulInterceptionIdentifier: TESTVOIP001
 ETSILI:     authorizationCountryCode: SP
 ETSILI:     communicationIdentifier:
 ETSILI:       networkIdentifier:
 ETSILI:         operatorIdentifier: WAND
 ETSILI:         networkElementIdentifier: openli
 ETSILI:       communicationIdentityNumber: 1796335989
....

CC:

Tue Jun 10 16:25:42 2025
 Capture: Packet Length: 326/326 Direction Value: -1
 ETSILI: pS-PDU:
 ETSILI:   PSHeader:
 ETSILI:     li-psDomainId: 0.4.0.2.2.5.1.17
 ETSILI:     lawfulInterceptionIdentifier: TESTVOIP001
 ETSILI:     authorizationCountryCode: SP
 ETSILI:     communicationIdentifier:
 ETSILI:       networkIdentifier:
 ETSILI:         operatorIdentifier: WAND
 ETSILI:         networkElementIdentifier: openli
 ETSILI:       communicationIdentityNumber: 138071930
....

However this information is captured in the first tcpsip_voip.pcap emitted after restarting the service, if I launch it a second time it no longer responds. Is this an expected behavior of OpenLI? Why?

[salcock]

Yes, in the case of this example, it is expected behavior.

The reason is because you are replaying the exact same sequence of TCP packets each time to replay the pcap file. For TCP SIP, OpenLI uses the TCP sequencing to reassemble the SIP payloads into messages -- this allows us to account for lost or reordered segments, as well as handle SIP messages that span multiple TCP packets.

When you replay the pcap a second time, the sequence numbers in the captured packets are repeats of ones that OpenLI has already parsed and intercepted. Therefore, OpenLI ignores them because it assumes they are retransmits.

If the replayed traffic began with a TCP SYN handshake, then OpenLI would reset its sequence number tracking for that TCP stream. But that particular pcap that you are using does not include the handshake, so that is why the traffic is only intercepted once.

In short: you are replaying the same call multiple times, but OpenLI is "smart" enough to only intercept it once.

[laaurii00]

Here’s the full message in English, formatted for GitHub Issues and including your request examples:

---

Title:

Error invalid field in received IP/VOIP intercept: 55 when configuring a new LEA's interception.

---

Description:

Hello OpenLI team,

I am configuring a new LEA (LEA_VM_2) based on a previous configuration, only changing the LEA IP address for VoIP, static IP, and Radius intercepts.

HI1 requests are reaching the WAND collector correctly with MediatorId = 1. Example capture:

ETSILI: pS-PDU:
  lawfulInterceptionIdentifier: TESTVOIP001
  authorizationCountryCode: SP
  deliveryCountryCode: SP
  operatorIdentifier: WAND
  sequenceNumber: 1
  timeStamp: 20251201152339.495Z
  target-Information: 12345678910,jsmith@example.com

However, when sending REST requests to the provisioner (/voipintercept and /ipintercept), the collector logs:

Collector openlicollector[1388171]: OpenLI: invalid field in received IP intercept: 55.
Collector openlicollector[1381278]: OpenLI: invalid field in received VOIP intercept: 55.
Collector openlicollector: SIP worker failed to decode VoIP intercept start message from provisioner
Collector openlicollector: halting SIP processing thread 0

---

Example requests sent:

Configure SIP server:

curl --cacert XXX -X POST -H "Content-Type: application/json" \
-d '{"ipaddress": "10.100.50.65", "port": "5060"}' \
https://provisioner:provisioner_port/sipserver

VoIP intercept request:

curl --cacert XXX -X POST -H "Content-Type: application/json" \
-d '{
  "liid": "TESTVOIP001",
  "authcc": "SP",
  "delivcc": "SP",
  "agencyid": "LEA_VM_2",
  "mediator": 1,
  "starttime": 0,
  "endtime": 0,
  "siptargets": [
    { "username": "12345678910" },
    { "username": "jsmith", "realm": "example.com" }
  ]
}' \
https://provisioner:provisioner_port/voipintercept

---

Additional details:

• Method used: POST (also tested with PUT)
• Fields sent: liid, authcc, delivcc, agencyid, mediator (string in this example, also tested as integer), siptargets (list), plus optional fields (starttime, endtime).
• HI1 requests are processed correctly, but the error occurs during intercept decoding in the collector.
• Versions: [please specify provisioner and collector versions]
• Only change from previous working configuration: LEA IP address.

---

Question:

Does TLV code 55 correspond to a new field not supported by the collector? Could this be caused by a version mismatch or by optional fields in the JSON?

Thank you for your help!

[salcock]

Usually, this sort of error can occur when the OpenLI components are running different versions to one another.

Make sure your collector and provisioner are running the same OpenLI version -- if they are not, let me know and we can try to dig deeper.

[laaurii00]

Thanks, the issue was indeed caused by version mismatches.
I have an informational question:

Is there a way to configure the source IP address that the Mediator uses to communicate with the LEA?
Or is OpenLI Mediator designed to emit HI2 and HI3 (IRI and CC) directly to the LEA using the configured listening ports, but without an option to define the source IP?

Thanks and best regards.

[salcock]

There's currently no way to configure the source address for the mediator handovers to the LEA. In a typical deployment, there would only be one route from the mediator to the LEA (usually over an IPSec tunnel or VPN), so there aren't many practical situations where it is necessary to choose a source address.