Browsed by
Category: Releases

Product release messages, including LTS, stable, development versions and patches.

Final V31

Final V31

We released the final V31, that means we will be focus on next very important version V32 which will be our next LTS version to replace V24.

In fact, lots of features have been merged into the latest V31, and we will stay with V31 for several months since it is the base line of V32.  Please refer to following sections for more details about the key points.

Tools upgraded

In Windows platforms, we upgrade several important tools for V31.  The VC++ is upgraded to VC2010, so new MSS is using VC2010 run-time libraries. It could be powerful and better than previous VC2008 which has several manifest problems in customers’ environments.

The basic SSL library is migrated from OpenSSL to LibreSSL in MSS for windows. In Linux system, we still keep OpenSSL at this time and will move to LibreSSL in future. LibreSSL provides official windows library and we think it is optimized to be better than OpenSSL. If you are deploying “SIP over TLS”, this modification could be much better and safer then previous versions.

SIP stack upgraded

In recent days, we work with several customers to process scenarios with different IMS networks. We have to say we met several strange and very old SIP call flows. That’s ok, V31 is refined to fit these requirements.

“18X with/without SDP” flows are supported. “18X” means 180 or 183, so you can see several possibilities, such as “180 with SDP”, “180 without SDP”, “183 with SDP”, “183 without SDP”, and so on, and their orders are different. Sometimes we receive 180 firstly, sometimes we receive 183 firstly. In most scenarios, these messages are used to play different ring-back tone, so it is not only something with SIP stack but also something with media connections which means MSS inner MG module is upgraded too.

Another key point is SIP-UPDATE. Some IMS networks don’t use 18x to bring ring-back tone media information, they use SIP-UPDATE messages.  In another IMS network, we find it use “SIP-UPDATE without SDP” to keep alive in dialog. It is an interesting topic and we hope to write another blog to describe these scenarios carefully. Anyway, V31 is upgraded to support part of SIP-UPDATE to work with such IMS networks. We don’t implement all features about SIP-UPDATE and MSS will not invoke SIP-UPDATE flow by itself. If MSS wants to change media, it always invokes reINVITE procedures.

“tel” number format is supported in V31. Traditional soft-switch networks could transfer this format to MSS when they work with PSTN networks. We don’t understand why these soft-switch don’t convert it to SIP URL. Now V31 can accept that. Of course, MSS will never send out such number format.

miniSIPServer on Debian 9

miniSIPServer on Debian 9

It is a good news to see that the latest Debian 9 is released. We have downloaded and tested it in our lab.

Debian 9 is very interesting. Since it is a stable version, it is important for us to run miniSIPServer on this system. We have to find that so many libraries and softwares have been changed or upgraded. Previous MSS versions cannot work on it by default.

We did lots of work to fix these conflict and upgrade MSS to V31 (build 20170621). And we are exciting to announce that the latest versions can still work on previous Debian systems, such as Debian 7 and Debian 8. Everything is perfect now!

If you want to try Debian 9, please upgrade MSS to the latest V31. And please refresh the document for more details about libraries.

RFC3262

RFC3262

RFC3262 defines a method to provide reliable provisional response messages in SIP dialog. Simply, it uses a new message which is PRACK to response “response” messages. We don’t think it is a good idea, and most traditional VoIP devices don’t following this RFC document.

But now in some interoperability scenarios with the PSTN, it is required to provide RFC3262 capability. Specially in some 4G-IMS networks, for example, in China telcom markets, mobile carriers’ networks will reject SIP calls if they don’t have this capablity.

So we upgrade MSS to V31 to support RFC3262. New MSS will add ‘100rel’ in outgoing calls to update peer sides or SIP phones that it has RFC3262 capability, they can decide to invoke it by themselves. For incoming calls, MSS will not invoke RFC3262 procedures automatically unless peer sides or SIP phones require that.

If you have problem to work MSS with your local ISP networks, please try the latest MSS and hope you can enjoy it.

Media gateway and V30

Media gateway and V30

V30 is released. The key feature of this version is “media gateway”.

In fact, previous version has media gateway functions too, but these functions were combined in the same core with call-control and service-control tasks. For small size or middle size business, it is no problem to do that. But for huge size business, for example, our cloud-mss system, it could effect performance if media gateway is combined with other tasks.

We decided to separate media gateway module into an independent application. In cloud system, media gateway can be run in separated device. Several call servers can share the same media gateway server.

Since local MSS and cloud MSS have the same core, we merge this function back to V30. The difference is that the media gateway is an independent inner task in local MSS application.

This feature doesn’t require any modification in configuration or GUI. By default, you should not notice this change. We believe new core can be more stabler and more flexible.  Hope you can enjoy it!

Operator services

Operator services

We added two traditional PBX services in new MSS version: operator break-in and operator overstep. Please refer to service document for more details.

Both local-MSS and cloud-MSS have been upgraded for these services. The latest MSS version is V29 now.

Next local MSS version will be V30 and we will focus on refining media gateway functions. If you have any suggestions or requirements, please update us and we are very glad to discuss with you.

V28 and Lua services

V28 and Lua services

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.

No-answer timer in external line

No-answer timer in external line

In the external line “outgoing calls” configuration, we add an item “no-answer timer”. This item is used to limit the no-answer timer value when make outgoing calls. Please refer to attached figure.

No-answer timer value
No-answer timer vaule in outgoing calls of external line.

By default, its value is zero that means the line will use system default no-answer timer value. If it is set a value, the line will use it firstly.

For example, if it is set to be “15”, then the line will force to release the call in 15 seconds if peer side doesn’t answer the call.

miniSIPServer on Ubuntu 16.04

miniSIPServer on Ubuntu 16.04

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.

miniSIPServer on Ubuntu 16.04
miniSIPServer on Ubuntu 16.04
miniSIPServer updated and say goodbye to webRTC

miniSIPServer updated and say goodbye to webRTC

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.

IP address authorization

IP address authorization

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
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.