Yesterday, we helped a Chinese customer to deploy MSS to work with CTC IMS network. In this scenario, CTC IMS network has ZTE soft-switch (according to User-Agent header in SIP messages) , we need be careful to cooperate with it.
Since CTC provides user name and password for authorization, we configure “external line” in MSS to do that. Following sections will illustrate some key points.
By default, we often use “External line (account)” as authorization user name, but ZTE softswitch requires full URI format, so we need configure “authorization ID” in external line. Please refer to following figure for more details.
If it is not full format, IMS network will return “403 Forbidden” messages to reject it. In fact, we think it is a bug in ZTE softswitch since there is “realm” and “domain” parameters in SIP authorization header. No matter the user name is full format or not, the device should pass it according to successful authorization itself.
Anyway, if you have same problem to cooperate with other IMS networks, please pay attention to it and configure “authorization ID” to take a try.
In Chinese CTC-IMS network, its “SIP server” is logic domain, not a real SIP device and cannot be visited. In above scenario, “gd.ctcims.cn” is its domain, not its real address. SIP messages should be routed to another device (we think it is a SBC or proxy), so we need configure “Via” address in MSS external line configuration. Please refer to following figure.
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 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.
By default, MSS previous versions don’t limit concurrent calls of SIP trunk. That means you can make or receive calls as much as you can. If peer sides don’t have enough resources, they will reject calls by themselves. But now in some scenarios, customers hope MSS can handle concurrent calls and limit them automatically.
To fit this requirement, we upgrade MSS to provide concurrent calls configurations in SIP trunk. Too much calls will be rejected by MSS itself. Please refer to following figure for more details about these items.
Please pay attention to these.
(1) These items are independent. You can configure different values for them to limit different concurrent calls for outgoing calls and incoming calls.
(2) If one of them is zero, in fact all them can be zero, that means only incoming calls can be received, or can only make outgoing calls outsides.
We upgraded miniSIPServer V30 today to change “one number, multi-devices” service in local user’s configuration. In previous versions, we don’t need configure anything to enable this feature in local user since it was enabled by default. Customers think it is good idea to reduce configuraiton workload, but it brings new management problem. In fact, they hope to be able to control which local users can have this feature. In most scenarios, only some local users have several phones with same number, others are not permit to do that.
To fit this requirement, we add a new optional item in local user’s configuration. Please refer to following figure for more details. By default, this service is not enabled now until you configure it obviously.
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!
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.