Description
This article provides guidance for this unusual behavior of the FortiGate regarding secondary SIP INVITE packets.
Normally, one or two INVITE packets are sent when a call is placed.
These packets are correctly forwarded and NAT-ted by FortiGate towards their destination, and the call establishes successfully.
However, in some cases the call does not complete, or the remote site blocks part of the conversation (either SIP packets or RTP ports).
In these cases, the SIP INVITE is re-sent.
Also, a second SIP invite can be considered the ones used for call transfers. So, if a call transfer fails, a possible problem is this second INVITE that has no NAT performed on the SDP header.
Scope
This behavior is associated with SIP-ALG and affects ONLY FortiOS 6.2.
DO NOT disable SIP-ALG to eliminate this problem.
SIP-ALG should be used, so make sure that it is correctly enabled.
Note: The policy allowing the SIP traffic in FortiOS 7.0+ (7.2+) MUST be in proxy-mode for SIP-ALG to be enabled and used correctly.
How this looks in a packet capture:
Solution
This is a common problem reported in FortiOS 6.2.x, and not fixed in this version.
Upgrade to FortiOS 6.4 that benefits from a major improvement and redesign of SIP-ALG.
The alternative for 6.2 version is to disable all SIP inspection (including sip session-helper) and reconfigure the FortiGate to open all needed ports for SIP signalling and audio.
It was also reported when SIP session-helper is used in newer versions (7.0, 7.2). SIP session-helper mechanism is not maintained, so there is no (and will not be a) solution for that. The use of SIP-ALG is really needed for more complex SIP call scenarios. Make sure SIP-ALG is enabled (in system settings) and used (firewall policy must be in proxy-mode).
