SIP port guide: VoIP signaling on ports 5060 and 5061

SIP coordinates communication sessions. A SIP user agent, phone, PBX, trunk, or softphone sends messages such as REGISTER, INVITE, ACK, BYE, OPTIONS, and CANCEL to establish and manage calls. Those messages describe who is calling, where the endpoint can be reached, which codecs are available, and how media should be exchanged.

SIP is only the signaling layer. Once a call is negotiated, audio or video usually flows over RTP or secure RTP on separate UDP ports. That separation is why a SIP device can appear online while the call has one-way audio, no audio, or media that drops after a few seconds.

Port 5060 is the conventional SIP signaling port. It is commonly used with UDP, but SIP can also run over TCP on 5060 when the platform requires reliable transport or larger messages. Many phones, PBXs, and SIP trunks still use UDP 5060 by default.

Port 5061 is commonly used for SIP over TLS. TLS protects signaling metadata in transit and helps clients verify the server they are talking to. It does not automatically encrypt the media stream; voice media needs SRTP or another media-layer protection when privacy is required.

SIP tells endpoints how to start, change, and end a call. RTP carries the actual audio or video packets after the endpoints agree on codecs and addresses. RTP port ranges vary by PBX, provider, phone system, SBC, or cloud voice platform, so there is no single universal RTP port.

Common examples include UDP ranges such as 10000-20000, 16384-32767, or provider-specific ranges. Open only the ranges required by your voice platform, and document whether traffic must flow from phones to PBX, PBX to provider, or both directions.

Open SIP ports only where a trusted phone, PBX, SIP trunk provider, session border controller, or voice gateway needs to exchange signaling. Typical deployments allow phones to reach an internal PBX, a PBX to reach a SIP trunk, or an SBC to mediate public VoIP traffic.

Do not expose SIP broadly just because calls need to work remotely. Public SIP endpoints attract scanners, registration attempts, toll fraud, extension enumeration, and password attacks. Prefer VPN, private peering, provider allowlists, SBCs, or tightly scoped source networks.

Start by identifying the exact voice path. Confirm which device owns signaling, which side initiates registration, which RTP range the platform uses, and whether TLS or SRTP is required. Then allow SIP 5060 or 5061 only between the expected sources and destinations.

For NAT environments, configure the PBX or SBC with the correct public address, local networks, external signaling address, and external media address. Avoid relying blindly on SIP ALG because it can rewrite packets incorrectly and create intermittent registration or audio failures.

A basic port check can confirm whether a TCP listener such as SIP over TLS on 5061 is reachable. For UDP 5060, use SIP-aware checks where possible because UDP does not behave like a TCP connection. Tools such as sipsak, sipvicious in controlled tests, provider diagnostics, PBX logs, and packet captures can show whether SIP messages are reaching the right endpoint.

After signaling works, place a real test call and verify media. Check two-way audio, call setup time, codec negotiation, RTP source and destination addresses, NAT translations, firewall counters, and whether packets continue after the first few seconds.

If a phone cannot register, check DNS, outbound firewall rules, credentials, realm, transport mode, TLS certificates, provider allowlists, and whether the PBX or proxy is listening on the expected SIP port. Registration failures are often authentication or policy problems, not only port problems.

If calls connect but have no audio, inspect RTP ranges, NAT addresses in SDP, SIP ALG, symmetric RTP settings, provider media IP ranges, and firewall direction. If audio works one way only, one side can usually send RTP while the other side cannot receive it.

Limit SIP exposure to known providers, branch offices, VPN clients, SBCs, or private networks. Disable unused extensions, require strong passwords or certificate-based authentication where supported, rate-limit registration attempts, and alert on failed registrations or unexpected international dialing.

Use SIP over TLS and SRTP when supported, but remember that encryption does not replace access control. Keep PBX, SBC, phone firmware, and voice gateways patched, review call detail records for fraud, and separate voice management interfaces from public signaling paths.