Browsed by
Category: Tech-docs

Common technology documents about MSS and SIP-PBX

Invalid CSeq number

Invalid CSeq number

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:

==>
REGISTER sip:sip.xxx.com SIP/2.0
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 13 REGISTER
...

<==
SIP/2.0 401 Unauthorized
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 13 REGISTER
...

==>
REGISTER sip:sip.xxx.com SIP/2.0
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 14 REGISTER
...

<==
SIP/2.0 400 Bad Request
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 14 REGISTER
P-Registrar-Error: Invalid CSeq number
...

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.

[sip]
gVarSipRegSameDialog=0

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.

Anti SIP scanning

Anti SIP scanning

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.

Reports in MSS

Reports in MSS

2020-12-29 updated: Since miniSIPServer has ‘event channel‘ function to provide users’ status and details of each call, customers can use these information to build their own reports, so we cancel these functions from V38.

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.