What distinguishes a native VoLTE SIP leg from a PSTN-gateway interconnect leg in a Deutsche Telekom SBC capture?

The strongest discriminator is the From-URI domain: ims.telekom.de marks a native VoLTE / IMS originator (real handset User-Agent, HD codecs EVS and AMR-WB offered, ICSI feature tags including mmtel, mid-call, srvcc-alerting and ps2cs-srvcc, BYE with SIP cause 200 'User Triggered'), while dtag-gn.de marks a PSTN-gateway interconnect leg (no User-Agent, narrowband-only codec offers — PCMA, PCMU, G.729, G.723 — and BYE with Q.850 cause=16 'Normal call clearing').

Why is the SIP/SDP codec offer different on a VoLTE call vs a PSTN-interconnect call?

A native VoLTE IMS originator can negotiate HD voice codecs end-to-end, so its SDP offer leads with EVS and AMR-WB before falling back to AMR-NB and narrowband options. A PSTN-interconnect leg has to be transcodable to TDM/PSTN endpoints, so the SBC restricts the offer to narrowband codecs only — PCMA, PCMU, G.729 and G.723. The capture confirms this: Call 2 (ims.telekom.de origin) offers EVS/AMR-WB, while Calls 1 and 3 (dtag-gn.de gateway origin) offer narrowband only.

What do ICSI feature tags like mmtel, mid-call, srvcc-alerting and ps2cs-srvcc indicate in a SIP INVITE?

ICSI (IMS Communication Service Identifier) feature tags in the Contact / Accept-Contact headers advertise what the originating UE and network support. mmtel indicates the IMS Multimedia Telephony service. mid-call signals support for mid-call service-continuity events. srvcc-alerting and ps2cs-srvcc indicate that the UE supports Single Radio Voice Call Continuity from the IMS/PS domain to the CS domain — i.e. the call can be handed over from LTE/VoLTE to 3G/2G CS if radio conditions degrade. These tags appear only on the VoLTE leg in this capture, not on the PSTN-gateway legs.

Why does VisualEther suppress RTP/RTCP packets when rendering a SIP/RTP capture's sequence diagram?

VoIP captures are dominated by media — in this capture 12,922 of 6,486+12,922 packets are RTP/RTCP and only 27 are SIP signalling messages. The sip-rtp FXT template applies a filter='true' rule that deduplicates the RTP/RTCP stream so the SIP signalling stays readable on the sequence diagram. The validator may warn '0% match' for that rule, which is misleading — the rule is working as intended, hiding the media flood so INVITE / 100 / 180 / 200 / ACK / BYE ladders are legible.

How does VisualEther group SIP messages into call-level sessions for pcap analysis?

VisualEther's extract_sessions tool, driven by the sip-rtp sessions.fxt.xml template, keys on the SIP dialog identifier (Call-ID + from-tag + to-tag) and groups every INVITE / 1xx / 2xx / ACK / BYE / response for the same dialog into one session. Each session is classified by outcome — success::call-completed, failure::4xx-client-error, failure::5xx-server-error, etc. In this capture three independent sip-dialog sessions are produced, all classified success::call-completed, each linked to its own per-session HTML / PDF / NDJSON artifact in the session navigator.

VoIP SIP/RTP Call Flow pcap Analysis: VoLTE vs PSTN Gateway via Telekom SBC

01UserGenerate FXT templates

please generate explore.fxt.xml and sessions.fxt.xml from @"VoIP Calls FINAL.pcapng"

02ClaudeFXT template generation

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 signalling + 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.

03UserRender both diagrams

yes, render both

04ClaudeExplore & session diagrams

Ran explore and extract_sessions in parallel.

Explore

27 SIP signalling 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.

Note. 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 signalling stays readable.

Sessions

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.

05UserCompare the three calls

Do you see any differences between the three calls?

06ClaudeThree-call comparison

Walked the 3 session NDJSON files. All three share an identical signalling skeleton:

INVITE → 100 Trying → 180 Ringing → ACK → BYE

between 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

Key flow differences

Call 2 is a native VoLTE leg. Originated from the IMS domain (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.
Calls 1 and 3 are interconnect/PSTN-side traffic. Both originate in the gateway domain (dtag-gn.de), advertise narrowband codecs only (PCMA/PCMU/G729/G723), have no User-Agent, and clear with the standard Q.850 cause=16.
All three terminate at the same German number through the same SBC pair — this capture appears to be three distinct inbound legs to a single B-party.
From-URI domain is the strongest discriminator — dtag-gn.de flags PSTN gateway origin, ims.telekom.de flags native VoLTE origin.

07CodaArtifacts & findings

Files produced

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}

Findings summary

3 dialogs Three independent successful SIP calls, all to +4960339285361@telekom.de via the same SBC pair (217.0.21.65 ↔ 84.146.135.221).
origins One VoLTE leg, two PSTN-gateway legs. Call 2 is the only native IMS originator (iPhone, EVS/AMR-WB, SRVCC tags); calls 1 and 3 are gateway-domain origins with narrowband codecs.
clean All three completed normally. No 4xx/5xx/6xx responses, no CANCELs, no retransmission storms — clean signalling on each leg.
media RTP volume dominates the capture (~99.6%): 12,922 media packets deduplicated by the FXT filter rule vs. 27 signalling messages — expected for a VoIP trace.
scope No re-INVITE / UPDATE / hold / transfer activity — these are simple two-party call legs from setup to teardown.

Method. Capture rendered with VisualEther via its MCP integration with Claude — analyze_capture → explore for the master sequence diagram, then extract_sessions for per-dialog SIP outcome buckets, using the bundled sip-rtp FXT samples (32 explore templates + one sip-dialog session type).