SIPPTS: auditing SIP servers and PBX extensions from the command line

One tool that speaks the protocol rather than probing ports

SIPPTS is a set of tools to audit VoIP servers and devices using the SIP protocol, programmed in Python, and the README states its purpose as allowing you to check the security of a VoIP server using the SIP protocol. That framing is the point. A conventional port scan tells you something is listening on 5060; it does not tell you whether the server answers an OPTIONS request, whether it leaks a digest header, or whether an extension set is enumerable. A protocol-aware tool answers the second kind of question, and that is what SIPPTS is built for. Running the tool with no arguments prints the help, and the command surface it lists shows the scope, with modules for a fast SIP scanner, searching SIP extensions of a PBX, a remote password cracker, enumerating methods of a SIP server, a SIP ping, trying to make calls through a PBX, dumping SIP digest authentications from a PCAP file, SIP digest authentication cracking, flooding a SIP server, SIP network sniffing, ARP spoofing, extracting data from a PCAP file, an Asterisk AMI pentest, sending a customised message, and sending one over WebSocket.

sippts -h
usage: sippts [-h] [-up] {video,astami,scan,exten,rcrack,send,wssend,enumerate,leak,ping,invite,dump,dcrack,flood,sniff,spoof,pcapdump,rtpbleed,rtcpbleed,rtpbleedflood,rtpbleedinject} ...

The last three modules, covering RTPBleed and RTCPBleed detection and exploitation, are the most specialised, since they target a specific class of media stream weakness in RTP and RTCP implementations rather than the signalling layer.

The scanner is multithreaded and works over UDP, TCP and TLS

The scan module is described as a fast SIP scanner using multithreading that can check several IPs and port ranges, and it works with UDP, TCP and TLS protocols. The option list is the clearest statement of what you can point it at. The target can be a single host or IP address, a network in CIDR form, or a file with several IPs or network ranges. The port argument accepts a single port, comma separated lists, ranges, and the keyword ALL for 1 through 65535, with 5060 as the default. The protocol argument takes udp, tcp, tls or all, defaulting to udp. There is also an outbound proxy option, which matters because SIP traffic often crosses a network boundary that you would rather traverse through a controlled exit point than directly. The header options let you shape the request precisely, and the defaults are informative. The SIP method defaults to options, the From user defaults to 100, the User-Agent header defaults to pplsip, and the domain defaults to the target IP address. The P-Preferred-Identity and P-Asserted-Identity options are there because those headers are what real user agents send, and a scanner that sends an unusual request shape gets an unusual answer.

The command set covers exposure, enumeration and media

Reading the module list as a workflow is more useful than reading it as a feature list. The scan module establishes whether SIP is exposed and what it answers. The exten module searches SIP extensions of a PBX, which is the question an auditor asks when a customer is told their direct dial numbers are unreachable from outside. The enumerate module enumerates the methods of a SIP server, and the astami module is an Asterisk AMI pentest for the specific case where the management interface is the weak point rather than the signalling. The invite module tries to make calls through a PBX, which is a functional test of authorisation on the call path rather than a credential test. The dump module pulls SIP digest authentications out of a PCAP file, and dcrack does the digest authentication cracking against data you have captured yourself, so the workflow is capture then analyse, and the analysis happens on your machine. The rtpbleed family is separate again, and the three variants, detect, flood and inject, tell you that the tool can do more than report on a media vulnerability, which is worth thinking about before you install it on a laptop you take to a customer site.

Configuration lives in files you can read, and the version is one file

The repository is a conventional Python package, with a pyproject.toml, a setup.py, a src/ directory, a bin/ directory, a changelog.txt and a cveversion file. The pyproject file names the project sippts, requires Python 3.7 or newer, and reads its version and dependencies dynamically. The comment in that file explains the arrangement, that the version is read from the version file, the same one GitHub serves for the update check, so releasing means editing that single file. The setup.py is described in its own docstring as a shim to allow for editable install, and it copies the version file into the package data at install time so an installed copy can read it, with a comment explaining that the root version file is not part of the package. The dependency list is small and tells you what the tool does at the protocol level, with netifaces for network interface enumeration, requests, IPy for IP address handling, scapy for packet construction, pyshark for capture analysis, websocket-client for the WebSocket sending module, and rel for the RTP related work. Two optional extras are declared, cursor for terminal handling and asterisk-ami for the AMI module, and the comment notes that extra_requires is not a setuptools option and was silently ignored, so those were never declared anywhere and are installed with the full extra.

Legal use is stated plainly, which is the right way to handle this class of tool

The README has a section headed on whether sippts can be used for illegal purposes, and the answer is that the purpose of the tool is to audit your own systems or to perform penetration tests on systems for which you have received express authorisation, with the author not responsible for misuse. The licensing section says the tool is free to use, modify and distribute, and asks that modifications include a reference to the site. The project is licensed GPL-3.0, and the two are consistent, since a copyleft licence on a security tool is the arrangement that most discourages silent commercial redistribution while still allowing the audit work to happen. The practical advice for a reader is the obvious one, but it is worth stating because the module list includes a remote password cracker, an Asterisk AMI pentest, flooding and ARP spoofing. Those are the capabilities that turn a scanning utility into something that will get you blocked from a network, and the difference between a legitimate audit and an intrusion attempt is authorisation, not configuration. The tool's own documentation is clear that the authorisation has to be in place before you point it at a target, and the audit trail that matters is a signed scope document, not a config file.

Where SIPPTS is the wrong tool

The first limit is that the SIP protocol is not the only thing standing between you and the media, and a tool that only speaks signalling tells you nothing about the RTP stream itself, the codecs in use, or whether the call is encrypted. If your concern is eavesdropping on calls, you need a different analysis. The second is that the toolkit assumes a traditional SIP deployment, so a PBX that only offers a web interface or a proprietary management API is out of scope, and the Asterisk module is the only sign of interest in the wider management surface. The third is the age of the packaging. The release list shows v4.2.1 from 2026-09-14 and then v4.1.2 from 2024-11-22, so the current release is recent but the one before it sat unchanged for nearly two years, and the Python floor of 3.7 in the pyproject file suggests the code has not been modernised. The fourth is the operational one. This is a collection of scripts with a menu rather than a tool with a configuration model, which makes it easy to start and easy to misuse, and it makes the audit log something you have to build yourself, since nothing here records what you did. For a one-off internal assessment with a written scope, that is a fine trade. For a repeatable compliance check, the operational discipline has to come from somewhere else.

Editorial conclusion

Adopt SIPPTS if you run a SIP-based PBX, an Asterisk system or a VoIP gateway and want a single tool that can check exposure, extension configuration and media stream handling, and if you have written authorisation for every system you point it at. Skip it if you only need to confirm whether ports are open, since a port scanner covers that, and skip it if you need something hardened for continuous scanning. Verify first that the SIP stack you audit is one the tool understands, that your Python version meets the requirement, and that the extension and digest modules are pointed only at systems you own or are engaged to test.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Pepelux/sippts on GitHub
4. README
5. Releases