Many people have the impression that if they use secure transports, such as TLS (for SIP and Jabber) or SRTP for audio/video, their privacy problems are solved.

This is not the case. Let's take a deeper look.

SIP message privacy

A typical SIP INVITE message is used to set up a session/call. Let's see an example of this message, taken from RFC 3261, the official standard for SIP:

INVITE SIP/2.0 Via: SIP/2.0/UDP;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob From: Alice <>;tag=1928301774 Call-ID: CSeq: 314159 INVITE Contact: <> Content-Type: application/sdp User-Agent: Lumicall 1.8.1 (Samsung Galaxy Tab)

That message is sent when you make a call. When you receive a call - and even before you answer it - your user agent (SIP device or software) sends a response that looks very similar to the INVITE.

Sending the INVITE and response across TLS connections ensures that all these details are encrypted. Encryption gives certainty that no arbitrary middleman (such as the government or phone company) can inspect these messages.

However, it is worth taking a moment to reflect on the fact that all these details are visible to the person you are calling. In fact, these details are even visible to a person trying to call you, even if you don't accept the call. Let's look at some of them more closely:


Each user agent constructs the Call-ID header in a slightly different way. If you have multiple SIP addresses and/or domains, it is quite possible that a user agent may construct such a header containing a domain other than the identity you are using for the call. The Call-ID could also include your IP address or other details that could locate you.

Contact: <>

Notice that the Contact header contains a specific hostname or IP address where the user is currently located. One of these headers is sent from both ends of a call.

User-Agent: Lumicall 1.8.1 (Samsung Galaxy Tab)

The User-Agent header, much like the equivalent in HTTP or email, allows the peer to see exactly which software and version you are using. In this case, it is the Lumicall mobile SIP client on a Samsung Galaxy Tab device. Fortunately Lumicall is open source and you can patch it to hide this information.

ICE negotiation and privacy

SIP and (S)RTP are surprisingly bad at traversing NAT and firewalls. To solve this problem, the ICE protocol (RFC 5245) was created.

By it's very nature, the ICE protocol explores all the possible ways that you can exchange media streams with the person you are trying to call (or the person trying to call you). This process of exploration takes place silently before you even answer the phone.

Let's look at the ICE data enclosed in a typical INVITE packet, embedded in the SDP body (taken from an example in RFC 5245):

a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 8998 typ host a=candidate:2 1 UDP 1694498815 45664 typ srflx raddr rport 8998

In this case, the ICE data is contained in the candidate attributes. Each IP address of the user agent is listed and given to the peer. This can give the peer a very interesting perspective about your internal network topology and your location.

The threats

Based on the information above, it is clear that someone who simply sends you a missed call can gather all of the following details:

  • Your type of softphone and/or phone hardware
  • Domains you are associated with (other than the domain in your publicly advertised SIP address)
  • All of the IP addresses on your device, and possibly some perspective on your network topology
  • Even if you are using TOR, your real location may be revealed

The defence

It is not the end of the world for VoIP however. Consider some of the following options:

  • An open source user agent can be modified to send only the most essential details in the packet
  • A SIP back-to-back user agent (B2BUA) together with a media relay can completely hide your real location (a SIP proxy, on the other hand, can NOT remove some of the identifying details from a SIP packet)
  • An ICE implementation can be modified to ONLY work through a TURN relay, and withhold all candidate attributes representing private addresses.