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

从仅含 GTP 的 5G 抓包中读取 IMS 语音通话

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. 一份 srsRAN 的错误报告描述了在 5G 基站 F1-U 接口上获取的抓包，该抓包解码后仅显示 GTP。SIP 信令和 RTP 语音似乎完全不存在——Wireshark 只显示了 GTP 隧道并就此停止。但实际上它们就在那里。

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. F1-U 在 GTP-U 隧道内承载 PDCP PDU。在此实验室版本中，PDCP 运行 NEA0 空加密且没有 SDAP 头部，因此内部 IP 数据包在每个 T-PDU 中都从固定的 3 字节偏移处开始。删除这三个字节，将结果重新封装为 LINKTYPE_RAW，下方就会出现 2,960 个内部 IPv4 数据包：这是一次双向 VoNR 通话。

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. 重构后的抓包显示了什么？加密边界可以通过手动读取一个字节来确定。T-PDU 的第 0 字节是 0x80——这是一个带有 18 位序列号的 PDCP-NR 数据 PDU，因此头部为 3 字节。第 3 字节是 0x45：这是一个立即开始的 IPv4 数据包，中间没有 SDAP 头部。那个 0x45 就是载荷为明文的标志。

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. 内部追踪分析是与你最初面对的问题不同的另一回事。这里有 1,670 个 RTP 帧、273 个 TLS、208 个 IPsec ESP、59 个 DNS、14 个 RTCP，以及 6 条 SIP 消息。新的端点、新的会话、新的故障模式。

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. 这 6 条 SIP 消息是所有可读的信令。包括一个带有空 Authorization 摘要的 REGISTER，一个 100 Trying，以及一个状态行显示为“Challenging the UE”的 401 响应。其 WWW-Authenticate 头部携带了 algorithm=AKAv1-MD5（nonce 包含了 UE 提供给 USIM 的 RAND 和 AUTN），而其 Security-Server 头部则移交了用于建立 IPsec 的参数：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. 401 响应告诉你该期待哪条隧道。大约 0.4 秒后，第一个 ESP 数据包出现在 SPI 0x0000100f 上——即十进制的 4111，这正是 P-CSCF 所通告的 spi-s。这种匹配将 IMS-AKA 质询与其响应的安全关联（Security Association）联系了起来。

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. 1,670 个 RTP 帧在流动，但抓包中任何地方都没有出现 INVITE。它在 ESP 内部。根据 TS 33.203 标准，注册后的每条 SIP 消息都承载在 IPsec 内部；而媒体面则不然。因此，RTP 保持可读，而协商它的信令则保持不透明。

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. 可见媒体流但没有可见的 INVITE，这是 IMS 按规范工作的表现，而不是通话中断——如果你在调试 VoNR 时发现 INVITE 似乎丢失了，请先检查这一点。

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. 有一个要求值得明确说明：NEA0。这种“剥离并重放”的方法之所以有效，是因为载荷未加密，这是测试环境的选择。在运行 NEA1 或 NEA2 的商业网络上，你需要 UE 的密钥，否则这些内容都无法恢复。

The full walkthrough carries the reconstruction script, a five-phase read of the call, and a silent DNS resolver found along the way. 完整的演练指南包含了重构脚本、通话的五个阶段解读，以及在此过程中发现的一个静默 DNS 解析器。

Full walkthrough: https://www.eventhelix.com/5G/reconstructing-vonr-from-f1u/ 完整演练：https://www.eventhelix.com/5G/reconstructing-vonr-from-f1u/