SIP and RTP/RTCP

FortiGates support the Real Time Protocol (RTP) application layer protocol for the VoIP call audio stream. RTP uses dynamically assigned port numbers that can change during a call. SIP control messages that start a call and that are sent during the call inform callers of the port number to use and of port number changes during the call.

During a call, each RTP session will usually have a corresponding Real Time Control Protocol (RTCP) session. By default, the RTCP session port number is one higher than the RTP port number.

The RTP port number is included in the m= part of the SDP profile. In the example above, the SIP INVITE message includes RTP port number is 49170 so the RTCP port number would be 49171. In the SIP response message the RTP port number is 3456 so the RTCP port number would be 3457.

 

How the SIP ALG creates RTP pinholes

The SIP ALG requires the following information to create a pinhole. The SIP ALG finds this information in SIP messages and some is provided by the SIP ALG:

Protocol	UDP (Extracted from SIP messages by the SIP ALG.)
Source IP	Any
Source port	Any
Destination IP	The SIP ALG extracts the destination IP address from the c= line in the SDP profile. The c= line can appear in either the session or media part of the SDP profile. The SIP ALG uses the IP address in the c= line of the media part of the SDP profile first. If the media part does not contain a c= line, the SIP ALG checks the c= line in the session part of the SDP profile. If the session part of the profile doesn’t contain a c= line the packet is dropped. Pinholes for RTP and RTCP sessions share the same destination IP address.
Destination port	The SIP ALG extracts the destination port number for RTP from the m= field and adds 1 to this number to get the RTCP port number.
Lifetime	The length of time during which the pinhole will be open. When the lifetime ends, the SIP ALG removes the pinhole.

The SIP ALG keeps RTP pinholes open as long as the SIP session is alive. When the associated SIP session is terminated by the SIP ALG or the SIP phones or servers participating in the call, the RTP pinhole is closed.

The figure below shows a simplified call setup sequence that shows how the SIP ALG opens pinholes. Phone A and Phone B are installed on either side of a FortiGate operating in transparent mode. Phone A and Phone B are on the same subnet. The FortiGate includes a security policy that accepts SIP sessions from port1 to port2 and from port2 to port1. The FortiGate does not require an RTP security policy, just the SIP policy.

You can see from this diagram that the SDP profile in the INVITE request from Phone A indicates that Phone A is expecting to receive a media stream sent to its IP address using port 4000 for RTP and port 4001 for RTCP. The SIP ALG creates pinhole 1 to allow this media traffic to pass through the FortiGate. Pinhole 1 is opened on the Port2 interface and will accept media traffic sent from Phone B to Phone A.

When Phone B receives the INVITE request from Phone A, Phone B will know to send media streams to Phone A using destination IP address 10.31.101.20 and ports 4000 and 4001. The 200 OK response sent from Phone B indicates that Phone B is expecting to receive a media stream sent to its IP address using ports 8000 and 8001. The SIP ALG creates pinhole 2 to allow this media traffic to pass through the FortiGate. Pinhole 2 is opened on the Port1 interface and will accept media traffic sent from Phone A to Phone B.

 

Configuration example: SIP in transparent mode

The figure below shows an example SIP network consisting of a FortiGate operating in transparent mode between two SIP phones. Since the FortiGate is operating in transparent mode both phones are on the same network and the FortiGate and the SIP ALG does not perform NAT. Even though the SIP ALG is not performing NAT you can use this configuration to apply SIP security features to the SIP traffic.

The FortiGate requires two security policies that accept SIP packets. One to allow SIP Phone A to start a session with SIP Phone B and one to allow SIP Phone B to start a session with SIP Phone A. SIP network with FortiGate in transparent mode

transparent mode

General configuration steps

The following general configuration steps are required for this SIP configuration. This example uses the default VoIP profile. The example also includes security policies that specifically allow SIP sessions using UDP port 5060 from Phone A to Phone B and from Phone B to Phone A. In most cases you would have more than two phones so would use more general security policies. Also, you can set the security service to ANY to allow traffic other than SIP on UDP port 5060.

1. Add firewall addresses for Phone A and Phone B.
2. Add a security policy that accepts SIP sessions initiated by Phone A and includes the default VoIP profile.
3. Add a security policy that accepts SIP sessions initiated by Phone B and includes the default VoIP profile.

Configuration steps – GUI

To add firewall addresses for the SIP phones

1. Go to Policy & Objects > Addresses.
2. Add the following addresses for Phone A and Phone B:

 

Category	Address
Name	Phone_A
Type	IP/Netmask
Subnet / IP Range	10.31.101.20/255.255.255.255
Interface	port1
Category	Address
Name	Phone_B
Type	IP/Netmask
Subnet / IP Range	10.31.101.30/255.255.255.255
Interface	port2

To add security policies to apply the SIP ALG to SIP sessions

1. Go to Policy & Objects > IPv4 Policy.
2. Add a security policy to allow Phone A to send SIP request messages to Phone B:

Incoming Interface	port1
Outgoing Interface	port2
Source	Phone_A
Destination Address	Phone_B
Schedule	always
Service	SIP
Action	ACCEPT

3. Turn on VoIP and select the default VoIP profile.
4. Select OK.
5. Add a security policy to allow Phone B to send SIP request messages to Phone A:

Incoming Interface	port2
Outgoing Interface	port1
Source	Phone_B
Destination Address	Phone_A

 

Schedule	always
Service	SIP
Action	ACCEPT

6. Turn on VoIP and select the default VoIP profile.
7. Select OK.

Configuration steps – CLI

To add firewall addresses for Phone A and Phone B and security policies to apply the SIP ALG to SIP sessions

1. Enter the following command to add firewall addresses for Phone A and Phone B. config firewall address edit Phone_A set associated-interface port1

set type ipmask

set subnet 10.31.101.20 255.255.255.255

next edit Phone_B set associated-interface port2

set type ipmask

set subnet 10.31.101.30 255.255.255.255

end

2. Enter the following command to add security policies to allow Phone A to send SIP request messages to Phone B and Phone B to send SIP request messages to Phone A.

config firewall policy edit 0 set srcintf port1 set dstintf port2 set srcaddr Phone_A set dstaddr Phone_B set action accept set schedule always set service SIP set utm-status enable set voip-profile default

next edit 0 set srcintf port2 set dstintf port1 set srcaddr Phone_B set dstaddr Phone_A set action accept set schedule always set service SIP set utm-status enable set voip-profile default end

 

RTP enable/disable (RTP bypass)

You can configure the SIP ALG to stop from opening RTP pinholes. Called RTP bypass, this configuration can be used when you want to apply SIP ALG features to SIP signaling messages but do not want the RTP media streams to pass through the FortiGate. The FortiGate only acts as a signaling firewall and RTP media session bypass the FortiGate and no pinholes need to be created.

Enter the following command to enable RTP bypass in a VoIP profile by disabling opening RTP pinholes:

config voip profile edit VoIP_Pro_1 config sip set rtp disable

end

end