The latest Ubuntu 16.04 was released yesterday. Since it is a LTS version, we downloaded it as soon as possible and made some test in lab.
Some libraries have been upgraded or changed in this version, we need update MSS to fit these modifications. If you want to try miniSIPServer on Ubuntu 16.04, or you want to upgrade your previous Ubuntu to 16.04, you need install latest miniSIPServer V27 (build 20160422) .
Please refer to attached figure, we run the latest MSS on Ubuntu 16.04.
One of our customers reported that his extensions have been cracked. We checked its MSS CDR records. It seems someone has cracked one extension’s password and used this extension number to make lots of calls.
Obveriously, it is a very dangerous problem. We think this “hacker” might send lots of SIP messages to MSS to try such extension’s password. MSS previous version doesn’t consider this scenario and always permit the SIP phone to keep trying its password until it is authorized.
To stop this, we upgrade V26 to support “fail to ban (F2B)” feature. Once SIP phone has failed to check authorization for several times in one minute, MSS will detect it as “scanning” and ban its IP address for several hours. All SIP messages from such address will be rejected directly. Then it is impossible for “hacker” to crack SIP passwords.
This feature is enabled by default and need configure nothing for it.
miniSIPServer V25 is updated to fix some bugs and refine system to be more stable. The most important change is that we cut ‘webRTC’ feature from this version and abover.
As we described in previous post, MSS webRTC feature can work with Chrome navigator. Chrome is upgraded to V48 and make some changes to webRTC and doesn’t consider compatibility with previous version. We think maybe webRTC is perfect for public network services, such as Google hangouts, but it is not suitable or flexible for small or middle size enterprise communication markets.
So we cut it from V25, and keep it in V24. If you are using webRTC feature, please keep your Chrome to V47 or lower versions.
Some virtual servers in cloud-MSS system have been changed, please pay attention to these items.
STUN server
Each virtual SIP server will enable STUN feature. For example, if the SIP server address is “1234.s1.minisipserver.com”, its STUN server can also be the same address. That means “1234.s1.minisipserver.com” is also its STUN server address.
Now we suggest “stun.minisipserver.com” by default. It is a simple public STUN server for all virtual SIP servers. Of course, you can still configure your virtual SIP server address as your STUN server.
SMTP server
In voice-mail feature, we need a SMTP server to send emails with attached audio files. Each virtual SIP server can be configured with customers’ own SMTP servers. But we find it could make several problems. For example, most customers try to use Gmail SMTP server. Gmail SMTP server requires that you need enable POP/SMTP firstly, and grand other access. Most customers don’t know how to do that.
So we disable SMTP server configurations. All voice mails will be sent from our own SMTP server. Most important is that you will need check your spam box if you cannot find voice email in ‘inbox’.
This feature was merged to the latest V25 (build 20160126).
Some special SIP devices, for example embeded devices in automaticated system, don’t have full SIP capabilities, they can make or receive simple SIP calls without account and password authorization. They even cannot send REGISTER messages to MSS to update their own status.
Yep, we can configure them as “SIP trunk” in MSS. but it will lost several key features, such as ringing-group. In some scenarios, customers hope to ring all such devices together, so we have to treat them as “local users”.
To fit these requirements, we add “IP address authorization” in local user’s configuration. That means MSS will not require SIP phones/devices to register them firstly, and will not check their account and password if their messages are from specific or configured IP addresses. Please refer to below figure for more details.
IP address authorization
By the way, we update openAPI document according to the latest V25. If you are interesting in it, please refer to openAPI document.
Some customers have several office branches and hope to establish VoIP connections between them. There are several methods to do that. Here we give an example to describe how to establish voip connections between two MSSes with SIP trunk feature.
2. Network topology
The network topology is simple. There are two office branches. Please refer to below figure.
Demo network
Before we setup voip network, it is better to assign extension numbers. Different office numbers will effect how to configure call routing in both MSSes. In above figure, we can see the extensions in office 1 are 1xx, and extension numbers in office 2 are 2xx.
Both MSSes are configured with public IP address. If your MSS is behind NAT or router and you want to provide connection for outsides users, please refer to another document firstly.
Now we give detail configurations for it.
3. Configuration
In below configurations, items should be kept their default values if we don’t configure them obviously.
3.1 MSS1
Please click menu “data – SIP trunk”, then add a record:
SIP trunk ID = 1
Description = to MSS2
Server address = 10.23.x.x
Please click menu “dial plan – analyzed called number” , then add a record for routing 2xx to such SIP trunk.
called number prefix = 2
route type = SIP trunk
SIP trunk ID = 1
3.2 MSS2
It is almost same with MSS1.
Please click menu “data – SIP trunk” to add a record.
SIP trunk ID = 1
Description = to MSS1
Server address = 41.32.x.x
Please click menu “dial plan – analyzed called number” for routing calls to above SIP trunk.
called number prefix = 1
route type = SIP trunk
SIP trunk ID = 1
In voice mail feature, MSS need use SMTP library to send emails. Since MSS can embed Python script functions, it is easy to use Python-smtplib to send email. That’s what we done and it works well, we are satisfied with it.
But smtplib is too old ( in python 2.7) to fit some modem SMTP servers’ requirements. It also has a shortage. It is synchronous. That means it can block thread when sending a email, then its performance is poor and cannot fit our requirements in cloud system.
Something is changed, we want MSS to be better, so we develop a new SMTP library to send voice mails. This SMTP library is asynchronous and can work perfectly with most SMTP servers. And, it is written in C/C++ language.
We upgraded MSS V23 and cloud-MSS to replace python-smtplib with this new SMTP library.
Hope you can enjoy latest versions.
By the way, since MSS V23 has been released for several months and we got very better result, we think it is time to release new LTS version which is V24 and new stable version which is V25 in the end of this year or in the beginning of next year.
MSS V23 was released yesterday. The main feature of this version is “shared appearance”. In one number service, the SIP phones can subscribe others’s dialog status, and MSS will notify them with all kinds of busy signals: early, confirmed, terminated, and so on.
Please note that this feature requires SIP phones to have SUBSCRIBE/NOTIFY capabilities. If your phones cannot support these methods, this feature will be discard automatically.
You need configure nothing to enable this feature. So easy, right? Hope you can enjoy it!
