Controlling how the SIP ALG NATs SIP contact header line addresses

Controlling how the SIP ALG NATs SIP contact header line addresses

You can enable contact-fixup so that the SIP ALG performs normal SIP NAT translation to SIP contact headers as SIP messages pass through the FortiGate unit.

Disable contact-fixup if you do not want the SIP ALG to perform normal NAT translation of the SIP contact header if a Record-Route header is also available. If contact-fixup is disabled, the FortiGate ALG does the following with contact headers:

  • For Contact in Requests, if a Record-Route header is present and the request comes from the external network, the SIP Contact header is not translated.
  • For Contact in Responses, if a Record-Route header is present and the response comes from the external network, the SIP Contact header is not translated.

If contact-fixup is disabled, the SIP ALG must be able to identify the external network. To identify the external network, you must use the config system interface command to set the external keyword to enable for the interface that is connected to the external network.

Enter the following command to perform normal NAT translation of the SIP contact header:

config voip profile edit VoIP_Pro_1

config sip

set contact-fixup enable end

end

NAT with IP address conservation

NAT with IP address conservation

In a source or destination NAT security policy that accepts SIP sessions, you can configure the SIP ALG or the SIP session helper to preserve the original source IP address of the SIP message in the i= line of the SDP profile. NAT with IP address conservation (also called SIP NAT tracing) changes the contents of SIP messages by adding the source IP address of the originator of the message into the SDP i= line of the SIP message. The SDP i= line is used for free-form text. However, if your SIP server can retrieve information from the SDP i= line, it can be useful for keeping a record of the source IP address of the originator of a SIP message when operating in a NAT environment. You can use this feature for billing purposes by extracting the IP address of the originator of the message.

 

Configuring SIP IP address conservation for the SIP ALG

You can use the following command to enable or disable SIP IP address conservation in a VoIP profile for the SIP ALG. SIP IP address conservation is enabled by default in a VoIP profile.

config voip profile edit VoIP_Pro_1

config sip

set nat-trace disable end

end

If the SIP message does not include an i= line and if the original source IP address of the traffic (before NAT) was 10.31.101.20 then the FortiGate unit would add the following i= line.

i=(o=IN IP4 10.31.101.20)

You can also use the preserve-override option to configure the SIP ALG to either add the original o= line to the end of the i= line or replace the i= line in the original message with a new i= line in the same form as above for adding a new i= line.

By default, preserver-override is disabled and the SIP ALG adds the original o= line to the end of the original i= line. Use the following command to configure the SIP ALG to replace the original i= line:

config voip profile edit VoIP_Pro_1

config sip

set preserve-override enable end

end

 

Configuring SIP IP address conservation for the SIP session helper

You can use the following command to enable or disable SIP IP address conservation for the SIP session helper. IP address conservation is enabled by default for the SIP session helper.

config system settings

set sip-nat-trace disable end

If the SIP message does not include an i= line and if the original source IP address of the traffic (before NAT) was

10.31.101.20 then the FortiGate unit would add the following i= line.

i=(o=IN IP4 10.31.101.20)

Additional SIP NAT scenarios

Additional SIP NAT scenarios

This section lists some additional SIP NAT scenarios.

 

Source NAT (SIP and RTP)

In the source NAT scenario shown below, a SIP phone connects to the Internet through a FortiGate unit with and IP address configured using PPPoE. The SIP ALG translates all private IPs in the SIP contact header into public IPs.

You need to configure an internal to external SIP security policy with NAT selected, and include a VoIP profile with SIP enabled.

 

SIP source NAT

217.10.79.9    217.10.69.11

SIP Proxy

Server

RTP Media

Server

SIP service provider has a SIP server and a separate RTP server 217.233.122.132

10.72.0.57

FortiGate Unit

 

Destination NAT (SIP and RTP)

In the following destination NAT scenario, a SIP phone can connect through the FortiGate unit to private IP address using a firewall virtual IP (VIP). The SIP ALG translates the SIP contact header to the IP of the real SIP proxy server located on the Internet.

SIP destination NAT

217.10.79.9

217.10.69.11

SIP Proxy

Server

RTP Media

Server

SIP service provider has a SIP server and a separate RTP server

In the scenario, shownabove, the SIP phone connects to a VIP (10.72.0.60). The SIP ALG translates the SIP contact header to 217.10.79.9, opens RTP pinholes, and manages NAT.

The FortiGate unit also supports a variation of this scenario where the RTP media server’s IP address is hidden on a private network or DMZ.

 

SIP destination NAT-RTP media server hidden

192.168.200.99

219.29.81.21

RTP Media

Server

10.0.0.60

217.233.90.60

SIP Proxy Server

FortiGate Unit

In the scenario shown above, a SIP phone connects to the Internet. The VoIP service provider only publishes a single public IP. The FortiGate unit is configured with a firewall VIP. The SIP phone connects to the FortiGate unit (217.233.90.60) and using the VIP the FortiGate unit translates the SIP contact header to the SIP proxy server IP address (10.0.0.60). The SIP proxy server changes the SIP/SDP connection information (which tells the SIP phone which RTP media server IP it should contact) also to 217.233.90.60.

 

Source NAT with an IP pool

You can choose NAT with the Dynamic IP Pool option when configuring a security policy if the source IP of the SIP packets is different from the interface IP. The FortiGate ALG interprets this configuration and translates the SIP header accordingly.

This configuration also applies to destination NAT.

 

Different source and destination NAT for SIP and RTP

This is a more complex scenario that a SIP service provider may use. It can also be deployed in large-scale SIP environments where RTP has to be processed by the FortiGate unit and the RTP server IP has to be translated differently than the SIP serverIP.

 

Different source and destination NAT for SIP and RTP

RTP Servers

192.168.0.21 – 192.168.0.23

219.29.81.10

219.29.81.20

RTP Server

10.0.0.60

 

SIP Server

IP: 217.233.90.60

 

In this scenario, shown above, assume there is a SIP server and a separate media gateway. The SIP server is configured so that the SIP phone (219.29.81.20) will connect to 217.233.90.60. The media gateway (RTP server:

219.29.81.10) will connect to 217.233.90.65. What happens is as follows:

1. The SIP phone connects to the SIP VIP. The FortiGate ALG translates the SIP contact header to the SIP server: 219.29.81.20 > 217.233.90.60 (> 10.0.0.60).

2. The SIP server carries out RTP to 217.233.90.65.

3. The FortiGate ALG opens pinholes, assuming that it knows the ports to be opened.

4. RTP is sent to the RTP-VIP (217.233.90.65.) The FortiGate ALG translates the SIP contact header to 192.168.0.21.

SIP NAT configuration example: destination address translation (destination NAT)

SIP NAT configuration example: destination address translation (destination NAT)

This configuration example shows how to configure the FortiGate unit to support the destination address translation scenario shown in the figure below. The FortiGate unit requires two SIP security policies:

  • A destination NAT security policy that allows SIP messages to be sent from the Internet to the private network. This policy must include destination NAT because the addresses on the private network are not routable on the Internet.
  • A source NAT security policy that allows SIP messages to be sent from the private network to the Internet.

 

SIP destination NAT scenario part two: 200 OK returned to Phone B and media streams established

FortiGate-620B Cluster

 

SIP proxy server

Virtual IP: 172.20.120.50

 

SIP Phone A (PhoneA@10.31.101.20)

SIP proxy server

10.31.101.50

SIP Phone B (PhoneB@172.20.120.30)

 

General configuration steps

The following general configuration steps are required for this destination NAT SIP configuration. This example uses the default VoIP profile.

1. Add the SIP proxy server firewall virtual IP.

2. Add a firewall address for the SIP proxy server on the private network.

3. Add a destination NAT security policy that accepts SIP sessions from the Internet destined for the SIP proxy server virtual IP and translates the destination address to the IP address of the SIP proxy server on the private network.

4. Add a security policy that accepts SIP sessions initiated by the SIP proxy server and destined for the Internet.

 

Configuration steps – web-based manager

To add the SIP proxy server firewall virtual IP

1. Go to Policy & Objects > Virtual IPs.

2. Add the following SIP proxy server virtual IP.

VIP Type                                     IPv4

Name                                           SIP_Proxy_VIP

Interface                                     port1

Type                                            Static NAT

External IP Address/Range     172.20.120.50

Mapped IP Address/Range      10.31.101.50

 

To add a firewall address for the SIP proxy server

1. Go to Policy & Objects > Addresses.

2. Add the following for the SIP proxy server:

Address Name                           SIP_Proxy_Server

Type                                            Subnet

Subnet/IP Range                       10.31.101.50/255.255.255.255

Interface                                     port2

 

To add the security policies

1. Go to Policy & Objects > IPv4 Policy.

2. Add a destination NAT security policy that includes the SIP proxy server virtual IP that allows Phone B (and other SIP phones on the Internet) to send SIP request messages to the SIP proxy server.

Incoming Interface                   port1

Outgoing Interface                   port2

Source                                        all

Destination Address                 SIP_Proxy_VIP

Schedule                                    always

Service                                       SIP

Action                                         ACCEPT

3. Turn on NAT and select Use Outgoing Interface Address.

4. Turn on VoIP and select the default VoIP profile.

5. Select OK.

6. Add a source NAT security policy to allow the SIP proxy server to send SIP request messages to Phone B and the Internet:

Incoming Interface                   port2

Destination Address                 all

Source                                        SIP_Proxy_Server

Schedule                                    always

Service                                       SIP

Action                                         ACCEPT

7. Turn on NAT and select Use OutgingInterface Address.

8. Turn on VoIP and select the default VoIP profile.

9. Select OK.

 

Configuration steps – CLI

 

To add the SIP proxy server firewall virtual IP and firewall address

1. Enter the following command to add the SIP proxy server firewall virtual IP.

config firewall vip edit SIP_Proxy_VIP

set type static-nat

set extip 172.20.120.50 set mappedip 10.31.101.50 set extintf port1

end

2. Enter the following command to add the SIP proxy server firewall address.

config firewall address edit SIP_Proxy_Server

set associated interface port2 set type ipmask

set subnet 10.31.101.50 255.255.255.255 end

 

To add security policies

1. Enter the following command to add a destination NAT security policy that includes the SIP proxy server virtual IP

that allows Phone B (and other SIP phones on the Internet) to send SIP request messages to the SIP proxy server.

config firewall policy edit 0

set srcintf port1 set dstintf port2 set srcaddr all

set dstaddr SIP_Proxy_VIP

set action accept set schedule always set service SIP

set nat enable

set utm-status enable

set voip-profile default end

2. Enter the following command to add a source NAT security policy to allow the SIP proxy server to send SIP request messages to Phone B and the Internet:

config firewall policy edit 0

set srcintf port2 set dstintf port1

set srcaddr SIP_Proxy_Server set dstaddr all

set action accept set schedule always

set service SIP

set nat enable

set utm-status enable

set voip-profile default end

FortiOS 5.6 Beta 2 Kicks Ass

So, if you guys have viewed or read my “Where Fortinet is Messing Up” page….you know that I much prefer the way Palo Alto Networks does app assignment on policies.

5.6 Beta 2 is flipping that on it’s head though as it seems to be more aligned. The ability to select the policy and the web category from the policy is going to make policy creation significantly more granular and simple / straight forward.

I am a happy boy!

SIP NAT configuration example: source address translation (source NAT)

SIP NAT configuration example: source address translation (source NAT)

This configuration example shows how to configure the FortiGate unit to support the source address translation scenario shownbelow. The FortiGate unit 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. Both of these policies must include source NAT. In this example the networks are not hidden from each other so destination NAT is not required.

 

SIP source NAT configuration

 

 

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 firewall 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 – web-based manager

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                                     Internal

Category                                     Address

Name                                          Phone_B

Type                                            IP/Netmask

Subnet / IP Range                     172.20.120.30/255.255.255.255

Interface                                     wan1

 

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

1. Go to Policy & Objects > Policy > IPv4.

2. Add a security policy to allow Phone A to send SIP request messages to Phone B:

Incoming Interface                   internal

Outgoing Interface                   wan1

Source                                        Phone_A

Destination Address                 Phone_B

Schedule                                    always

Service                                       SIP

Action                                         ACCEPT

3. Turn on NAT and select Use Outgoing Interface Address.

4. Turn on VoIP and select the default VoIP profile.

5. Select OK.

6. Add a security policy to allow Phone B to send SIP request messages to Phone A:

Incoming Interface                   wan1

Outgoing Interface                   internal

Source                                        Phone_B

Destination Address                 Phone_A

Schedule                                    always

Service                                       SIP

Action                                         ACCEPT

7. Turn on NAT and select Use Outgoing Interface Address.

8. Turn on VoIP and select the default VoIP profile.

9. 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 internal set type ipmask

set subnet 10.31.101.20 255.255.255.255 next

edit Phone_B

set associated interface wan1 set type ipmask

set subnet 172.20.120.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 internal set dstintf wan1

set srcaddr Phone_A set dstaddr Phone_B set action accept set schedule always set service SIP

set nat enable

set utm-status enable

set voip-profile default next

edit 0

set srcintf wan1

set dstintf internal set srcaddr Phone_B set dstaddr Phone_A set action accept

set schedule always set service SIP

set nat enable

set utm-status enable

set voip-profile default end

SIP NAT scenario: destination address translation (destination NAT)

SIP NAT scenario: destination address translation (destination NAT)

The following figures show how the SIP ALG translates addresses in a SIP INVITE message sent from SIP Phone B on the Internet to SIP Phone A on a private network using the SIP proxy server. Because the addresses on the private network are not visible from the Internet, the security policy on the FortiGate unit that accepts SIP sessions includes a virtual IP. Phone A sends SIP the INVITE message to the virtual IP address. The FortiGate unit accepts the INVITE message packets and using the virtual IP, translates the destination address of the packet to the IP address of the SIP proxy server and forwards the SIP message to it.

 

SIP destination NAT scenario part 1: INVITE request sent from Phone B to Phone A

FortiGate-620B Cluster

In NAT/Route mode

Port2

 

 

72

 

100

10.11.101.  00

 

P   t1

 

Por

172.20.

 

 

.

20 120.141

SIP Virtual IP: 172.20.120.50

SIP Phone A (PhoneA@10.31.101.20)

SIP proxy server

10.31.101.50

SIP Phone B (PhoneB@172.20.120.30)

Phone B sends an INVITE request for Phone A to the SIP Proxy Server Virtual IP (SDP 172.20.120.30:4900)

INVITE sip:PhoneA@172.20.120.50 SIP/2.0

Via: SIP/2.0/UDP 172.20.120.50:5060

From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@172.20.120.50> Call-ID: 314134@172.20.120.30

CSeq: 1 INVITE

Contact: sip:PhoneB@172.20.120.30 v=0

o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 172.20.120.30

m=audio 4900 RTP 0 3

SIP ALG creates Pinhole 1. Accepts traffic on Port2 with destination address:port numbers 172.20.120.30:4900 and 4901

The SIP ALG performs destination NAT on the INVITE request and forwards it to the SIP proxy server.

The SIP proxy server forwards the INVITE request to Phone A (SDP: 172.20.120.30:4900)

INVITE sip:PhoneA@10.31.101.50 SIP/2.0

Via: SIP/2.0/UDP 10.31.101.50:5060

From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@10.31.101.50>

Call-ID: 314134@172.20.120.30

CSeq: 1 INVITE

Contact: sip:PhoneB@172.20.120.30 v=0

o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 172.20.120.30

m=audio 4900 RTP 0 3

 

To simplify the diagrams, some SIP messages are not included (for example, the Ringing and ACK response messages) and some SIP header lines and SDP profile lines have been removed from the SIP messages.

The SIP ALG also translates the destination addresses in the SIP message from the virtual IP address (172.20.120.50) to the SIP proxy server address (10.31.101.50). For this configuration to work, the SIP proxy server must be able to change the destination addresses for Phone A in the SIP message from the address of the SIP proxy server to the actual address of Phone A.

The SIP ALG also opens a pinhole on the Port2 interface that accepts media sessions from the private network to SIP Phone B using ports 4900 and 4901.

Phone A sends a 200 OK response back to the SIP proxy server. The SIP proxy server forwards the response to Phone B. The FortiGate unit accepts the 100 OK response. The SIP ALG translates the Phone A addresses back to the SIP proxy server virtual IP address before forwarding the response back to Phone B. The SIP ALG also opens a pinhole using the SIP proxy server virtual IP which is the address in the o= line of the SDP profile and the port number in the m= line of the SDP code.

 

SIP destination NAT scenario part 2: 200 OK returned to Phone B and media streams established

FortiGate-620B Cluster

In NAT/Route mode

Port2

SIP Virtual IP: 172.20.120.50

SIP Phone A (PhoneA@10.31.101.20)

SIP proxy server

10.31.101.50

SIP Phone B (PhoneB@172.20.120.30)

Phone A sends a 200 OK response to the SIP proxy server (SDP: 10.31.101.20:8888)

The SIP proxy server forwards the response to Phone B (SDP: 10.31.101.20:8888)

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.31.101.50:5060

From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@10.31.101.50>

Call-ID: 314134@172.20.120.30

CSeq: 1 INVITE

Contact: sip:PhoneB@172.20.120.30 v=0

o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 10.31.101.20

m=audio 5500 RTP 0

The SIP ALG NATs the SDP address to the Virtual IP address before forwarding the response to Phone B (SDP: 172.20.120.50:5500)

SIP/2.0 200 OK

Via: SIP/2.0/UDP 172.20.120.50:5060

From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@172.20.120.50> Call-ID: 314134@172.20.120.30

CSeq: 1 INVITE

Contact: sip:PhoneB@172.20.120.30 v=0

o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 172.20.120.50

m=audio 5500 RTP 0

Phone A sends RTP and RTCP media sessions to Phone B through pinhole 1. Destination address:port number 172.20.120.30:4900 and 4901

Pinhole 2 created. Accepts traffic on Port1 with destination address:port numbers 172.20.120.50:5500 and 5501

Pinhole 1

1 The SIP ALG NATs the destination address to 10.31.101.20.

Phone B sends RTP and RTCP media sessions to Phone A through pinhole 2. Destination address:port number 172.20.120.50:5500 and 5501.

 

Pinhole 2

The media stream from Phone A is accepted by pinhole one and forwarded to Phone B. The source address of this media stream is changed to the SIP proxy server virtual IP address. The media stream from Phone B is accepted by pinhole 2 and forwarded to Phone B. The destination address of this media stream is changed to the IP address of Phone A.

SIP NAT scenario: source address translation (source NAT)

SIP NAT scenario: source address translation (source NAT)

The following figures show a source address translation scenario involving two SIP phones on different networks, separated by a FortiGate unit. In the scenario, SIP Phone A sends an INVITE request to SIP Phone B and SIP Phone B replies with a 200 OK response and then the two phones start media streams with each other.

To simplify the diagrams, some SIP messages are not included (for example, the Ringing and ACK response messages) and some SIP header lines and SDP profile lines have been removed from the SIP messages.

 

SIP source NAT scenario part 1: INVITE request sent from Phone A to Phone B

Internal

10.31.101.100

WAN1

172.20.120.122

SIP Phone A (PhoneA@10.31.101.20)

FortiGate unit

in NAT/Route mode

SIP Phone B (PhoneB@172.20.120.30)

 

Phone A sends an INVITE request to Phone B

(SDP 10.31.101.20:4000).

INVITE sip:PhoneB@172.20.120.30 SIP/2.0

Via: SIP/2.0/UDP 10.31.101.20:5060

From: PhoneA <sip:PhoneA@10.31.101.20> To: PhoneB <sip:PhoneB@172.20.120.30> Call-ID: 314159@10.31.101.20

CSeq: 1 INVITE

Contact: sip:PhoneA@10.31.101.20 v=0

o=PhoneA 5462346 332134 IN IP4 10.31.101.20 c=IN IP4 10.31.101.20

m=audio 49170 RTP 0 3

SIP ALG creates Pinhole 1. Accepts traffic on WAN1 with destination address:port numbers

172.20.120.122:49170 and 49171

The SIP ALG performs source NAT on the INVITE request and forwards it to Phone B.

INVITE sip:PhoneB@172.20.120.30 SIP/2.0

Via: SIP/2.0/UDP 172.20.120.122:5060

From: PhoneA <sip:PhoneA@172.20.120.122> To: PhoneB <sip:PhoneB@172.20.120.30>

Call-ID: 314159@172.20.120.122

CSeq: 1 INVITE

Contact: sip:PhoneA@172.20.120.122 v=0

o=PhoneA 5462346 332134 IN IP4 172.20.120.122 c=IN IP4 172.20.120.122

m=audio 49170 RTP 0 3

 

For the replies to SIP packets sent by Phone A to be routable on Phone Bs network, the FortiGate unit uses source NAT to change their source address to the address of the WAN1 interface. The SIP ALG makes similar changes the source addresses in the SIP headers and SDP profile. For example, the original INVITE request from Phone A includes the address of Phone A (10.31.101.20) in the from header line. After the INVITE request passes through the FortiGate unit, the address of Phone A in the From SIP header line is translated to 172.20.120.122, the address of the FortiGate unit WAN1 interface. As a result, Phone B will reply to SIP messages from Phone A using the WAN1 interface IP address.

The FortiGate unit also opens a pinhole so that it can accept media sessions sent to the WAN1 IP address using the port number in the m= line of the INVITE request and forward them to Phone A after translating the destination address to the IP address of Phone A.

Phone B sends the 200 OK response to the INVITE message to the WAN1 interface. The SDP profile includes the port number that Phone B wants to use for its media stream. The FortiGate unit forwards 200 OK response to Phone A after translating the addresses in the SIP and SDP lines back to the IP address of Phone A. The SIP ALG also opens a pinhole on the Internal interface that accepts media stream sessions from Phone A with destination address set to the IP address of Phone B and using the port that Phone B added to the SDP m= line.

 

SIP source NAT scenario part 2: 200 OK returned and media streams established

Internal

10.31.101.100

WAN1

172.20.120.122

SIP Phone A (PhoneA@10.31.101.20)

FortiGate unit

in NAT/Route mode

SIP Phone B (PhoneB@172.20.120.30)

Phone B sends a 200 OK response to

Phone A (SDP: 172.20.120.30:3456).

 

SIP/2.0 200 OK

Via: SIP/2.0/UDP 172.20.120.122:5060

From: PhoneA <sip:PhoneA@172.20.120.122> To: PhoneB <sip:PhoneB@172.20.120.30>

Call-ID: 314159@172.20.120.122

CSeq: 1 INVITE

Contact: sip:PhoneB@172.20.120.30 v=0

o=PhoneB 124333 67895 IN IP4 172.20.120.30 c=IN IP4 172.20.120.30

m=audio 3456 RTP 0

SIP ALG creates Pinhole 2. Accepts traffic on Internal with destination address:port numbers 172.20.120.30: 3456 and 3457..

The SIP ALG performs source NAT on the 200 OK response and forwards it to Phone A.

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.31.101.20:5060

From: PhoneA <sip:PhoneA@10.31.101.20> To: PhoneB <sip:PhoneB@172.20.120.30> Call-ID: 314159@10.31.101.20

CSeq: 1 INVITE

Contact: sip:PhoneB@172.20.120.30 v=0

o=PhoneB 124333 67895 IN IP4 172.20.120.30 c=IN IP4 172.20.120.30

m=audio 3456 RTP 0

Phone B sends RTP and RTCP media sessions to Phone A through pinhole 1. Destination address:port number 172.20.120.122:49170

and 49171.

 

Pinhole 1

Phone A sends RTP and RTCP media sessions to Phone B through pinhole 2. Destination address:port number 172.20.120.30:3456 and 3457.

Pinhole 2