ETSI's lawful interception handover interface specifications cover the full chain from warrant delivery to content handover. HI1 defines how law enforcement submits warrant and tasking information to the carrier. HI2 defines the intercept-related information record — the metadata associated with a target's communications. HI3 defines the content channel. The specifications are internationally adopted, regularly updated, and formally maintained. In practice, connecting two compliant implementations to each other still requires custom integration work in the majority of cases.
The ETSI handover interface stack
The handover interface architecture separates the administrative and delivery functions. The Administration Function (ADMF) handles warrant management and tasking — the HI1 channel. The Delivery Function (DF) handles the outbound interfaces: DF2 for IRI over HI2, DF3 for content over HI3. Internally, the network communicates with the intercept infrastructure over X interfaces: X1 for provisioning intercept access points, X2 for IRI delivery from the network element to the DF, and X3 for content delivery.
ETSI TS 103 120 defines the HI1 warrant interface specifically, including the data structures for electronic submission of lawful authorisations. TS 103 221 parts 1 and 3 define the internal X1 and X3 interfaces. The Common Parameters dictionary in TS 103 280 provides shared data elements referenced across specifications. Together these documents describe a system that should allow interoperability across vendors and jurisdictions.
What 'ETSI-compliant' means in practice
Compliance with ETSI LI specifications is self-declared. There is no certification body that tests and accredits handover interface implementations against the full specification set. Vendors and operators declare compliance with the relevant specifications, but the specifications themselves contain options, profiles, and locally defined extensions that leave significant implementation latitude.
ASN.1 encoding, which underlies the ETSI LI data structures, offers multiple valid encodings of the same data. Transport choices — IP over TCP versus X.25 legacy links, for instance — affect how the interface is physically connected. Timing and sequence numbering implementations vary. When two independently developed systems that are both 'ETSI-compliant' attempt to connect, the implementation choices made on each side often differ in ways that require explicit translation.
Where fragmentation occurs at the handover interface
The fragmentation points are predictable and well-documented by practitioners, even if they are not acknowledged in the specifications. HI2 IRI record formats vary in how they encode certain optional fields — particularly for supplementary services and call-forwarding scenarios — because the specification permits multiple valid representations. HI3 content framing choices affect how receiving systems reconstruct RTP or signalling streams. Correlation identifiers, which link HI2 and HI3 records for the same intercept, are implemented differently enough across vendors that passive correlation at the law enforcement monitoring facility often fails without prior negotiation.
Certificate management and mutual authentication on the handover interface — increasingly required as ETSI incorporates security requirements into LI specifications — introduces another integration point. ADMF-to-LEA connections that need to support encrypted delivery with mutual TLS require PKI coordination that is operationally separate from the technical interface specification itself.
The mediation problem for multi-jurisdiction delivery
An operator delivering intercept to law enforcement agencies across multiple jurisdictions faces a combinatorial problem. Each agency connection may have different encoding preferences, different transport requirements, and different local extensions to the ETSI base specification. Building and maintaining a separate integration for each agency-operator pair is not scalable.
Mediation layers address this by normalising the output of the operator's Delivery Function into a common internal representation, and then translating outbound to the specific format and transport required by each law enforcement destination. This separates the network-facing integration from the agency-facing integration, and allows each to evolve independently. It also provides a single point where audit logging, sequencing verification, and delivery confirmation can be implemented across all agency connections.
What a normalised delivery architecture requires
Building a mediation architecture that actually resolves the handover interface fragmentation problem — rather than just moving it — requires specific capabilities that generic integration middleware does not provide.
- Native ETSI ASN.1 parsing and generation across multiple profile variants, with the ability to translate between encoding options without data loss.
- Correlation identifier normalisation to ensure HI2 and HI3 records for the same intercept are reliably linked at the receiving agency regardless of how the originating DF generates them.
- Transport adaptation across IP, legacy X.25, and encrypted TLS delivery channels, managed through a single configuration interface.
- Agency-specific profile management that captures the encoding and transport preferences of each delivery destination and applies them automatically.
- Delivery confirmation handling that provides the operator with evidence of successful handover to the law enforcement monitoring facility — a requirement in several jurisdictions.
- Audit logging at the mediation layer, independent of the operator's network element logs, to provide an end-to-end delivery record for compliance audit purposes.
