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.
One of our customers reported a problem that his external line was always offline with a voip provider. That’s very strange because “external line” is a very basic function of MSS and it works perfectly with lots of voip providers.
We captured the log and found the voip provider returned “400 Bad Request” message with following cause:
P-Registrar-Error: Invalid CSeq number
We checked the REGISTER messages, and think it is no problem in CSeq header. Following items are from MSS:
We checked RFC3261 to find “CSeq” in SIP-REGISTER procedures:
A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.
Obviously we are right. But why did peer side reject MSS’ messages?
Finally, we tried to send SIP-REGISTER with different ‘call-id’, and the problem was resolved! That made us confused again because in RFC3261 we can find the details of “call-id” in SIP-REGISTER procedures:
All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar.
We think the voip provider is unprofessional. Unfortunally, it is hard for them to upgrade their system. So we have to add a switch varant to control MSS to fit this kind of situation.
If you have the same problem with some voip providers, please add above parameter into “mss_var_param.ini” file and restart your MSS to enable it.
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.
Most SIP or PBX devices may have some reports to help administrator to check system’s status.
MSS has some reports too. Please click menu “Reports” to show them. MSS has two reports at this time:
(1) Basic call report
(2) Local user report
Both these reports are generated per hour. If there is not any value for each item, then the report will not be generated.
“Local user report” is simple. It only calculates how many local users are online per hour.
“Basic call report” is used to calculate how many calls MSS has been processed in one hour. There are some important items, such as “attempt”, “alert”, and “answer” and so on. It includes total durations and it can help administrator to understand how many calls have been answered and the avarage duration in one hour. If there are too many calls to make MSS heavy work-load, administrator can decide to upgrade MSS.