We’ve been using Mikrotik over the last year for a few installations with our on site SIP platform and when they work, they work fantastically. However we’ve run into several instances, including cross country installs, where we end up being unable to register.
Packet captures shows the following error on registration packets:
Header not terminated by empty line (CRLF)
[Expert Info (Warning/Malformed): Header not terminated by empty line (CRLF)]
[Header not terminated by empty line (CRLF)]
[Severity level: Warning]
[Group: Malformed]
We’ve experienced this out of state, and in local installs. In some cases, simply factory resetting the device can clear the error and allow it to work. In other cases it continues to fail. According to our SIP provider when this error is happening, they never receive any registration request packets so it is being stopped at the door and never leaves the building. When taking the Mikrotik out of play, and placing a different router in place, registration takes no effort and works just fine so it is most definitely the Mikrotik doing something. In all of these cases each Mikrotik was on the latest stable firmware available (we do not use RCs in customer environments unless absolutely necessary).
Any thoughts/ideas? Need any more information? Let me know and I will respond as soon as I can.
First thing to check is SIP helper turned off in your routers? IP>Firewall>Services ?
Occasionally clients call up with SIP issues and ask for SIP-ALG to be turned off which the above is the “go to” in this occasion.
In a case I experienced with SonicWall and SIP the solution was to use TCP for the SIP protocol, as this would work better than UDP.
Also: after changing the SIP helper setting you might need to clear connection tracking/reboot the phones in order to test it properly. But I’m not sure about it, so just a guess
This platform has an on-site PBX that hosts the SIP connection to the carrier. All other phones are provisioned locally or for remote connection back to this PBX and are not presenting with an issue. It is only the device registering to the SIP servers that is having this issue causing it to be unable to register to the SIP provider. The SIP provider also does not allow for modification on the protocols for registration. Otherwise I would try this.
@WesternData - I use MTs for the sole purpose of supporting my voice deployments. So lets start with the basics. 1) What type of SIP platform is this? 2) Can you get an actual pcap/sip capture of the packets at both the SIP platform level and the router level?
We use the Yeastar S-Series platform PBX which has built in packet capture and can use the MT’s packet sniffer tool to redirect it’s findings into the Yeastar’s pcap. The header analysis in OP is directly from a pcap captured this way.
Depending on the capabilities of the PBX, the SIP ALG functionality may or may not be necessary in your case. If it is not necessary, disabling it and, according to some MUM presentations, a subsequent reboot of the Mikrotik should make sure it won’t modify the SIP messages at all. I had some issues with unusual SDP fields causing the SIP ALG to drop some packets in the past. This particular issue cannot be related to REGISTER which carries no SDP but there may be something else unusual in the REGISTER messages (sent by some phone models?) what sends the ALG off-track.
If the problems persist even with SIP ALG off, or if you need it to be active because the PBX cannot handle client-side NAT, I would use /tool sniffer to capture the traffic on both interfaces involved (the registrar-facing one and the phone-facing one) simultaneously into a file and compare the REGISTER packets “before” and “after” using Wireshark. If you find some issues with the contents of the SIP messages on the PBX-facing interface which did not exist in the same message sniffed on the phone-facing one, the proper next step is to send the capture together with supout.rif to support@mikrotik.com.
Since at this stage there should be no Authorization header in the REGISTER yet, there is no risk of password leakage. If your phone does place an authorization header into REGISTER based on previously received 401, or if the issue occurs only with the second REGISTER responding the 401 with a WWW-Authenticate header, change the username and password before sniffing the file to be sent to support.
What you have posted in the OP does not indicate the particular header which is affected; at best switch on the “Display raw text for SIP message” protocol preference of SIP in Wireshark (right-click any line in the dissected SIP message, choose Protocol preferences and check the line), copy the raw message text, edit the IP addresses and other sensitive information while preserving the number of characters, and paste the message here. Do this for both messages, the one coming from the phone and the one sent out by the Mikrotik. See an example below.
The Yeastar S-Series runs Asterisk v13. All of my PBXes sitting behind my MTs are Asterisk based. I even have one Yeastar U-100 and I use the Yeastar NeoGate TA series for handling SIP to FXS for legacy PBXes. If you are having issues with the SIP headers being malformed then you have a configuration issue within the Yeastar that needs to be addressed. Make sure the Firewall in the Yeastar is turned off, it’s a POS. Also make sure the SIP Settings have the right NAT details.
If the S-Series allows it, log into the PBX via SSH and do the following:
asterisk -r
sip set debug on
Then attempt a call, registration, etc. That will output the the Asterisk SIP messages and show how Asterisk is formatting the REGISTER/INVITE headers. That is what needs to be looked at.