PAGES
← all tools
◆ Reconnaissance & OSINT

sipsak

0.9.7 open-source

sipsak is a command-line tool for testing SIP applications and devices, described as a SIP swiss army knife.

source ↗ rss ↗ What is a cyber toolchain? last repo push May 26, 2025

Summary

sipsak is an open-source command-line tool for testing and probing SIP (VoIP signaling) servers, letting a user send crafted requests, run trace and usrloc modes, throttle timing, and check authentication behavior without needing a full softphone stack. It runs as a single binary built from source with autoconf and make, with optional GnuTLSGnuTLSAn open-source TLS/SSL library maintained by the GNU Project that implements secure communications protocols, giving cyber tools a portable, LGPL-licensed alternative to OpenSSL for encrypted connections., OpenSSL or c-ares support for TLS and DNS SRVSRVA DNS record type that advertises the hostname and port for a specific service, letting clients discover endpoints without hardcoded addresses. lookups, and is aimed at people doing reconnaissance or interoperability testing against VoIP infrastructure rather than general network scanning. It sits in the SIP/VoIP testing niche rather than broader recon tooling, filling a role comparable to protocol-specific probing utilities. Development goes back to 2002 with 18 contributors, but there have been no commits in the past year, so anyone adopting it should expect a stable, largely unmaintained tool rather than active development.

sipsak is a command-line tool for testing SIP applications and devices, described as a SIP swiss army knife.

How sipsak helps

Is a SIP server actually reachable and responding before troubleshooting goes any further?

sends a single crafted request to the target and reports whether a response comes back, standing in for a full softphone or client setup

Does a SIP server accept forged or malformed requests it should be rejecting?

crafts requests with adjustable headers and content, sends them directly to the target, and shows the raw response so bad behavior is visible without a client stack in the way

Will a SIP server hold up when hit with a burst of registrations or repeated requests?

fires repeated requests at adjustable timing and tallies responses and failures across the run, exposing where the server slows down or drops requests

Is a set of credentials actually valid against this SIP server's authentication?

replays the exchange with a supplied password or precomputed digest and reports whether the server's challenge is satisfied

Which user locations does the registrar actually have on file?

queries the server in usrloc mode across a range of generated usernames and reports which registrations exist and what they resolve to

Does a SIP proxy or outbound route send requests where they are actually supposed to go?

places its own address in the request and inspects where the response and any forwarded messages land, revealing routing or proxy misconfiguration

Languages

Not documented

Score card

  1. Shipping velocity releases a month, last 12 months
  2. Documentation quality release-notes rubric, 0–100
  3. Breaking-change discipline how rarely a release breaks users, and notice given
  4. Maintenance risk quiet time against its own cadence, maintainers
  5. Innovation & surface new capabilities, API and MCP surface
  6. Community health
  7. Contributor trend distinct committers, this year against last
  8. Maintainer concentration bus factor now against a year ago
  9. Issue backlog trend issues closed per issue opened, 12 months
  10. Responsiveness median time to a maintainer’s first reply

Nine scores for sipsak, each built from the releases, notes and API history this site tracks — and, on Researcher and Business, where it stands among every measured tool in its category and how that has moved.

Score cards are part of every paid plan.

See plans →

Each score is 0–100 on a published rubric, derived from data this site already shows. A dimension we cannot measure says so — it is never scored 0 and never enters a rank.

How this is scored
  • Shipping velocity — releases a month over the last 12 months, on a log scale where 16 a month scores 100. Needs 3 releases in the window.
  • Documentation quality — the release-notes rubric published on the analytics page, unchanged.
  • Breaking-change discipline — the share of releases carrying a breaking change (none scores 100, half or more scores 0). Only projects that label breaking changes are measured: a clean record cannot be told from an unlabelled one.
  • Maintenance risk — quiet time measured against the tool's own release cadence (quiet longer than 90 days and three typical gaps scores 0), plus the number of active maintainers and whether contributors are growing, where known. Higher is lower risk.
  • Innovation & surface — new capabilities in the feature ledger this year, API and MCP operations added, and the share of commits that are features: the mean of whichever we hold.
  • Community health (open-source tools only) — each is a direction, not a size: contributors this year against last, the bus factor now against a year ago, and issues closed per issue opened, where steady scores 50, doubled 100 and halved 0; plus the median time to a maintainer's first reply (an hour scores about 100, a month or more 0). A commercial card has no repository and carries none of the four.
  • Documented delivery (commercial tools) — when a vendor's documented new capabilities have slowed against its own baseline, that counts against the overall standing as heavily as two low dimensions. Steady delivery, or too little history to judge, leaves the standing alone; it is never a sixth score.
  • Open-source tools are scored on repository signals; commercial tools on their published changelog. Ranks compare tools within one category and one profile and need at least five measured peers; the overall standing needs three ranked dimensions. Best-in-breed or consolidator is a shape, not a quality, and is never scored.

Release-note detail over time

See how much detail sipsak puts in its release notes, quarter by quarter, and compare it with tracked tools in the same category. This history uses up to ten retained, reviewed notes per tool; sparse or blank older quarters may reflect that limit.

Checking release-note history…

Explore the full chart →

Releases

Show

2 entries

  1. October 20261
  3. April 20191
    Show

    2 entries

    1. docs update Oct 10, 2026 · issue 101

      sipsak gains -X continuous monitoring mode that runs until a SIP device failure is detected⁠︀︄︇︀︅︉︀︅︀︀︃︀︀︅︅︀︅︊︀︄︆︀︃︄⁠

      └──▷ TRY IT
      Continuously poll a SIP device every 250 ms and exit with failure only if 5 consecutive retries go unanswered — useful in monitoring scripts that should stay alive through transient negative responses.
      $ sipsak -s sip:foo@bar.com -X -Z 250 -D 5
      • Adds -X flag for continuous monitoring mode: keeps sending SIP messages until a failure occurs, ignoring RFC 3261 retransmission timers in favour of constant intervals — pair with -Z (interval in ms) and -D (max retries) for controlled polling.⁠︀︄︇︀︅︉︀︅︀︀︃︀︀︅︅︀︅︊︀︄︆︀︃︄⁠

      1 detail in Everything

    2. 0.9.7 Apr 27, 2019 · release notes

      sipsak 0.9.7 adds new command-line options

      └──▷ GET THIS VERSION 
      $ git clone --branch 0.9.7 https://github.com/nils-ohlmeier/sipsak.git
# already have the repo? check out this version:
$ git checkout 0.9.7
      • sipsak 0.9.7 introduces several new CLI flags (details in Changelog)

      1 detail in Everything

    Project health

    Issue, contributor and maintainer activity in nils-ohlmeier/sipsak, 2023-10 – 2026-09, as of 2026-09-25. Twelve-month figures first; the trend lines run the whole window.

    1. Contributors 0 ±0 vs prior 12 months
    2. Maintainers 0 +0 joined · −0 left, last 12 months
    3. Bus factor 0 committers behind half the commits
    4. Community-filed 100% of issues opened, last 12 months
    5. Median time to close not measured issues closed, last 12 months
    6. Open backlog 18 of 34 issues ever filed
    1. Issues opened / month 0 · 0 communitymaintainers
    2. Open backlog 18
    3. Contributors / month 0
    4. Commits / month 0
    5. Stars 176
    Issue themes, last 12 months
    • other 100%

    Counts from the project's public repository and git history; no individuals are identified. Maintainers are the committers covering 80% of the last year's commits. how we measure this

    Add the badge to your README

    Maintain this project? The badge links readers straight to this page, so they can follow every release here.

    Tracked by Cyber Toolchain Choose a badge style and copy the code →
    compare.md

      Free the public facts, no sign-in Any paid plan all other sections Researcher & Business pricing history and category rank

      my-toolchain — 0 tools

        Betas, release candidates and previews. Turn it off to see final releases only. It also applies to changes you ask for over MCP when you're signed in.
        browse all tools → score card for your toolchain →
        cyber-toolchain / feedback

        Send us feedback