Just for the records, I did disable/delete the SIP session-helper feature and rebooted (several times, between tests). I then started off my SIP-ALG testings with a copy of the DEFAULT VOIP-PROFILE.
Actually I wasn’t totally right with my initial findings exposed above, as further investigations have determined the following:
On booting, our Aastra SIP phones produce the following REGISTER header packet: (sensible values were modified):
…..
Via: SIP/2.0/UDP 10.0.1.110:5060;branch=z9hG4bKb0570a3cb75d7f471
…..
Contact: " " <sip:+41443011111-00@10.0.1.110:5060;transport=udp>;expires=3600;+sip.instance=" <urn:uuid:00000000-0000-1000-8000-00085D3C27F8>"
…..
With the default VOIP-PROFILE, the above REGISTER packet is blocked by the Fortigate with the message:
Malformed Description: empty-quoted-string
Malformed Description: invalid-quoted-string-in-display-name
Block reason: unrecognized form
That makes sense, given the unexplained presence of the double quotes in the Contact header.
The only way I found to circumvent this misconfigured header was to disable the ‘block-unknow’ option in the VOIP-PROFILE.
With this option disabled, this is how the REGISTER packet looks when it reaches the LAN interface
Via: SIP/2.0/UDP 10.0.1.110:5060;branch=z9hG4bK94d1659f7b5d7a71c
Contact: " " <sip:+41443011111-00@10.0.1.110:5060;transport=udp>;expires=3600;+sip.instance=" <urn:uuid:00000000-0000-1000-8000-00085D3C27F8>"
and how it looks on the WAN interface, on its way to the SIP Server:
Via: SIP/2.0/UDP 119.124.131.12:5060;branch=z9hG4bK94d1659f7b5d7a71c
Contact: " " <sip:+41443011111-00@10.0.1.110:5060;transport=udp>;expires=3600;+sip.instance=" <urn:uuid:00000000-0000-1000-8000-00085D3C27F8>"
This packets will be eventually rejected by the SIP server, most probably due to the different VIA and CONTACT values
My impression is that the Fortigate bugs here:
- It nats the VIA header
- Further down the packet it finds a misconfigured CONTACT header
- It sees the instruction to NOT TO BLOCK unknown packets
- So it releases the packet immediately without finishing his job, i.e. natting the rest of the header.
The result is a mismatched VIA and CONTACT information that will be rejected by the SIP server with a ‘403 Forbidden’ notification.
I have setup a SIP proxy that simply removes the double quotes in the CONTACT header on the fly, before they reache the Fortigate, and that had fixed the problem, at least temporarily.