I’ve just published a new article which looks at the topic of transport protocol transcoding. This builds on some of my earlier articles that looked at using OpenSIPS as a WebRTC-to-SIP gateway and looked at how you can fix different headers in the SIP requests and responses.
As a retirement/lockdown project, I have written a series of articles exploring when and how you should fix the address values sent in some SIP headers. These articles will be ideal for beginners to use as a tutorial explaining some of the tricky basics of the SIP protocol, but also for more experienced VoIP solution designers who want to understand how OpenSIPS handles tricky problems with NAT and how it conforms to International SIP standards.
They say it’s good to learn something new as an antidote to lockdown blues, so I hope these articles will give your brain a good workout:
I have just published a new post on my wiki site which examines how Contact, Record-Route and Route headers are used in what is known as “loose routing”. This is a somewhat fundamental part of understanding how SIP Proxies work and if you don’t get this, then you’ll probably find it very difficult to understand what’s going on in a SIP trace or packet capture. So if you don’t already have this topic under your belt, go and take a look at my latest tutorial article. Just click on this link:
…and, if you find it helpful, please remember to use the Like or Recommended buttons that you’ll find at the end and start of the post.
While testing a WebRTC application recently, I noticed some unexpected delays in the execution of a series of lines in my OpenSIPS control script. For OpenSIPS to behave properly it is essential that the child threads don’t get blocked and that the lines in the script are executed at speed. Seeing a delay of several seconds during handling of a BYE request (i.e. hangup at one end terminating the call) was therefore quite concerning.
Initially, I believed the delay must be linked to DNS queries in my NAT detection routines, but as I looked closer it became clear that it was in fact arising from very slow transmission of large messages over UDP. The UDP connection was from OpenSIPS on one server to rtpengine on another. It is used to send control commands – ‘offer’, ‘answer’ and ‘delete’ – one way and then receive responses back in the reverse direction. The commands and responses can vary in size quite a lot because they may include a copy of the SDP or a report on the quality of a call.
The two servers in question were Virtual Private Servers provided by two different Internet hosting companies. Using tcpdump to capture and wireshark to analyse the network traffic, it was possible to see that small command messages were transmitted very fast while large messages such as the response to the ‘delete’ command, were delayed by up to 5 seconds. Searching on the web, it looked like the problem was linked to fragmentation of the network packets. UDP datagrams whose size exceeded the Maximum Transmission Unit (MTU) of 1500 bytes were being broken into smaller fragments, transmitted over the Internet and reassembled at the far end. For some reason that I was not able to identify, the fragmented packets were being given very low priority as they traversed the networks within or between the two hosting providers.
It seemed unlikely that I would be able to get the hosting companies to investigate so instead I searched for a tunnelling solution. I thought that, if I could somehow transmit the UDP over a TCP connection, then it would no longer be delayed by some obstinate piece of intermediate network equipment. After a lot of Google searches and a few unsuccessful tests with free UDP tunnelling utilities, I discovered a tool called socat. This utility is installable as a yum package in CentOS, it is well documented and it was fairly easy to find some working examples not dissimilar to what I wanted to do.
The commands I used, which worked first time, were as follows. On the rtpengine host server:
socat TCP4-LISTEN:2223,fork UDP4:127.0.0.1:2223
On the OpenSIPS host server:
socat UDP4-LISTEN:2223,fork TCP4:<rtpengine-address>:2223
On the rtpengine host server, I had to make rtpengine listen for ng commands on the localhost address instead of the published Internet IP. I also had to add a rule to iptables to allow connections over TCP to port 2223 from the OpenSIPS server. On the OpenSIPS server, I just had to change the address specified in the rtpengine module parameters from the remote address of the rtpengine host server, to 127.0.0.1.
I’m happy to say that the results were brilliant. All the horrible delays vanished and, so far, I have seen no problems. All that is left now is to configure the servers such that socat runs as a daemon or is otherwise automatically started before OpenSIPS starts.
The same solution could be applied to other UDP connections, either as a way to overcome the problems of datagram fragmentation or possibly as a way to get through awkward NAT routers or firewalls that don’t handle UDP very well. I think I will be using socat again, possibly quite soon.
The Covid-19 crisis has led to an explosion in working from home. Most large companies already had solutions in place, but many smaller companies will have been forced to look for quick-fix solutions. In that situation it may be tempting to rig up an Asterisk based telephony solution perhaps based around FreePBX. It’s a fantastic product, but please be aware that there are risks if it is not configured correctly.
If you have just set up a FreePBX or other Asterisk based telephony solution, you will probably find it useful to read the three part article I wrote back in 2010. It’s old, but I just read it through and almost all of it is all still relevant. Here’s a link to part 2 which is full of tips to improve the security on your VoIP phone system:
Earlier this year, I was pleased to be allowed to present a paper at the 2019 OpenSIPS Summit entitled ‘Docker, Clustering, Scalability – A case study’
You can watch my presentation on YouTube:
At Smartvox, we have access to log reports from a number of different SIP Proxy servers. The information available from these reports helps give some insight into the most common SIP requests being sent by hackers to detect and probe your VoIP servers.
Here’s some common characteristics of malicious INVITE requests that have been seen recently on Smartvox servers. Based on these characteristics, you might be able to configure your firewall, SBC or OpenSIPS proxy to cut out the unwanted requests as soon as they are received:
From header contains one of the following:
The From name (also called the display name) is “sipvicious”, “Caller”, “MAYET”, “Simple SIP” or “0123456789”
Another easy and reliable target for identifying malicious requests is to check for the User-Agent header being set to “friendly-scanner”.
It is becoming increasingly difficult to filter out malicious requests simply based on the User-Agent header. Recently I have seen many unwanted requests using “FPBX” or “FreePBX 1.8” which could too easily be from a legitimate customer. However, there may still be some benefit in triggering an alarm on your system or simply by blocking INVITE requests where the User-Agent header contains one of the following strings:
- SIP Call
- SimpleSIP V4.3
In addition, the following strings are often found at the start of the User-Agent value, but may have long and varying character strings appended to them. They should therefore be checked using a sub-string match or regular expression:
- Z 3.14
If your VoIP system, firewall or SBC doesn’t allow you to block this type of probing request, then it is much more likely to be hit by high volumes of malicious SIP requests from hackers looking for a weakness or vulnerability so they can use dial-through fraud on your system. Consider using a Smartvox OpenSIPS proxy server to upgrade your security. Give me a call or send an email.
At Smartvox, all of our biggest clients are VoIP Service Providers who need their SIP-based services to be resilient and robust – able to keep working despite some random hardware failure or accidental tripping over the lead in the server room.
Systems that have built-in resilience are often referred to as “highly-available” and they make particular use of clustering methodologies. In IT, a cluster is simply a group of inter-connected servers that behave like a single system to provide high availability or load sharing. Widely used in the world of Linux is the ClusterLabs stack comprising Pacemaker and Corosync. If you are interested in learning more about using Pacemaker with OpenSIPS then please have a read of this new article just published in the Smartvox Knowledgebase:
Are you thinking of using TLS connections to OpenSIPS?
Support for TLS existed in version 1, but the configuration changed significantly in version 2.
You can read the full article explaining how to set up OpenSIPS v2.2.x for TLS on the Smartvox Knowledgebase at:
Smartvox owner, John Quick, is looking forward to presenting a paper at the 2016 OpenSIPS Summit in Amsterdam in May.
The theme of my paper will be security and how to avoid getting clobbered by International Revenue Share Fraud incidents. Hope to see you there.