please generate explore.fxt.xml and sessions.fxt.xml from @"VoIP Calls FINAL.pcapng"
Ran analyze_capture against the PCAP. Detected 3 protocols: SIP, RTP, PPP (PPP is the link layer — PPPoE-encapsulated frames). Recommended template: sip-rtp/explore.fxt.xml (full coverage of the signaling + media protocols that matter).
Action: Copied sip-rtp/explore.fxt.xml and sip-rtp/sessions.fxt.xml from the bundled samples into the PCAP directory.
Validated explore.fxt.xml against the PCAP:
| File | Templates | Session types | Coverage |
|---|---|---|---|
explore.fxt.xml | 32 | 0 | 6486 / 6486 frames matched (100%) |
sessions.fxt.xml | — | sip-dialog | (validated indirectly via extract_sessions) |
All conflicts reported by the validator were "expected first-match-wins" — no errors. SIP Method-keyed templates (INVITE / BYE / ACK) correctly outrank the generic Request-Line fallback; the 1xx/2xx status templates correctly outrank the generic Status-Line fallback.
yes, render both
Ran explore and extract_sessions in parallel.
27 SIP signaling messages on the diagram; 12,922 RTP/RTCP packets deduplicated by the filter="true" rule (expected — VoIP captures are dominated by media). Viewer opened at output/explore/VoIP Calls FINAL/VoIP Calls FINAL_viewer.html.
The validator's "0% match" warning is misleading for VoIP captures — the filter rule is working as intended, suppressing 12,922 RTP/RTCP packets so the SIP signaling stays readable.
3 SIP dialogs, all success::call-completed.
| Session type | Outcome | Count |
|---|---|---|
| sip-dialog | success::call-completed | 3 |
Navigator opened at output/sessions/VoIP Calls FINAL/index.html.
Do you see any differences between the three calls?
Walked the 3 session NDJSON files. All three share an identical signaling skeleton:
INVITE → 100 Trying → 180 Ringing → ACK → BYEbetween the same two SBC IPs (217.0.21.65 ↔ 84.146.135.221), all calling the same callee +4960339285361@telekom.de. But the calls differ meaningfully in caller, codec, and origin domain:
| Call 1 | Call 2 | Call 3 | |
|---|---|---|---|
| When | 2019-11-15 14:59 | 2019-11-18 16:08 | 2019-11-18 21:35 |
| Caller | +46739883425 (SE) | +491741880211 (DE) | +31859027384 (NL) |
| Caller domain | dtag-gn.de (gateway) | ims.telekom.de (IMS) | dtag-gn.de (gateway) |
| User-Agent | — | iOS/13.2.2 iPhone | — |
| Codecs offered | PCMA, PCMU, G729, G723, telephone-event | EVS, AMR-WB, AMR-NB, … | PCMA, PCMU, G729, G723 |
| SDP session name | SBC call | - | SBC call |
| RTP port | 5690 | 35192 | 15020 |
| ICSI feature tags | mmtel | mmtel + mid-call + srvcc-alerting + ps2cs-srvcc | mmtel |
| Talk time (INVITE → BYE) | ~51 s | ~25 s | ~56 s |
| BYE reason | Q.850 cause=16 Normal call clearing | SIP cause=200 "User Triggered" | Q.850 cause=16 Normal call clearing |
ims.telekom.de) on an actual handset (User-Agent iOS/13.2.2 iPhone), negotiates HD codecs (EVS, AMR-WB), advertises SRVCC + mid-call handover capability, and tears down with a SIP "User Triggered" reason — the subscriber hung up.dtag-gn.de), advertise narrowband codecs only (PCMA/PCMU/G729/G723), have no User-Agent, and clear with the standard Q.850 cause=16.dtag-gn.de flags PSTN gateway origin, ims.telekom.de flags native VoLTE origin.voip/
├── VoIP Calls FINAL.pcapng # input
├── explore.fxt.xml # exploration template (32 templates, sip-rtp sample)
├── sessions.fxt.xml # session-tracking template (sip-dialog)
├── session.md # this report (Markdown)
├── session.html # this report (styled HTML)
└── output/
├── explore/
│ └── VoIP Calls FINAL/
│ └── VoIP Calls FINAL_viewer.html
└── sessions/
└── VoIP Calls FINAL/
├── index.html
└── sip-dialog/success/{00001,00002,00003}.{html,pdf,ndjson}+4960339285361@telekom.de via the same SBC pair (217.0.21.65 ↔ 84.146.135.221).