Reading an IMS voice call out of a GTP-only 5G capture

An srsRAN bug report describes a capture taken on a 5G base station's F1-U interface that decodes as nothing but GTP. The SIP signaling and the RTP voice are simply not there - Wireshark shows GTP tunnels and stops. They are there. F1-U carries PDCP PDUs inside GTP-U tunnels, and in this lab build, PDCP runs the NEA0 null cipher with no SDAP header, so the inner IP packet starts at a fixed 3-byte offset in every T-PDU. Delete those three bytes, re-frame the result as LINKTYPE_RAW, and 2,960 inner IPv4 packets appear underneath: a two-party VoNR call. What the reconstructed capture shows The encryption boundary is one byte you can read by hand. Byte 0 of the T-PDU is 0x80 - a PDCP-NR data PDU with an 18-bit sequence number, so a 3-byte header. Byte 3 is 0x45: an IPv4 packet beginning immediately, no SDAP header in between. That 0x45 is the tell that the payload is in the clear. The inner trace is a different problem from the one you started with. 1,670 RTP frames, 273 TLS, 208 IPsec ESP, 59 DNS, 14 RTCP - and six SIP messages. New endpoints, new sessions, new failure modes. Those six SIP messages are the whole readable signaling. A REGISTER with an empty Authorization digest, a 100 Trying, then a 401 whose status line reads "Challenging the UE". Its WWW-Authenticate header carries algorithm=AKAv1-MD5 - the nonce packs the RAND and AUTN the UE feeds its USIM - and its Security-Server header hands over the IPsec parameters to establish: spi-s=4111, alg=hmac-md5-96, ealg=aes-cbc. The 401 tells you which tunnel to expect. About 0.4 s later, the first ESP packet appears on SPI 0x0000100f - decimal 4111, exactly the spi-s the P-CSCF advertised. That match ties an IMS-AKA challenge to the security association answering it. 1,670 RTP frames flow, and no INVITE appears anywhere in the capture. It is inside the ESP. Under TS 33.203, every SIP message after registration rides inside IPsec; the media plane does not. So RTP stays readable, and the signaling that negotiated it stays opaque. Visible media with no visible INVITE is IMS working as specified, not a broken call - if you are debugging VoNR and the INVITE seems missing, check this first. One requirement is worth stating plainly: NEA0. Strip-and-replay works because the payload is unciphered, which is a test-rig choice. On a commercial network running NEA1 or NEA2, you would need the UE's keys, and none of this is recoverable. The full walkthrough carries the reconstruction script, a five-phase read of the call, and a silent DNS resolver found along the way. Full walkthrough: https://www.eventhelix.com/5G/reconstructing-vonr-from-f1u/ Top comments (0)