V28 is released today! We have spent several months on this version. The key feature of this version is “Lua service engine”.
As you know, previous MSS has a service engine which is written in Python language. It serves very well, but still has some limitations. Now the engine is rewritten in Lua language. Following items are some key points about why we make this decision.
(1) Lua is much simpler than Python. Python is full stack language,Lua is a embed script, it has less function but it is simple. We love Python but still find that Lua is suitable for MSS to provide service engine. We don’t need full functions, we only need the engine to packing MSS core functions and capabilities.
(2) The most important is stability. Python service engine uses one Python VM to serve all services. That means one unknown exception could block all services. With new Lua service engine, one Lua VM serves one service. That means one unknown exception can only block one service, other services can keep on working. That’s amazing, the whole system can step into higher level now!
(3) Faster! faster! faster! In fact, because of GIL, Python cannot provide high performance, so we have to limit the engine in service level. Lua doesn’t have such limitation, each Lua VM is tiny and independent, Now we can use it to be a service engine and will even use it to provide a basic call engine. The future is coming.
In V28, Python services are replaced with Lua services. You can find these Lua services in “lua/services” sub-directory. If you have modified Python services by yourself, you will have to update related Lua services.
Lua service engine is in background, you don’t need change any configuration by default.
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.
Today we release latest V15 for miniSIPServer. This version is focus on providing a new service engine which is written in Python script.
That means almost all services are written in Python script files. New service engine is more flexible to fit different services requirements. Some advanced customers even can written their own special services now.
As you may know, we can implement service logic by using Python script. It is very flexible to fit all kinds of customers’ requirements.
For example, MSS’ calling card service is written in Python script. In some fields, some customers require some different service logic,such as playing audio or not, prompt this or that, and so on. We can update python script file according to their requirement without any modification to MSS core.
But something is not so flexible. For example, the trigger of calling card is fixed in MSS core with previous versions. That means you can only trigger calling card service with called number ‘*300*’ of incoming calls. Some customers don’t like this number, some others want to support more called number to trigger calling card service.
With V10.4 released, we can configure different trigger for python services. In fact, we can trigger a python service according to their dial-plan and destination number in incoming calls. So everything is perfect now! Customers can implement their own service logic, they can trigger their services according to their real requirement. You don’t like ‘*300*’? no problem, just need configure another record!
For more details, please refer to manual document: