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