SIP and RTP Explained: How VoIP Calls Work and How to Secure Them

A VoIP call uses three protocols working together. SIP (Session Initiation Protocol, RFC 3261) finds the other party and sets up, changes and ends the call. SDP (Session Description Protocol, RFC 8866), carried inside SIP, describes the media: codecs, addresses and ports. RTP (Real-time Transport Protocol, RFC 3550) then carries the actual audio and video, with RTCP reporting on quality alongside it.

None of the three encrypts anything by default. Securing a phone system means adding layers on purpose: TLS for signalling, SRTP for media, keys exchanged without leaking them, strong registration credentials, a dialplan that cannot reach premium numbers from untrusted callers, and STIR signatures for calls that cross carrier networks. This post covers each protocol on the wire, the weakness classes the standards describe, and configuration checks from the official Asterisk, Kamailio and OpenSSL documentation.

Key takeaways

• SIP (RFC 3261, 2002) handles signalling; SDP (RFC 8866, January 2021) describes media and is negotiated with offer/answer (RFC 3264); RTP and RTCP (RFC 3550, July 2003) carry media and quality reports.
• IANA registers SIP on port 5060 (UDP, TCP, SCTP) and SIPS on 5061. RTP ports are chosen per call in SDP.
• SIP over TLS is hop by hop, not end to end, because proxies must read and rewrite headers. RFC 5630 (October 2009) requires TLS on every hop of a SIPS request, including the last.
• SRTP (RFC 3711, March 2004) defaults to AES counter mode with HMAC-SHA1 and an 80 bit tag. Authentication is mandatory for SRTCP and recommended for SRTP; without it there is no replay protection.
• SRTP keys travel either inside SDP (SDES, RFC 4568), which needs encrypted signalling, or through DTLS on the media path (RFC 5763 and RFC 5764, May 2010).
• STIR (RFC 8224, 8225 and 8226, February 2018) lets carriers sign the calling number. The FCC required US voice providers to implement STIR/SHAKEN in the IP portions of their networks by June 30, 2021.
• Most real failures are operational: weak registration passwords, toll routes reachable from untrusted contexts, cleartext RTP and middleboxes that rewrite signalling.

What SIP, SDP and RTP are for, where they sit and which standards define them

A phone call over IP has two separate problems: rendezvous and control (finding the other party, ringing, holding, transferring, hanging up) and media (moving small slices of audio fast enough that a conversation feels natural). The VoIP suite splits these jobs cleanly.

SIP is an application layer signalling protocol. It runs over UDP, TCP, SCTP or TLS over TCP, and in browsers it can run over WebSocket (RFC 7118, January 2014). RFC 3261, edited by Jonathan Rosenberg, Henning Schulzrinne and others, is the core specification. It obsoletes RFC 2543. The document is dated June 2002, while the RFC Editor's index lists July 2002. The RFC Editor lists more than twenty documents that update RFC 3261, including RFC 5630 (SIPS), RFC 8760 (Digest algorithms) and RFC 8996 (retiring old TLS versions).

SDP is not a protocol in the request and response sense. It is a text format for describing a media session, which SIP carries as a message body. RFC 8866 (January 2021) is the current specification and obsoletes RFC 4566. RFC 3264 (June 2002) defines how two parties use SDP to agree on a session: one side offers, the other answers.

RTP is a media transport, almost always over UDP, that adds what real time media needs and UDP lacks: a sequence number, a timestamp, a payload type naming the codec and a source identifier. Its companion, RTCP, carries reception statistics and participant identity. RFC 3550 (July 2003) defines both and obsoletes RFC 1889. RFC 3551 (July 2003, obsoleting RFC 1890) is the audio and video profile that assigns the familiar static payload types, such as 0 for G.711 mu-law (PCMU) and 8 for G.711 A-law (PCMA).

SRTP (RFC 3711, March 2004) is an RTP profile that adds encryption, message authentication and replay protection for SIP phones, session border controllers and WebRTC alike.

Here is how the pieces map to roles in a typical deployment:

How SIP works on the wire

SIP messages are text, in a format deliberately modelled on HTTP/1.1. A request starts with a request line naming the method, the Request-URI and the version SIP/2.0; a response starts with a status line carrying a three digit code. Headers follow, then a blank line, then an optional body, usually SDP.

RFC 3261 defines six methods: REGISTER for registering contact information; INVITE, ACK and CANCEL for setting up sessions; BYE for ending them; and OPTIONS for querying capabilities. Extensions have added more. The IANA SIP Parameters registry, fetched for this post, lists 14 methods: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE and UPDATE.

Response codes follow the HTTP pattern: 1xx provisional (100 Trying, 180 Ringing, 183 Session Progress), 2xx success, 3xx redirection, 4xx client errors (including 401 Unauthorized and 407 Proxy Authentication Required, which carry Digest challenges), 5xx server errors and 6xx global failures.

The headers that matter for security

Registration

A phone sends REGISTER for its address of record, such as sip:alice@example.com, with a Contact header naming its current address. A registrar that requires authentication answers 401 with a Digest challenge containing a nonce, and the phone retries with an Authorization header holding a hash of the username, password, nonce and request details. RFC 3261 mandates Digest for this purpose and forbids Basic authentication outright: servers "MUST NOT accept or request Basic authentication." RFC 3261 Digest uses MD5; RFC 8760 (March 2020) adds SHA-256 and SHA-512/256 and calls MD5 obsolete, though device support varies.

An INVITE dialog, step by step

The core call flow in RFC 3261 section 4 is often called the SIP trapezoid, because two proxies sit between the caller and callee. This simplified version shows a call from Alice to Bob through one proxy.

Alice (UA)              Proxy                 Bob (UA)
    |                     |                      |
    |--- INVITE (SDP offer) ->|                  |
    |<-- 100 Trying ------|                      |
    |                     |--- INVITE (SDP offer) ->|
    |                     |<-- 180 Ringing ------|
    |<-- 180 Ringing -----|                      |
    |                     |<-- 200 OK (SDP answer)|
    |<-- 200 OK (SDP answer)|                    |
    |--------------------- ACK ----------------->|
    |                                            |
    |<========= RTP media both ways ============>|
    |                                            |
    |<-------------------- BYE ------------------|
    |--------------------- 200 OK -------------->|

Step by step:

1. INVITE. Alice's phone sends an INVITE to sip:bob@example.com with an SDP offer: IP address, port and an ordered list of codecs.
2. 100 Trying. The proxy answers at once so Alice's phone stops retransmitting. Over UDP, SIP runs its own retransmission timers; RFC 3261 sets timer T1 to a default of 500 ms.
3. INVITE forwarded. The proxy adds its Via header, may add Record-Route to stay in the path, looks up Bob's registered contact and forwards the request.
4. 180 Ringing. Bob's phone is alerting; provisional responses retrace the Via path.
5. 200 OK with SDP answer. Bob picks up. His SDP selects codecs from the offer and gives his media address and port.
6. ACK. Alice confirms the 200. ACK for a 2xx is its own end to end transaction and may go directly to Bob's Contact unless Record-Route keeps the proxy in the path.
7. Media. RTP flows between the addresses in the two SDP bodies, not through the SIP proxy, unless a PBX or session border controller anchors it.
8. BYE. Either side ends the call with BYE inside the dialog; the other confirms with 200 OK.

Two details explain many security problems. Signalling and media take different paths with different protection, so encrypting one says nothing about the other. And a dialog is identified by Call-ID plus the From and To tags, which are visible on any unencrypted transport; RFC 3261 discusses forged BYE requests for that reason.

How SDP describes media

An SDP body is a short list of type=value lines in a fixed order. RFC 8866 defines the session level lines v= (version), o= (originator and session identifier), s= (session name), c= (connection address), t= (timing) and optional a= attributes, followed by one or more media descriptions, each starting with m= (media type, port, transport profile and payload types). The k= line for carrying keys is marked obsolete.

A minimal audio offer looks like this:

v=0
o=alice 2890844526 2890844526 IN IP4 192.0.2.10
s=-
c=IN IP4 192.0.2.10
t=0 0
m=audio 49170 RTP/AVP 0 8 9
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000

The m= line profile shows whether media will be protected: RTP/AVP is plain RTP, RTP/SAVP is SRTP, and UDP/TLS/RTP/SAVP is SRTP keyed through DTLS, as WebRTC uses. SDES adds a=crypto lines; DTLS-SRTP adds a=fingerprint and a=setup.

Offer and answer

RFC 3264 describes the negotiation rules. The offerer lists the media streams and, for each, the codecs it supports in order of preference. The answerer must reply with the same number of m= lines in the same order, picks a subset of the offered codecs for each stream, and can reject a stream by setting its port to zero. Either party can later send a new offer, for example in a re-INVITE to put a call on hold or change codecs. That flexibility is useful and is also why RFC 3261 lists forged re-INVITEs as a way to redirect media or weaken session security on unprotected signalling.

How RTP and RTCP work on the wire

The RTP header

Every RTP packet starts with a fixed 12 octet header defined in RFC 3550 section 5.1, optionally followed by contributing source identifiers added by a mixer.

RFC 3550 says the initial sequence number and timestamp should be random, to make known plaintext attacks on encryption more difficult; that is a hardening detail, not security by itself. The SSRC is also chosen randomly so that two streams in the same session are unlikely to collide.

RFC 3551 assigns static payload types, for example 0 PCMU, 8 PCMA, 9 G722 and 18 G729, all at an 8,000 Hz RTP clock, and reserves 96 to 127 for dynamic types that are bound to a codec per call by an a=rtpmap line in SDP.

RTCP

RTCP packets travel alongside RTP and carry control information rather than media. RFC 3550 defines five types: SR (sender report, with transmission and reception statistics from active senders), RR (receiver report), SDES (source description, including the CNAME that ties streams from one participant together), BYE (leaving the session) and APP (application defined). Packets are sent as compound packets that start with an SR or RR and include an SDES with a CNAME. RTCP traffic is scaled so it uses about 5 percent of the session bandwidth.

RTCP matters for security because it reveals information, such as CNAMEs that often contain user and host names, and because forged reports can mislead a sender about network conditions. SRTP makes RTCP authentication mandatory.

Ports

RTP has no well known port. Each side picks a port and announces it in SDP. RFC 3550 says RTP should use an even destination port and RTCP the next higher odd port, and that RTP and RTCP must never share a port unless something else demultiplexes them. RFC 5761, which updates RFC 3550, defines exactly that: RTP and RTCP multiplexed on one port, which is how WebRTC and many modern trunks work. The IANA port registry also lists 5004 and 5005 for the RFC 3551 profile, for applications that choose to use them as a default pair.

Versions and history

What is deployed in practice: SIP 2.0 per RFC 3261 is universal, and nothing has replaced it for interconnecting carriers, trunks and enterprise PBXs. SRTP with AES counter mode and HMAC-SHA1 is the most common media protection. SDES is still the most common way enterprise phones key SRTP, while browsers and WebRTC gateways use DTLS-SRTP. MD5 Digest remains common on phones despite RFC 8760, so the strength of a registration still comes down mostly to the password.

Security properties: what SIP and RTP guarantee and what they do not

Out of the box, without TLS, SRTP or STIR, the suite guarantees almost nothing:

RFC 3261 section 26.2 explains why SIP cannot simply be encrypted end to end: proxies must read the Request-URI, Route and Via headers to route a request and must add Via headers of their own. So SIP relies on hop by hop security and on trusting the proxies along the path to some degree. That one design fact explains most of what follows.

How SIPS and TLS protect signalling

RFC 3261 requires proxies, redirect servers and registrars to implement TLS and to support both mutual and one way authentication. It strongly recommends that user agents be able to initiate TLS, and requires every SIP element that supports TLS to have a way to validate certificates.

A sips: URI says that the request must be carried over TLS. RFC 3261 originally allowed a quiet gap here: the final hop, from the callee's proxy to the callee's device, could fall back to an unprotected transport. RFC 5630 removed that last hop exception, so a SIPS request must use TLS on every hop up to the remote target. It also confirms that the older transport=tls URI parameter, which RFC 3261 had already deprecated, should not be used to signal security.

However well TLS is configured, each proxy still sees the full message, including any SDES media keys in the SDP, and TLS proves nothing about the telephone number in the From header.

RFC 8996 (March 2021) updates RFC 3261 to deprecate TLS 1.0 and 1.1. TLS 1.2 or 1.3 is the floor for SIP today. For background on what changes between those versions, see TLS 1.3 vs TLS 1.2: what to disable and what is TLS.

How SRTP protects media

SRTP keeps the RTP header in the clear, so routers, header compression and monitoring can still work, and protects the payload. RFC 3711 defines default transforms that are also mandatory to implement:

The NULL cipher is also mandatory to implement. RFC 3711 is explicit that "mandatory-to-implement" does not mean "mandatory-to-use", and NULL exists for cases where only authentication is needed. A NULL cipher suite on a call that you think is encrypted is a configuration problem worth checking for.

The authentication tag is recommended for SRTP and mandatory for SRTCP. RFC 3711 forbids SRTCP from using HMAC-SHA1 with a tag or key shorter than the defaults, and says shorter values for SRTP are not recommended without careful consideration. The 32 bit tag variant seen in some phones trades integrity margin for bandwidth.

Each SRTP receiver keeps a replay list, a sliding window of packet indexes it has already accepted, and drops packets it has seen before or that fall behind the window. Replay protection depends on authentication; without the tag, an attacker who can inject packets can also replay them.

RFC 3711 also warns about the "two-time pad": if two streams are encrypted with the same key and the same SSRC and index, they reuse keystream, and combining the two ciphertexts exposes information about both plaintexts. This is far more likely with manual or static key management, one of several reasons keys should be negotiated per session.

Getting keys to SRTP: SDES versus DTLS-SRTP

SRTP does not say how the ends agree on a master key. Two standards dominate.

SDES (RFC 4568, July 2006) puts the key in the SDP. Each offer includes one or more a=crypto lines naming a crypto suite and the inline key material. The answerer picks one and returns its own key. It is simple, but the RFC's abstract notes that the attribute "requires the services of a data security protocol to secure the SDP message." In other words, SDES over unencrypted SIP sends the media key in cleartext next to the media, and every proxy that handles the SDP can read it. The Asterisk documentation makes the same point for its sdes setting: encrypted SIP transport "should be used in conjunction with this option to prevent exposure of media encryption keys."

DTLS-SRTP (RFC 5763 and RFC 5764, May 2010) moves the key exchange to the media path. Each side puts a hash of its certificate in SDP with an a=fingerprint line and declares its role with a=setup (for example actpass in an offer). The endpoints then run a DTLS handshake directly over the RTP ports, negotiate an SRTP protection profile with the use_srtp extension and derive SRTP keys from the handshake. Proxies never see the media keys. RFC 5764 defines profiles including SRTP_AES128_CM_HMAC_SHA1_80 (0x0001), SRTP_AES128_CM_HMAC_SHA1_32 (0x0002) and two NULL cipher variants. The weak point moves to the fingerprint: if an attacker can rewrite the SDP, they can substitute their own fingerprint. RFC 5763 says the SIP Identity mechanism can protect the fingerprint from modification by intermediate proxies.

How STIR addresses caller ID spoofing

Neither TLS nor SRTP solves the problem most people associate with phone fraud: a call that claims to come from a number it did not come from. In SIP, the From header is whatever the originating device or carrier put there. RFC 8224 says it directly: SIP's baseline security mechanisms are "inadequate for cryptographically assuring the identity" of the people who originate requests, especially between domains.

The IETF's STIR (Secure Telephone Identity Revisited) work answers that with three documents published in February 2018:

• RFC 8224, Authenticated Identity Management in SIP, obsoletes RFC 4474 and defines the Identity header. The originating provider's authentication service signs the calling and called numbers plus a timestamp; the terminating verification service fetches the signer's certificate, checks the signature and checks freshness, with sixty seconds recommended. Verifiers can answer 428 (Use Identity Header) or 438 (Invalid Identity Header).
• RFC 8225, PASSporT, defines the signed object: a JSON Web Token whose required claims include orig (the originating identity), dest (the destination) and iat (issued at). Implementations must support ES256, the ECDSA P-256 with SHA-256 signature algorithm.
• RFC 8226, Secure Telephone Identity Credentials, defines X.509 certificates that assert authority over telephone numbers, including a TN Authorization List extension.

SHAKEN (Signature-based Handling of Asserted information using toKENs) is the industry profile of STIR produced by ATIS and the SIP Forum, according to the FCC's March 2020 order. RFC 8588 (May 2019) adds the two claims SHAKEN needs: an attestation level, where "A" means full attestation (the provider knows the customer and their right to the number), "B" partial attestation (the provider originated the call but cannot vouch for the number) and "C" gateway attestation (the call came in from a gateway, such as a legacy network, that could not be authenticated), and an origid UUID that supports tracing a call back to its source.

In the United States, FCC Report and Order FCC 20-42, adopted March 31, 2020, required all voice service providers to implement STIR/SHAKEN in the IP portions of their networks by June 30, 2021, alongside the TRACED Act (Pub. L. No. 116-105, 2019). The same order sought comment on extensions, intermediate providers and non-IP networks, so a given provider's exact obligations depend on later orders.

STIR authenticates the originating provider's assertion about a number, not the person speaking, and calls that cross a non-IP segment lose the Identity header. An enterprise PBX does not usually sign anything itself; its carrier does. For an enterprise, STIR mostly matters as a reason to keep your carrier's records of which numbers you may use accurate.

Weakness classes, described as concepts

RFC 3261 section 26.1 lists "classic" threats against SIP. The list below starts from those and adds the operational classes seen in real PBX deployments. These are concepts, not instructions.

Registration hijacking

A registrar decides whether a REGISTER may change the contacts for an address of record. If it trusts the From header, or if the credentials are weak, someone else can register their own device as the contact and receive the victim's calls. RFC 3261 places this in the family of threats that come from "the absence of cryptographic assurance of a request's originator." Digest authentication with a strong per device password is the baseline answer; TLS client certificates are stronger.

Toll fraud through weak registrations and open dialplans

The most expensive VoIP problem for most organisations is someone else placing calls through your trunk, typically to premium rate or international numbers. It happens when an extension or trunk accepts weak credentials, when a trunk is authenticated by source IP alone and that source can be reached, or when the dialplan lets low trust callers reach outbound routes. The Asterisk dialplan security guidance says to isolate outgoing and toll services from incoming connections in separate contexts, assume anything that can enter a context can reach every extension in it, and "never ever put outgoing toll services in the 'default' context."

Server impersonation and redirection

A user agent that cannot authenticate its server can be steered by a forged response, such as a fake 301 pointing at another registrar. RFC 3261 says prevention requires user agents to authenticate the servers they talk to, which in practice means TLS with certificate validation on.

Tampering, media redirection and forged teardown

Proxies are trusted to route requests, not to change their bodies. An intermediary that alters SDP can point RTP at a recording device or downgrade SRTP to RTP; RFC 3261 names exactly this wiretapping case. On unencrypted signalling, anyone who sees a dialog's identifiers can also inject a BYE that ends the call or a re-INVITE that moves media. Hop by hop TLS stops outsiders but not a compromised proxy; DTLS-SRTP with a protected fingerprint narrows the window further.

Eavesdropping on RTP and exposed keys

Plain RTP carries encoded audio with a payload type that names the codec, so anyone who captures the packets can play the conversation back with ordinary protocol analysis tools. RFC 3550 deliberately leaves security to profiles and lower layers. A common half fix is SRTP keyed by SDES over SIP on UDP 5060: the phone shows a lock icon, but whoever captured the signalling also has the media key.

Downgrade to cleartext media

Many systems offer SRTP but accept RTP if the other side declines, and that fallback is what an on-path attacker or a misconfigured intermediary can trigger. Asterisk exposes the choice as media_encryption_optimistic, which uses encryption "if possible but does not terminate the session if not achieved." It defaults to off.

Signalling floods and reflection

RFC 3261 describes several denial of service patterns: forged source addresses and Via headers that make SIP elements send responses at a victim, falsified Route values sent to forking proxies that multiply traffic, and unauthenticated REGISTER requests that de-register users or exhaust a registrar's memory. Source spoofing is easy over UDP, so internet facing SIP over UDP is the riskiest combination. Rate limits, authentication on every request type and TLS for public endpoints reduce the exposure.

Enumeration

Different answers for valid and invalid users let an outsider list extensions to target. Asterisk's documentation warns that its allow_unauthenticated_options setting "can allow information disclosure" of endpoint names through OPTIONS requests. It defaults to off.

SIP ALG breakage

Many routers include a SIP application layer gateway that rewrites addresses inside SIP headers and SDP to help calls cross NAT. When it misparses a message, the result is one way audio, dropped registrations and calls that fail after a fixed time, and it means a device on the path is modifying signalling. SIP over TLS stops an ALG from reading or rewriting messages. The cleaner fix is to disable the ALG and handle NAT deliberately at the PBX or session border controller.

Secure configuration, with defender-side check commands

Only run these against systems you own or are authorised to test. The configuration options and commands below come from the official Asterisk documentation (docs.asterisk.org), the Kamailio TLS module documentation (kamailio.org) and the OpenSSL s_client manual page (docs.openssl.org), each cited in Sources.

Step 1: put signalling on TLS 1.2 or later

In Asterisk's PJSIP channel driver, a TLS transport is a type=transport section in pjsip.conf. The Asterisk Secure Calling tutorial shows the shape; the method option is documented in the res_pjsip module reference, which lists tlsv1, tlsv1_1, tlsv1_2, tlsv1_3 and older SSL values, and states that the default "is currently TLSv1." Set it explicitly.

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
method=tlsv1_2

The same reference documents verify_client, verify_server and require_client_cert for mutual authentication and peer certificate checks. The tutorial's method=sslv23 and its tip for disabling server verification are lab conveniences, not production settings.

In Kamailio, the tls module provides TLS, enabled with enable_tls=yes. Its tls_method accepts TLSv1.2+ and TLSv1.3+ among others, and the documentation lists TLSv1 as the default, so set it explicitly. verify_certificate and require_certificate control peer checks; verification "will always fail if the ca_list is empty."

modparam("tls", "tls_method", "TLSv1.2+")
modparam("tls", "verify_certificate", 1)
modparam("tls", "require_certificate", 1)

Step 2: check the TLS listener from outside

Use OpenSSL's s_client to see what your own SIP TLS listener negotiates and which certificate it presents. The OpenSSL manual page notes that s_client is a test tool that will continue after verification errors unless you pass -verify_return_error.

# Summary of protocol, cipher and verification result
openssl s_client -connect pbx.example.com:5061 -servername pbx.example.com -verify_return_error -brief

# Confirm TLS 1.2 and TLS 1.3 work
openssl s_client -connect pbx.example.com:5061 -servername pbx.example.com -tls1_2 -brief
openssl s_client -connect pbx.example.com:5061 -servername pbx.example.com -tls1_3 -brief

# Confirm TLS 1.1 is refused (the handshake should fail)
openssl s_client -connect pbx.example.com:5061 -servername pbx.example.com -tls1_1 -brief

# Show the full chain the server sends
openssl s_client -connect pbx.example.com:5061 -servername pbx.example.com -showcerts

Whether -tls1_1 can be attempted depends on your OpenSSL build and security level, so read the error: a client side refusal proves nothing about the server.

On Kamailio, the TLS module exports RPC commands you can run with kamcmd. The documentation describes tls.options as listing the current TLS configuration, tls.list as listing details about all active TLS connections, and tls.info as a short summary of maximum and open connections and write queue size.

kamcmd tls.options
kamcmd tls.list
kamcmd tls.info

Step 3: require SRTP and confirm it is negotiated

In Asterisk, media encryption is per endpoint. The res_pjsip reference documents media_encryption with three values: no, sdes and dtls. Use sdes only together with TLS signalling, and leave media_encryption_optimistic at its default of no so a call fails rather than silently dropping to cleartext.

[alice]
type=endpoint
aors=alice
auth=alice
context=internal-phones
disallow=all
allow=g722
media_encryption=sdes

For WebRTC style endpoints, the documented route is media_encryption=dtls with options such as dtls_verify, dtls_setup, dtls_fingerprint and dtls_auto_generate_cert.

To confirm what was actually negotiated, the Asterisk PJSIP troubleshooting guide recommends turning on SIP message logging at the CLI:

core set verbose 4
pjsip set logger on

Place a test call and read the SDP in the INVITE and the 200 OK. You want RTP/SAVP or UDP/TLS/RTP/SAVP on the m= line, a=crypto (SDES) or a=fingerprint (DTLS-SRTP) attributes, and the INVITE arriving on your TLS transport rather than UDP 5060. Turn the logger off when done, because these logs contain media keys.

Step 4: lock down registration and authentication

• Give every endpoint its own username and a long random password in a type=auth section with auth_type=userpass; the Secure Calling tutorial's sample password literally says to use a better one.
• Confirm each endpoint is matched and challenged as expected. The troubleshooting guide uses pjsip show endpoints to list loaded endpoints and pjsip show endpoint with a name to show its identify, auth and AoR details. An endpoint with no auth section is not being challenged.

pjsip show endpoints
pjsip show endpoint alice
pjsip show aor alice

• Leave allow_unauthenticated_options off unless a trunk provider requires it, given the enumeration warning in the documentation.
• Be deliberate about identify_by, which defaults to username,ip. Trunks identified by IP alone should only accept traffic from the provider's documented addresses.
• Prefer SHA-256 Digest (RFC 8760) where both sides support it.

Step 5: design the dialplan so a compromised extension cannot run up a bill

Use separate contexts for internal phones, inbound trunk calls and outbound routes, as the Asterisk dialplan guidance describes; keep toll routes out of default and out of anything an inbound trunk can reach; limit international and premium prefixes to extensions that need them; and remove the sample demo contexts. Carrier spend limits and fraud alerts are the backstop.

Step 6: limit exposure

The Asterisk Network Security page says sample configurations open several VoIP ports, and advises checking channel configuration files for ports and addresses, protecting the manager interface with SSH or a VPN, and using permit and deny ACLs. Beyond that:

• Do not expose UDP 5060 to the internet if every phone and trunk can use TLS on 5061.
• Restrict the RTP port range in your firewall to the PBX or session border controller, not to every phone.
• Disable SIP ALG on routers in front of the PBX and handle NAT in the PBX or session border controller instead.
• Send authentication failures from the PBX to your log pipeline and alert on bursts of them; they are the earliest sign that someone is guessing passwords.

Step 7: keep the stack itself current

SIP and RTP security depends on the software that parses them: the PBX, its SIP stack and the SRTP and TLS libraries underneath. Asterisk links its security vulnerability information from its documentation site. Track the versions you run, including inside container images, and patch on a schedule.

SIP trunking vs WebRTC vs proprietary UC protocols: when to use which

Most deployments mix several of these, and the security work is in the joins: the WebRTC gateway, the SBC facing the carrier, and the forgotten analog adapter that still registers with a short password.

Common mistakes

• Encrypting signalling and assuming media is encrypted. TLS on 5061 does nothing for RTP. Check the m= line profile in the negotiated SDP.
• SDES over cleartext SIP. A lock icon with the key sent in the open.
• Optimistic encryption left on. Silent fallback to RTP hides that protection is missing.
• Leaving the TLS method at a library default. Both the Asterisk and Kamailio documentation list TLS 1.0 as the default method, which RFC 8996 deprecated in 2021.
• Disabling certificate verification to fix a name mismatch, then forgetting it. That removes the protection against server impersonation.
• Default or shared registration passwords. Public SIP ports are probed constantly.
• Toll routes in reachable contexts. Any outbound route reachable from an inbound trunk or unauthenticated context invites toll fraud.
• Trusting the From header or display name. It is the sender's assertion; only STIR offers cryptographic evidence, and only between carriers.
• Leaving SIP ALG on. It rewrites signalling and breaks calls in hard to diagnose ways.
• Exposed management interfaces and debug logs. Keep the Asterisk manager interface behind a VPN or SSH, and turn full SIP logging off after troubleshooting, since it captures SDES keys.

FAQ

What port does SIP use?

IANA registers SIP on port 5060 for UDP, TCP and SCTP, and SIPS (SIP over TLS) on port 5061. RFC 3261 uses those defaults. Many providers and PBXs use other ports by configuration, so check what your own system binds rather than assuming.

What port does RTP use?

RTP has no single fixed port. Each side announces a port in SDP for every call, usually from a configured range. RFC 3550 recommends an even port for RTP and the next odd port for RTCP, and RFC 5761 allows both on one port. IANA lists 5004 and 5005 for applications that want a default pair.

Is SIP encrypted?

Not by default. SIP on port 5060 is plain text. SIP over TLS, usually on 5061, encrypts each hop, but every proxy still sees the full message, and media needs SRTP separately.

What is the difference between SIP and RTP?

SIP sets up, changes and ends calls; it carries no voice. RTP carries the voice and video once SIP and SDP have agreed on codecs, addresses and ports. They usually take different network paths and need separate protection.

What is the difference between SRTP and DTLS-SRTP?

SRTP is the encryption and authentication format for media. DTLS-SRTP is one way to agree on SRTP keys, by running a DTLS handshake between the endpoints on the media path. The other common way, SDES, puts keys inside SDP and relies on SIP being encrypted.

What is STIR/SHAKEN?

STIR (RFC 8224, 8225 and 8226) signs the calling number in a SIP request with a certificate proving authority over that number. SHAKEN is the industry profile US carriers use, with attestation levels A, B and C (RFC 8588). The FCC required it in the IP parts of US voice networks by June 30, 2021.

What is SIP ALG and should I disable it?

A router or firewall feature that rewrites addresses inside SIP messages to cross NAT. It often causes one way audio and dropped registrations. Most PBX deployments work better with it disabled and NAT handled by the PBX or a session border controller.

SIP vs WebRTC: which is more secure?

WebRTC mandates DTLS-SRTP and is usually signalled over HTTPS or secure WebSocket, so its baseline is higher. SIP can match it with TLS and SRTP, but encryption is optional and often off. At a gateway between them, the call is only as protected as the weaker side.

How do I know if my SIP calls are using SRTP?

Look at the negotiated SDP. With Asterisk, pjsip set logger on shows the INVITE and 200 OK; an m= line with RTP/SAVP or UDP/TLS/RTP/SAVP and a=crypto or a=fingerprint attributes means SRTP was negotiated. RTP/AVP means plain RTP.

Where Safeguard fits

Safeguard does not inspect, record or filter SIP or RTP traffic, and it does not configure PBXs, session border controllers or firewalls. The honest connection is the software that implements these protocols.

SIP stacks and SRTP, TLS, DTLS and codec libraries are open source components inside PBXs, softphones and the container images that run them. Safeguard's software composition analysis, generally available, builds a full transitive dependency inventory of those components, and SBOM generation and analysis, also generally available, records them in SPDX or CycloneDX. Vulnerability management with EPSS and KEV enrichment and reachability analysis, both generally available, rank which library findings your code actually calls. Container visibility and scanning, generally available as part of ESSCM, shows which media and TLS libraries sit inside each PBX or gateway image, though not a hardware phone's firmware, which still has to come from its vendor. For the HTTP and API interfaces you own and verify, such as a PBX admin portal or a provisioning API, Safeguard's first party DAST, generally available, tests the running service. Policies and gates, generally available, can stop a build that pulls in a known vulnerable TLS or SRTP library. See using SBOMs to find affected products fast for the workflow when a SIP or media library advisory lands, and the NIST 800-53 SC-19 VoIP control post covers how auditors frame VoIP controls.

Fix it without waiting for upstream

VoIP security bugs usually live in a library or daemon your system depends on: a SIP parser, an SRTP implementation, a DTLS or TLS library, or a codec. When that code is open source and ships inside software you build, you do not have to wait for the next release cycle.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency and remediation workflows, not call monitoring or PBX configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image of a PBX, a WebRTC gateway or a softphone build you maintain, the same scan lists the SIP, SRTP and TLS libraries inside it with their versions and known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a SIP or WebRTC library in a calling application you build.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects ship a particular version of a TLS or media library and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 3261: SIP: Session Initiation Protocol, June 2002
• RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP), June 2002
• RFC 8866: SDP: Session Description Protocol, January 2021
• RFC 3550: RTP: A Transport Protocol for Real-Time Applications, July 2003
• RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control, July 2003
• RFC 3711: The Secure Real-time Transport Protocol (SRTP), March 2004
• RFC 4568: SDP Security Descriptions for Media Streams, July 2006
• RFC 5763: Framework for Establishing an SRTP Security Context Using DTLS, May 2010
• RFC 5764: DTLS Extension to Establish Keys for SRTP, May 2010
• RFC 5630: The Use of the SIPS URI Scheme in SIP, October 2009
• RFC 3325: Private Extensions to SIP for Asserted Identity within Trusted Networks, November 2002
• RFC 7118: The WebSocket Protocol as a Transport for SIP, January 2014
• RFC 8224: Authenticated Identity Management in SIP, February 2018
• RFC 8225: PASSporT: Personal Assertion Token, February 2018
• RFC 8226: Secure Telephone Identity Credentials: Certificates, February 2018
• RFC 8588: PASSporT Extension for SHAKEN, May 2019
• RFC 8760: SIP Digest Access Authentication Scheme, March 2020
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1, March 2021
• RFC Editor metadata for RFC 3261 (publication date and updating documents)
• IANA: Session Initiation Protocol (SIP) Parameters
• IANA: Service Name and Transport Protocol Port Number Registry
• FCC 20-42: Call Authentication Trust Anchor, Report and Order, March 31, 2020
• Asterisk documentation: Secure Calling Tutorial
• Asterisk documentation: res_pjsip module configuration (Asterisk 22)
• Asterisk documentation: Asterisk PJSIP Troubleshooting Guide
• Asterisk documentation: Dialplan Security
• Asterisk documentation: Network Security
• Kamailio documentation: TLS module
• OpenSSL 3.0 manual: openssl-s_client

Last reviewed: 23 October 2026. PBX defaults and regulatory deadlines change; check the documentation for the version you run and your regulator's current orders.