SIP Flow
MCP server · mcp.sipflow.dev

SIP & VoIP knowledge in your editor.

The Sipflow MCP server exposes a curated VoIP knowledge base (vendor docs across 40+ stacks, SIP/SDP/WebRTC RFCs, and STIR/SHAKEN material) plus 20+ tools for reviewing configs in PR, debugging pcaps, parsing SDP, looking up RFCs and response codes, validating phone numbers, and walking RFC 3263 DNS. Hook Cursor, VS Code, Claude, or Codex CLI up to it in seconds and ask SIP questions where you already work.

View install snippetsSee what it ships

When to reach for it.

Four workflows where having vendor-specific SIP knowledge inside your editor changes the loop.

Review a vendor config in PR

Drop kamailio.cfg, opensips.cfg, pjsip.conf, FreeSWITCH XML, or a drachtio handler into your editor. The agent uses Sipflow to detect the vendor and ground every claim in vendor docs and RFCs - no hallucinated module names, no made-up loadparams.

Debug a live SIP failure with a pcap

Drop a pcap into your editor, ask the agent to detect the stack and look up vendor-specific guidance for the failing transaction (488 codec mismatch, 403 from carrier, missing ACK, NAT issues).

Configure Kamailio, FreeSWITCH, Asterisk, OpenSIPS

Hand the agent your dialplan, kamailio.cfg, or sip.conf and ask why a re-INVITE is being rejected, why the registrar isn't matching, or how to wire up STIR/SHAKEN signing on this stack.

Look up RFC behavior without leaving your editor

RFC 3261/3262/3263/3264, RFC 4566 / 8866 (SDP), RFC 7118 (SIP-over-WebSocket), RFC 8224 / 8225 / 8226 / 8588 (STIR/SHAKEN), RFC 9795 (RCD). Ranked snippets, cited source URLs, no context-switching to a browser.

What it ships.

20+ tools across 10 surfaces, plus a resource template (sipflow://docs/{vendor}/{id}) for re-fetching any chunk returned by search.

Discovery & grounding

  • search_sip_docs

    Hybrid (BM25 + vector) search across the curated VoIP corpus

    Use first for any SIP/VoIP question - config review, RFC lookup, vendor module behavior, response code, header semantics, WebRTC interop, STIR/SHAKEN, ATIS-1000074/094/084, CTIA BCID, RFC 9795 RCD. Hybrid retrieval (semantic + literal) over vendor docs across 40+ stacks plus 60+ RFCs. STIR-shaped queries on sourceType:"rfc" automatically broaden to "stir-shaken". Returns ranked snippets with source URLs.

    • query (required): natural-language question or keywords.
    • vendor (optional): asterisk, freeswitch, kamailio, opensips, twilio, cisco-cube, didww, voxbone, bandwidth, …
    • sourceType (optional): rfc | pbx | sbc | cpaas | uc-cloud | endpoint | stir-shaken | transport | regulatory | observability.
    • limit (1–15, default 5).

  • lookup_response_code

    Instant SIP response code lookup

    Static, no RAG - sub-millisecond. Returns name, RFC anchor, category, operator-flavored common causes, and known reason-phrase variants (e.g. 484 Address Incomplete vs. carrier-flavored "Number Incomplete") for any 1xx–6xx code.

    • code (required, 100-699).

  • lookup_sip_header

    Instant SIP header lookup

    Look up canonical or compact form (Via/v, Diversion, P-Asserted-Identity, Identity, Session-Expires, …). Returns RFC anchor, where it appears, short description, related headers, cardinality (singleton vs. multi vs. list), and parameter rules (e.g. ;tag forbidden on PAI/PPI per RFC 3325).

    • name (required): case-insensitive header name.

Detection

  • detect_sip_stack

    Vendor from a trace OR a config

    Works on both: User-Agent / Server headers from a SIP trace, OR structural signatures from a config blob (loadmodule, route blocks, [transport-*] sections, <profile name=>). Returns a slug aligned with search_sip_docs's vendor filter.

    • text (required): trace OR config blob.
    • kind (default auto): auto | trace | config.
    • filenameHint (optional): improves config-mode detection.

  • detect_sip_vendor_from_config

    Vendor from a config blob (heuristic-only)

    Scoped sibling of detect_sip_stack - pure CPU vendor detection on configs. Returns slug + confidence + structural signals that fired.

    • text (required): config blob.
    • filenameHint (optional).

Trace tools

  • minimize_sip_trace

    Prune noise headers from a raw trace

    Pure CPU. Compacts a SIP trace (PCAP/sngrep/syslog/pasted dialog) for sending to an LLM. Tolerates ngrep / sngrep / syslog / pasted-dialog annotation lines (e.g. `# [ts] A -> B`, `U ip:port -> ip:port`). Preserves SDP bodies and routing/auth/dialog headers. Safe on production traces - never persisted.

    • text (required).
    • maxBytes (1024–2,000,000, default 200,000).

  • render_sip_ladder

    SIP trace → Mermaid sequenceDiagram

    Pure CPU. Emits a Mermaid block your editor draws inline. Resolves lane labels by ip:port → ip → top-Via host → Contact host. Pair with minimize_sip_trace for noisy inputs.

    • text (required).
    • callId (optional).
    • compact (default false): drop keepalives + retransmissions.
    • groupRetransmits (default false): collapse consecutive retransmits into one labeled arrow.
    • highlightFailures (default false): emit notes over 4xx/5xx/6xx responses.
    • splitOnNewBranch (default false): visually break when the Via branch changes.
    • includeTiming (default false).
    • maxMessages (1–200, default 60).
    • aliases (optional): friendly lane labels keyed by ip:port (or ip alone).

  • sip_ladder_example

    Canonical SIP scenarios

    Hand-curated patterns (basic call, auth challenge, hold/resume, REFER transfer, SHAKEN-attested INVITE, redirect, BYE glare, …) as Mermaid + RFC-anchored notes. Use when teaching what X looks like without a real trace.

    • scenario (required): basic-call | auth-challenge | cancel-before-answer | early-media | hold-resume | refer-blind | proxy-with-record-route | shaken-attested-invite | bye-glare | redirect-302.
    • actorNames, includeExplanation, verbose (optional).

  • lint_sip_request

    RFC compliance lints for a single SIP request

    Catches the failure modes carriers reject silently: duplicate `From:` headers (RFC 3261 §7.3 / §20.20), missing CRLF between header lines (RFC 3261 §7.3), `;tag=` parameter on PAI / PPI (RFC 3325 §9.1), PASSporT `orig.tn` not matching the From caller TN (RFC 8224 §5), non-canonical TN in PASSporT claims (RFC 8225 §5.2.1), and brand display names without an `ppt=rcd` Identity header (CTIA BCID §5). Pure CPU.

    • text (required, ≤64KB): raw SIP request starting with the request line.

  • parse_sip_message

    Structural parse of any SIP message

    Pure CPU. Returns start-line (request or status), per-header fields with line numbers, body, duplicate-header counts, and structural flags (duplicate singleton headers, missing CRLF between headers, Content-Length mismatch, non-ASCII header names). Pair with diff_sip_messages or lint_sip_request.

    • text (required, ≤64KB): raw SIP message.

  • diff_sip_messages

    Structural diff of two SIP messages

    Pure CPU. Per-header diff classified as added / removed / mutated / duplicated / de-duplicated / whitespace-only / parameter-reorder, plus body changes (with SDP comparison delegated to compare_sdp_offer_answer when both bodies are SDP). Severity is weighted per header - handy for diffing pre-/post-proxy traces, B2BUA mutations, or carrier-side rewrites.

    • a (required): first SIP message.
    • b (required): second SIP message.

Config / source-file review

  • review_sip_config

    Ground-truth review of a vendor config

    The right tool when the user attaches kamailio.cfg, sip.conf, pjsip.conf, FreeSWITCH XML, or opensips.cfg. Detects vendor, extracts loaded modules / route blocks / profiles / sections / dialplan, surfaces risk flags (including Kamailio/OpenSIPS lump-vs-subst races where subst() and a header-API call mutate the same header on the same path), and returns suggested follow-up search_sip_docs queries. Pure CPU.

    • text (required): config blob.
    • filenameHint (optional): improves detection.
    • vendorHint (optional): force a specific vendor.

  • webrtc_sip_checklist

    WebRTC ↔ SIP interop checklist

    Returns a ranked checklist (WSS, ICE, DTLS-SRTP fingerprint, rtcp-mux + BUNDLE, media relay, STUN/TURN, secure-context Origin, Opus, session timer, STIR/SHAKEN). When configText is supplied, items are marked 'looks present' or 'check needed' based on signal regexes.

    • vendor (optional).
    • configText (optional).
    • filenameHint (optional).

SDP

  • parse_sdp

    Structured RFC 8866 SDP parse

    Returns origin, session, timing, per-media codecs (rtpmap + fmtp), direction, DTLS setup + fingerprint, ICE credentials + candidates, rtcp-mux, BUNDLE groups, and crypto attributes.

    • sdp (required, ≤64KB).

  • compare_sdp_offer_answer

    Diff an offer/answer pair (RFC 3264)

    Surfaces the issues that actually break calls: codec intersection, direction compat, DTLS setup conflicts, rtcp-mux/BUNDLE asymmetry, missing fingerprints when DTLS-SRTP is negotiated, ICE asymmetry. Pure CPU.

    • offer (required).
    • answer (required).

STIR/SHAKEN

  • validate_stir_shaken_identity

    Cryptographic verification of an Identity JWS

    Fetches x5u, parses cert, verifies ES256 signature, optionally validates RCD icon hash (RFC 9795). Accepts the legacy `rcdi["icn"]` key and surfaces a warning; set strictRfc9795 to fail instead. Useful for diagnosing 438 Invalid Identity Header.

    • headerB64, payloadB64, signatureB64 (required).
    • infoUrl (optional). iconUrl, expectedIconHash (optional).
    • rcdi (optional): pass the parsed PASSporT `rcdi` map and the tool resolves "/icn" or legacy "icn".
    • strictRfc9795 (optional, default false): treat legacy rcdi keys as errors instead of warnings.

  • stir_attestation_explainer

    Explain attestation A/B/C and STIR codes

    Plain-English requirements + scenarios for RFC 8588 attestation levels and the STIR-shaped 4xx codes (428, 436, 437, 438, 608). Pair with validate_stir_shaken_identity for the cryptographic verdict.

    • attestation (A | B | C, optional).
    • code (optional).

Telecom utilities

  • validate_e164_number

    Parse + classify a phone number

    International coverage via libphonenumber-js. NANP numbers (CC=1) split into NPA/NXX/station with toll-free / premium / personal / m2m / easily-recognizable / reserved / geographic classification. Pure CPU.

    • number (required, any common form; E.164 preferred).

  • troubleshoot_response_code

    Vendor-specific cause for a SIP response code

    Static RFC entry + top vendor-specific RAG hits for the exact code. Folds known reason-phrase variants (e.g. 484 "Address Incomplete" / "Number Incomplete" / "Overlap Receive") into the embed query and appends a chained "Next" suggestion (e.g. "→ search_sip_docs vendor:freeswitch query: ..."). One embed + one vector search per call; rate-limited.

    • code (required, 100-699).
    • vendorHint (optional, recommended).
    • context (optional, ≤8000 chars).

Network egress (rate-limited)

  • dns_diagnose_sip_target

    RFC 3263 NAPTR/SRV/A walk + sips TLS cert diagnostic for a SIP target

    Walks DNS the same way a SIP UA does (CNAME chain → NAPTR → SRV → A/AAAA, cross-checked against a second resolver). For sips targets, probes TLS and reports cert chain validity + RFC 5922 §7.2 domain compliance. When A/AAAA resolves but SRV is missing, suggests copy-pasteable zone records. Refuses targets that resolve only to RFC 1918 / loopback / multicast space (SSRF guard).

    • target (required): "sip:example.com", "example.com:5060", or bare hostname.
    • transport (default any): any | udp | tcp | tls | ws | wss.

Sipflow share hydration

  • fetch_sipflow_share

    Pull a teammate's shared trace + AI analysis into chat

    When the user pastes a sipflow.dev/share/<token> URL, this loads the redacted SIP trace AND any AI analysis the original sharer ran (executive summary, root cause, remediation steps, doc citations) in one round trip - so the agent can review their config alongside a coworker's pcap with no manual download / paste. Inherits the public share API's privacy projection (the sharer's free-text problem/architecture is never returned). Trace bytes are capped at 200kB to match the AI worker's budget; pair with minimize_sip_trace if it gets truncated.

    • url (required): full share URL, e.g. "https://sipflow.dev/share/<token>". Accepted hosts: sipflow.dev, www.sipflow.dev, mcp.sipflow.dev (plus the deployment's own origin).

Feedback channel

  • submit_sipflow_feedback

    Send the Sipflow team docs gaps, tool bugs, and feature requests

    After finishing a task, if you noticed a docs gap (search_sip_docs returned nothing for a real vendor / RFC), a tool bug, a wrong answer, or the user clearly wanted a feature we don't ship - send it back. Anonymous, one row in our DB keyed by daily-rotating IP hash. Privacy contract: ALWAYS show the user the exact summary + details you plan to send and wait for an explicit yes before calling this tool (set `userConsent: true` only after). NEVER include raw SIP traces, INVITE/REGISTER bodies, phone numbers, IPs, or Call-IDs - summarize in your own words; a server-side sanitizer is a backstop, not a license. Rate-limited at 3/min and 20/day per IP hash.

    • category (required): docs_gap | tool_bug | wrong_answer | feature_request | general.
    • summary (required): one-line description, PII-free.
    • details (optional): longer context: what the user was doing, what happened, what they expected.
    • relatedTool / relatedQuery / vendorOrTopic (optional): pin the report to a specific tool, query, or vendor.
    • contact (optional): email, only when the user explicitly provides it.
    • userConsent (required, must be `true`): set only after you've shown the user the payload and they confirmed.

Install in seconds.

Pick your client, paste the snippet, restart the editor (or reload its MCP config). One-click install in Cursor.

One-click install in Cursor

~/.cursor/mcp.json

json

{
  "mcpServers": {
    "sipflow": { "url": "https://mcp.sipflow.dev/mcp" }
  }
}

Reload Cursor (Cmd-Shift-P → "MCP: Reload") to pick up changes.

Four typical workflows.

Reviewing a vendor config in PR, diagnosing a real failure, comparing a teammate's shared trace against your own config, and explaining a call flow to a human. All short - the value is keeping you in your editor.

Review a config in PR.

Hand the agent kamailio.cfg / sip.conf / FreeSWITCH XML - Sipflow detects the vendor, extracts the loaded modules and route blocks, and grounds every recommendation in the matching vendor docs.

  1. You

    Does this kamailio.cfg look standard for handling WebRTC + SIP users? <attached: kamailio.cfg>

  2. Agent

    Reviewing the config…

    tool: review_sip_config
args: { "text": "<kamailio.cfg>", "filenameHint": "kamailio.cfg" }

  3. Agent

    → vendor: kamailio (high confidence). 18 modules loaded, 4 listen lines (udp/5060, tls/5061, ws/80, wss/443), 6 route blocks. Risk flag: WITH_NAT defined but rtpengine not loaded - RTP from NAT'd peers will not be relayed.

  4. Agent

    Looking up the websocket + rtpengine module behavior to ground the review…

    tool: search_sip_docs
args: { "query": "kamailio websocket module wss configuration", "vendor": "kamailio", "limit": 3 }

  5. Agent

    Standard for what's there: the WebSocket module is loaded, listeners cover both ws/wss, and the registrar block matches the cookbook. Two things to fix before shipping: (1) add `loadmodule "rtpengine.so"` and `modparam("rtpengine", "rtpengine_sock", ...)` so RTP traverses NAT; (2) the `nat_uac_test(64)` flag set is right for symmetric NAT but you'll also want `fix_nated_register()` in the REGISTER path. (See: kamailio.org/docs/modules/5.8.x/modules/rtpengine.html)

Debug a live failure.

Detect the stack, search vendor docs with the right filter, then minimize the trace before passing it to your own LLM.

  1. You

    Why is FreeSWITCH rejecting this re-INVITE? attached: re-invite.pcap

  2. Agent

    Detecting stack…

    tool: detect_sip_stack
args: { "text": "<pcap>" }

  3. Agent

    → vendor: freeswitch (Server: FreeSWITCH-mod_sofia/1.10.x)

  4. Agent

    Searching FreeSWITCH docs for re-INVITE rejection…

    tool: search_sip_docs
args: { "query": "freeswitch re-INVITE rejected SDP", "vendor": "freeswitch", "limit": 3 }

  5. Agent

    Found 3 sources. The most likely cause is mod_sofia rejecting the re-INVITE because the SDP offers a codec that wasn't in the negotiated answer. Try setting `inbound-codec-negotiation = greedy` or extending `media_codec_array` for this profile. (See: signalwire.com/freeswitch/.../sofia.conf.xml)

Compare a teammate's pcap against your config.

Coworker shared a Sipflow link from an upload they ran? Paste the URL and the agent loads their trace + AI analysis in one shot, then reviews your local kamailio.cfg / pjsip.conf in the same conversation - no manual download, no re-pasting.

  1. You

    My coworker is hitting 488s with this carrier - https://sipflow.dev/share/eyJqb2JJZCI6Ii4uLiJ9.abc123 - does our kamailio.cfg have the same gap? <attached: kamailio.cfg>

  2. Agent

    Loading the shared trace + analysis…

    tool: fetch_sipflow_share
args: { "url": "https://sipflow.dev/share/eyJqb2JJZCI6Ii4uLiJ9.abc123" }

  3. Agent

    → Got it. AI summary on the share: "488 Not Acceptable Here on the carrier's response to INVITE - offered codecs (G722, G729) don't intersect with the carrier's allow-list (PCMU only)." The shared trace is FreeSWITCH-flavored. Comparing against your kamailio.cfg now…

    tool: review_sip_config
args: { "text": "<kamailio.cfg>", "filenameHint": "kamailio.cfg" }

  4. Agent

    Yes - same gap. Your `dispatcher` route to that carrier doesn't strip non-PCMU codecs from the SDP either. Add `sdp_remove_codecs_by_name("G722,G729,opus")` (sdpops module) before the relay, or pin the codec at the trunk level. The shared trace's remediation step #2 applies verbatim.

Visualize the call flow.

Render a pasted trace as a Mermaid sequenceDiagram your editor draws inline. Pair it with sip_ladder_example when teaching a colleague what a pattern looks like.

  1. You

    This call drops after 30s. Diagram the BYE side so I can see who hung up. <attached SIP trace>

  2. Agent

    Rendering the ladder, with timing and noise pruned…

    tool: render_sip_ladder
args: { "text": "<trace>", "compact": true, "includeTiming": true }

  3. Agent

    Here's the call. The BYE comes from the carrier side at +29.8s - they're tearing down, not the UAC. Looks like a session-timer expiry (RFC 4028); the carrier expected a re-INVITE refresh that never arrived.

    ```mermaidyour editor renders this inline
    sequenceDiagram
    participant ip_192_0_2_10 as UAC
    participant ip_203_0_113_50 as Carrier
    ip_192_0_2_10->>ip_203_0_113_50: INVITE  +0ms
    ip_203_0_113_50-->>ip_192_0_2_10: 100 Trying  +18ms
    ip_203_0_113_50-->>ip_192_0_2_10: 200 OK (INVITE)  +1240ms
    ip_192_0_2_10->>ip_203_0_113_50: ACK  +24ms
    ip_203_0_113_50->>ip_192_0_2_10: BYE  +29800ms
    ip_192_0_2_10-->>ip_203_0_113_50: 200 OK (BYE)  +12ms
Privacy

Free, unauthenticated, private.

No account. No API key. We don't store the content of your queries. The endpoint is shared with sipflow.dev, so the same Next.js deployment serves both.

  • No signup, no API key. Point your client at https://mcp.sipflow.dev/mcp and you're live.
  • Query content is not logged or persisted.
  • Pcaps and configs you pass to minimize_sip_trace are processed in-memory and never persisted.
  • Open standards in, open standards out. Streamable HTTP, JSON-RPC, MCP.

FAQ.

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI editors and agents talk to external tools and data sources over a small JSON-RPC interface. Sipflow exposes its VoIP knowledge base and 20+ SIP/telecom utilities so any MCP-aware client (Cursor, VS Code, Claude Desktop, Codex CLI, Cline, Continue, Windsurf, Goose) can use them in your normal workflow.

Do I need an account or API key?

No. The endpoint is unauthenticated. We don't log query content.

What does it cost?

Nothing. The MCP server is free for everyone, no signup, no API key. All tools are rate-limited per IP to keep it that way.

Is the corpus open source?

The vendor docs we index are open source or publicly published. The curated index, the chunking pipeline, and the search are part of Sipflow.

Does it send my pcap or config to the server?

Tools that operate purely on text you supply (review_sip_config, minimize_sip_trace, lint_sip_request, parse_sip_message, diff_sip_messages, parse_sdp, compare_sdp_offer_answer, detect_sip_stack, detect_sip_vendor_from_config, render_sip_ladder, sip_ladder_example, lookup_*, validate_e164_number, stir_attestation_explainer, webrtc_sip_checklist) process input in memory and return immediately - nothing is persisted. The text never leaves the request/response cycle.

Which tools make outbound network calls?

search_sip_docs and troubleshoot_response_code embed your query and search our vector store. validate_stir_shaken_identity fetches the x5u certificate URL you supply. dns_diagnose_sip_target performs DNS lookups (NAPTR / SRV / A / AAAA) and, for sips targets, TLS handshakes (cert chain validation, RFC 5922 §7.2 domain check) against the target you supply, with a per-IP rate limit and a hard refusal of private / loopback / multicast targets. Everything else is pure CPU.

Can the agent really review my kamailio.cfg?

Yes - that's exactly what review_sip_config and webrtc_sip_checklist are for. The tool detects vendor (Kamailio, OpenSIPS, FreeSWITCH, Asterisk PJSIP, chan_sip, SIP.js, JsSIP, …) from filename + structural signatures, extracts your loaded modules / route blocks / profiles, surfaces risk flags, and suggests follow-up search_sip_docs queries so the agent can ground every recommendation in vendor docs and RFCs.

My coworker shared a Sipflow link with me - can the agent open it?

Yes. Paste the sipflow.dev/share/<token> URL into chat and the agent will call fetch_sipflow_share - it pulls the redacted trace AND any AI analysis the original sharer ran (executive summary, root cause, remediation steps, doc citations) in one round trip. From there you can pair it with review_sip_config on your own kamailio.cfg / pjsip.conf / FreeSWITCH XML, or render_sip_ladder to draw the call flow inline. The original sharer's free-text problem/architecture is intentionally NOT returned (the public share API strips those for privacy).

Ship one MCP entry. Skip context-switching for the rest of the week.

Free. No signup. Works with every popular MCP client.

Get the install snippetOr open the analyzer

SIP Flow · Free, private SIP/VoIP analyzer

Core utility runs entirely in your browser. AI debugging is opt-in and pseudonymizes by default.

ContactPrivacy