Hi,
I am struggling with the SIP ALG detection of the firewall checker, and I think there is a part missing from its documentation explaining this bit...
My setup is:
- 3CX 16.0.1078 on a Raspberry Pi 4 with Raspbian Buster
- Router: Unifi Dream Machine UDM (FW 1.8.4, Network Controller 6.0.43)
- ONT: Nokia G-010G-Q (provider is Deutsche Glasfaser)
I have disabled SIP ALG in the UDM (H.323: off, SIP: off), however the SIP ALG check keeps failing. For example my latest run yielded this output:
In order to understand what was going on, I dumped the traffic on both the Pi's LAN interface and the UDM's WAN interface while running this test. Here's what I got:
So the checker service saw the same INVITE message with CRC 0xAC1971AF that was sent out by the Pi. Good.
What it seems to have a problem with is the X-CSRESP value, which matches the left value 5b06ac3a of the error message. However, I have no clue how to generate that or the apparently expected value of e323e5a7 from the SIP packets. Throwing the SIP reponse as a whole or parts of it against the CRC-32 service yields completely different values.
Can somebody clarify how I can dig into what exactly is the mismatch here?
I am struggling with the SIP ALG detection of the firewall checker, and I think there is a part missing from its documentation explaining this bit...
My setup is:
- 3CX 16.0.1078 on a Raspberry Pi 4 with Raspbian Buster
- Router: Unifi Dream Machine UDM (FW 1.8.4, Network Controller 6.0.43)
- ONT: Nokia G-010G-Q (provider is Deutsche Glasfaser)
I have disabled SIP ALG in the UDM (H.323: off, SIP: off), however the SIP ALG check keeps failing. For example my latest run yielded this output:
In order to understand what was going on, I dumped the traffic on both the Pi's LAN interface and the UDM's WAN interface while running this test. Here's what I got:
- The SIP INVITE and response messages recorded on both devices are identical
- Using the documented procedure to check the INVITE's CRC-32 gives me a CRC value of 0xAC1971AF
- The response header returned by the checker service gives a matching value:
So the checker service saw the same INVITE message with CRC 0xAC1971AF that was sent out by the Pi. Good.
What it seems to have a problem with is the X-CSRESP value, which matches the left value 5b06ac3a of the error message. However, I have no clue how to generate that or the apparently expected value of e323e5a7 from the SIP packets. Throwing the SIP reponse as a whole or parts of it against the CRC-32 service yields completely different values.
Can somebody clarify how I can dig into what exactly is the mismatch here?
Last edited:
