Bypassing VOIP ISP block in Asterisk
This is an article I shared before on my LinkedIn profile a while ago, but I decided to re-share it on my blog with minor changes. You can find the LinkedIn article here.
Alice can now start sending media (voice and/or video) to Bob and receiving media from Bob.
I was a new guy to Asterisk. I set up my users, my dialplan and everything seemed fine, until I wanted to let my users connect to my server from the internet. I set up port forwarding on my router, but when I tried to connect from an internet device, nothing would happen.
Living in Egypt, I discovered that my ISP is blocking SIP. Attempting to use SIP over UDP port 5060 (which is the default) always resulted in failure. I decided to change the port number, tried again but to no avail. I also tried SIP over a random TCP port but it still did not work. I concluded that my ISP blocks SIP using deep packet inspection. So I did some research, read some RFCs (Request for comments) and I will share here the concepts I learnt and how they helped me get over these restrictions.
Please know that this article is not a how-to step by step guide. It will only explain the concepts you need to solve this problem. I am currently (as of this article) NOT a professional and only sharing this to document my trials. To understand what is written here, one must have a basic understanding of networking, NAT and encryption.
Brief Review of a normal SIP call
A call consists of a signal and the media, the signal and the media are 2 completely separate things that just happen to work together in our case.
For Alice to call Bob, Alice crafts a SIP invite message (signal) and sends it to Asterisk. Asterisk then forwards this signal to Bob. Bob's phone starts ringing and he answers the call. SDP takes place which is basically how everyone agrees on how this call will be running; which ports they will use for sending media, which codecs will they use and so on. After this agreement is made, Alice should now have a port for sending media to Bob and another port for receiving media from Bob and the same goes for Bob.
|Image from https://asterisktechs.wordpress.com|
How ISPs block calls
After countless tests, I concluded that, ISPs block the signal and not the media. Afterall, if Bob cannot know that Alice is calling him, then no call could take place. Moreover, blocking the media is more troublesome. This is because it can take countless forms and can use any random port; it is difficult to identify.
How to deliver the signal
By encrypting the signal that gets sent to Bob so that no-one can determine it is actually a SIP invite message. This can be accomplished by using SIP over TLS operating at a random port number. Now the signalling becomes encrypted, the ISP (or any eavsdropper) cannot determine whether its a SIP message or Facebook or YouTube or anything! This way, we can guarantee that the signal will arrive to its destination.
How to deliver the media
Now that the signal can arrive at its destination, the caller and the called can agree on how to exchange media but this is not enough. Most internet users are behind a NAT device one way or the other, specially mobile internet users. When NAT is involved, no internet address can communicate with an inside device unless the inside device communicated with it first. This is a problem, cause when we described the operation of a normal call, every party allocated a UDP port for sending voice and another UDP port for receiving voice. In order to traverse NAT, one must use the same port for sending and receiving.
Configuring Asterisk to use Symmetric RTP makes the user send and receive their data from the same UDP port. Now when Alice sends her voice from this port to Bob, Alice's port number gets recorded in the NAT table. When Bob sends his voice to Alice, then Alice's NAT will
know where to send Bob's voice because the port number she is using is already recorded in the NAT table.
In my setup, disabling SIP re-invites solved a lot of headaches, because I only had to worry about getting the data from the user to Asterisk and from Asterisk to the user. However, I plan to try again re-invites as soon as I am able.
If your only goal is getting calls to work, then there is no need to encrypt the media considering that it is not blocked anyway. The more encryption you do, the larger the overhead and the lesser the overall call quality. You will also have to do more configuration to get it to work correctly. Moreover, if the eavesdropper did not see the signal then it cannot quite be sure which codec you are using, it cannot even determine if this is voice RTP media or just random UDP messages.
I hope this article was of use to you. I am no Asterisk professional but I do this because I enjoy doing it ^_^. If you are like me and could not find the help you needed on the internet, be sure to follow my blog because I do not intend to share the regular stuff you find everywhere.
Post a Comment