I recently wanted to check out a couple of things concerning the SIP client on my Nokia phone when I stumbled over something I was not prepared for. In theory, the voice path between two SIP devices is supposed to be direct, i.e. one device sends the speech packets directly to the other device. In my case however, the SIP INVITE messages were always changed by the SIP Proxy to route the speech path packets through a media proxy in the network. I was quite perplexed.
Why would my SIP provider do that? Is someone spying on me? Is the government taping into my calls? Yes, maybe I am a bit paranoid, but this is not the way it is supposed to be. I ran a lot of different scenarios to see if the behavior changed like using different accounts, different SIP clients and different network configurations. However, no matter what I did, the INVITE message sent out and the INVITE message received on the other end were different and the speech path was relayed via a media proxy of my provider.
The Explanation
In the end, I contacted my SIP provider and asked them what was going on, not really expecting that I would get a qualified response. To my big surprise, I got a competent answer from one of the engineers explaining that they've had lots of trouble with Network Address Translation (NAT) in the past and have thus decided to route any call through one of their servers as soon as a NAT was detected in the transmission path. Calls from SIP clients without NAT in the way, he said, would not be routed that way. O.k. I thought, then let's test that, I believe it when I see it.
It's not that simple to set something up without a NAT in the IPv4 address space these days, specifically not behind DSL lines. However, with some VPN tunnels I finally managed to get a setup in which both SIP clients were not NATed. And sure enough, no media proxy in the speech path anymore. O.k. great, so I am not spied on, what a relief.
Open Questions
However, a couple of questions remain. Why all this fuss about "Simple Traversal of UDP over NATs" (STUN) when in the end the SIP proxy detects the NAT situation and deploys a countermeasure without the help of STUN? Is it really that unreliable? Also, sending practically all SIP to SIP calls through a media proxy must require a lot of resources in terms of bandwidth and computing power from my SIP provider for which he is not reimbursed since SIP to SIP calls are free of charge.
Lawful Intercept
This brings me to lawful interception of VoIP calls. Depending on the country you live in there are more or less strict laws in place these days that require that VoIP providers must be able to target all calls going through their system, which obviously includes direct SIP to SIP calls. The only way to do that, without the target knowing that somebody is listening in, is to route all calls through a media proxy. Bitcom, the German association representing the Internet industry is pushing very hard against this, saying that it is not practicable to proxy every call. Seems that that is not quite in line with what is already done anyway to get around NAT issues. A lot of hot air for nothing?
Summary
One way or the other, I don't like my calls being sent through a media proxy no matter for what reason. It's time IPv6 is finally marching in to rid us of NATs. If by the time law mandates commercial providers to media proxying all calls it might be time for my own Asterisk SIP server at home so at least "internal" calls are not proxied. Also, such a solution would provide for security and encryption of the call, both not supported by my SIP provider today.
But then, for those who really want to be sure nobody is listening in, they have to buy a pair of these or these.
STUN does not work with Symmetric NATs, in which case, TURN has to be used. TURN means to use media proxies
To my surprise also, after all the fuss with all that fancy NAT helping mechanisms, some that made it even into standards, this solution is the most effective one. Sure, I bet it’s not perfect, but so far it works just fine.
And don’t think that your streams are not actually saved somewhere just because they said so. When they redirect them, it’s as easy as setting a flag, in most of the RTP proxy solutions. When not, don’t assume that others can’t hear you – just capture your traffic with Wireshark, let it do the “magic” and then hear your conversation.
So if you want privacy, use encryption on RTP media.
HiMartin,
I discovered the same thing with my Australian SIP provider when calling within their network (from NZ to Peru). The RTP routes via Australia…
The reason why will be the need to Lawfully Intercept. Having worked with these requirements before, one of them is not to do anything visibly different (from the customer perspective) when the customer is subject to interception.
Proxying only intercepted traffic would violate this requirement, and so we have this perpetual inefficiency.
I suspect the same issue will crop up again with Roaming IMS in the future; if Governments and Carriers decide that calls while roaming should be interceptable (and MO calls are not today) then those packet calls will need to be routed home. In which case we might as well give up and keep routing everything through the home GGSNs…