SIP Call Flow Analyzer
Analyze SIP call flows with sequence diagrams, timing metrics, response summaries, and RTP stream hints from SDP.
AK
appkiro.comPaste multiple SIP messages (request and response) in the order they were captured. Optional # t=0.123 lines before each message feed the timing analysis.
Advanced Options
Call Setup Time (INVITE → 200 OK)
152 ms
Post Dial Delay (180 → 200 OK)
45 ms
Call Duration (200 OK → BYE)
1.153 s
Total Call Duration
2.015 s
| Metric | Value |
|---|---|
| INVITE → First Response | 2 ms |
| INVITE → 200 OK | 152 ms |
| 200 OK → ACK | 950 ms |
| Call Duration (Media) | 203 ms |
| Total Duration | 2.015 s |
SIP Call Flow Analyzer reads plain-text SIP traffic — exported from Wireshark, sngrep, FreeSWITCH logs, Kamailio captures, or copied directly from a packet trace — and turns the messages into a sequence diagram, a timing breakdown, a category summary, and an RTP stream table. The page runs entirely in your browser. Nothing leaves the tab.
Engineers reach for a tool like this when a call is failing intermittently, when a customer reports late audio, when post-dial delay creeps up after a server change, or when an interop test needs to confirm that a request travelled through every expected hop. Pasting the capture and pressing Analyze takes a noisy text dump and turns it into the same diagram you would draw on a whiteboard.
Request lines (INVITE sip:bob...), status lines (SIP/2.0 200 OK), every header including multi-value Via and Contact, plus the SDP body when one is attached. Folded headers (continuation lines) are joined back together.
The lifelines represent caller, proxy, and callee. Requests flow left-to-right through the proxy; responses retrace the path. ACK and BYE travel end-to-end. Provisional responses use a dashed line so they read differently from final responses.
When the input contains # t=0.123 markers before each message the timings are absolute. Without markers the analyzer falls back to message order so the relative gaps still make sense, but the millisecond totals are not authoritative.
The analyzer scans SDP bodies for m=audio descriptors, picks up the connection address, codec from a=rtpmap, and SSRC where present, then estimates packet count from the call duration assuming 50 packets per second for G.711.
No request leaves your machine. The capture you paste, the parsed messages, the generated SVG, and the rasterised PNG are all assembled in JavaScript on the page. Closing the tab discards every byte.
The Download buttons produce a vector SVG of the diagram for documents and an upscaled PNG for tickets and chat threads. Use the Copy button on the input to archive the raw capture alongside an investigation log.
#) are tolerated.Plain-text SIP messages copied from a packet capture, a server log, or a network monitor. Each message must include a request line or status line at the top, followed by headers and an optional body separated by a blank line. Multiple messages are separated by blank lines as well.
No. Parsing, sequence rendering, timing math, and exports run inside this page. Closing the tab is enough to discard the input — there is no copy on a server.
If your input contains lines like `# t=0.152` before each message, those values feed the timing analysis directly. When the markers are missing the analyzer falls back to the message order so the relative gaps still make sense, but absolute milliseconds will not be accurate.
From and To URIs determine the caller and callee. Requests start at the caller and pass through the proxy to the callee; responses retrace that path. ACK and BYE travel end-to-end. The diagram is a logical view, not the exact hop chain captured on the wire.
When SDP bodies advertise an `m=audio` line, the analyzer pulls the host, port, codec, and (when present) SSRC values, then estimates packet count from the call duration. Streams without an `a=ssrc` attribute are still listed using a derived identifier.
Yes. The Download buttons produce an SVG of the rendered sequence diagram and a PNG rasterised at twice the on-screen resolution for documents and tickets.
It performs structural validation — request line, status line, header parsing, CSeq, Call-ID, From/To, Via — and surfaces categories per response code. Deeper compliance checks (Route handling, RFC 3261 dialog rules, transaction state) are out of scope.