Secure Calls: How Your Company's Conversations Are Protected

Why can a call over the internet be overheard?

When your company uses IP telephony (also called VoIP, Voice over Internet Protocol), every conversation is split into thousands of data packets that travel across the network, just like an email or a web page. That's the big advantage: you don't need phone wiring, you can have extensions in any city and you pay much less.

The problem is that, by default, many of those packets travel in clear text, meaning with no protection at all. Anyone who manages to sit somewhere along the way (a public Wi-Fi network, a compromised computer inside your office, a misconfigured link) could see who you're talking to and, in the worst case, rebuild the audio of the call. The U.S. National Institute of Standards and Technology (NIST) warned about this in its SP 800-58 guide on VoIP security: voice over data networks inherits the risks of those networks and needs its own controls.

The good news is that there are open standards, proven over many years, to close that door. You just have to turn them on and configure them properly.

Two things to protect: the envelope and the letter

A call over the internet has two parts, and each is protected differently. Think of a letter you send by mail:

• The envelope is the signaling: who is calling, whom, when the call starts and when it ends. In IP telephony this is handled by the SIP protocol (Session Initiation Protocol), defined by the IETF (the body that creates internet standards) in RFC 3261.
• The letter is the voice: the audio of what you and your customer say. That audio travels over another protocol called RTP (Real-time Transport Protocol).

If you only protect the envelope, someone could still read the letter. If you only protect the letter, they'll know whom you're writing to and when. That's why a truly secure call encrypts both.

SIP over TLS: the sealed envelope

TLS (Transport Layer Security) is the same technology that protects your online banking when you see the padlock in your browser. According to the IETF, its goal is to prevent a third party from eavesdropping on, altering or forging messages. The current version is TLS 1.3, published in RFC 8446 and recently revised in RFC 9846; the previous version, TLS 1.2, was described in RFC 5246.

When SIP signaling travels inside TLS, it's like putting the envelope in a safe that only the sender and the recipient can open. TLS also uses digital certificates so each end can verify it's talking to the right server and not an impostor. RFC 3261 itself provides for this with the SIPS scheme, which requires TLS-encrypted transport on the leg toward the destination domain.

SRTP: the voice in a language only the two ends understand

SRTP (Secure Real-time Transport Protocol, the secure version of RTP) is defined in RFC 3711. It does three important things with the voice:

1. Confidentiality: it encrypts the audio, by default with the AES algorithm, so if someone intercepts the packets they only get meaningless noise.
2. Message authentication: it makes it possible to detect whether someone modified a packet along the way.
3. Replay protection: it rejects packets an attacker tries to resend to disrupt the call.

One key detail: SRTP doesn't distribute the keys on its own; that's done by external mechanisms agreed on during signaling. That's why SRTP and TLS work best together: if the envelope is open, the voice keys could be exposed.

The most common attacks on IP telephony

You don't need to be an expert to understand the risks. RFC 3261 and the NIST guide describe these scenarios, among others:

• Eavesdropping (interception): someone captures unencrypted voice traffic and rebuilds the conversation.
• Impersonation: a third party poses as a legitimate server or another user, or spoofs the number shown on screen to fool your team.
• SIP credential theft and registration hijacking: if an attacker gets an extension's username and password, they can register in its place, receive its calls or use your line to make calls you end up paying for.
• Call teardown or tampering: fake signaling messages can be used to try to hang up calls in progress or alter their content.
• Denial of service: flooding your system with messages or calls to exhaust its capacity. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) publishes specific guidance on telephony denial of service (TDoS), in which floods of automated calls overwhelm phone lines.

For example: an extension with a weak password

Imagine a distribution company in Medellín with 40 extensions on a cloud phone system. To speed up installation, every extension was given a short password similar to the extension number, and the server accepts connections from any country.

One Friday night, someone tries combinations automatically, guesses one extension's password and registers it from somewhere else. Over the weekend they use that line to make international calls. On Monday, the company discovers the charges and also realizes that the sales calls from that extension may have been diverted.

What would have prevented it? Long, unique passwords, a firewall that only accepts connections from the countries and networks where the company operates, automatic lockout after several failed attempts, spending limits and alerts for unusual traffic. None of these measures is expensive; what's expensive is not having them.

Best practices to protect your company's calls

• Encrypt everything you can: SIP over TLS for signaling and SRTP for voice, on desk phones, softphones and trunks.
• Strong, unique passwords: each extension with its own long password, never the factory default or one based on the number. If your platform allows it, turn on multi-factor authentication for admin portals, as MinTIC recommends for business tools.
• Firewall and access control: open only the ports you need and restrict which networks can connect. NIST recommends using VoIP-aware firewalls or session border controllers (SBC, Session Border Controller).
• Stay up to date: apply security patches to the phone system, phones and servers as soon as the vendor releases them.
• Separate the voice network: NIST suggests keeping voice and data on logically separate networks (for example, with VLANs, virtual networks over the same cabling), so an infected computer has no direct access to the phones.
• Protected remote administration: access management only through encrypted channels such as a VPN (virtual private network) or SSH.
• Constant monitoring: review logs, failed authentication attempts and unusual call patterns, and set up alerts and spending caps.

What to ask your phone provider

Before signing up for (or renewing) a cloud PBX or business mobile service, ask these questions and request concrete answers:

1. Do you support SIP over TLS and SRTP on extensions and trunks? Are they enabled by default?
2. Which TLS version do you use and how do you manage certificates?
3. How do you protect SIP credentials and what happens after several failed attempts?
4. Can I restrict by country, network or IP address where my extensions register from?
5. Do you have 24/7 monitoring, fraud alerts and configurable spending limits?
6. How often do you update your platform and how do you communicate incidents?
7. Who operates the infrastructure: your own team or a third party you resell?

If the provider hesitates or answers in generalities, that's a sign to keep looking. It's also worth reviewing the industry's regulatory framework in our regulations section.

Open source speaks the language of security too

Much of the world's IP telephony runs on open-source software, and the most widely used tools support these standards. Kamailio, a SIP server widely used by carriers, includes a TLS module that supports TLS 1.3. Asterisk documents step by step how to combine TLS for signaling and SRTP for voice. FreeSWITCH also offers SIP over TLS configuration and secure media with SRTP.

The fact that the software supports it doesn't mean it comes turned on: what makes the difference is the team that configures, updates and monitors it every day. At 19 80 TIC Cloud, our team of engineers runs its own IP telephony platform, so these security decisions are made and reviewed in-house.