The drafts below describe how SIP works with firewalls and NATs (network address translators).
March 2001.
In this draft, we discuss how SIP can traverse enterprise and
residential firewalls and NATs. This environment is challenging because
we assume here that the end user has little or no control over the
firewall or NAT, and that the firewall or NAT is completely ignorant of
SIP.
C. Martin and A. Johnston
February 2001.
This informational draft outlines the operation of a transparent SIP
NAT/firewall proxy which makes modifications to SIP (Session Initiation
Protocol)[2] headers and SDP (Session Description Protocol)[3] fields.
Both inbound and outbound detailed call flows are included.
July 2000.
At the boundaries of some networks, administrators may want to implement
policies that govern the application-layer traversal of SIP signaling.
This document serves as an introduction to application- layer policies
for SIP, discusses the architectures of network boundaries at which
policies might be deployed, and provides examples of policies tailored
to particular network services.
July 2000.
This document describes a solution that is able to handle SIP signaling
together with NAT enabled firewalls. The intent is to show that
existing firewalls do not have to be replaced by 'SIP enabled' ones,
instead they will only have to be reconfigured slightly. The main
feature of this solution is using MGCP from a session control proxy to
open/close holes in an RTP proxy which then enables RTP traffic to flow
between interconnected networks. Worth noting is that this solution
will not only work for SIP, it will also work for other protocols, such
as H.323 or Real Audio. It does not even have to be RTP that is passed
through the RTP proxy, though this draft assumes that the RTP stream is
accompanied by RTCP. The solution will work for any protocol that
wishes to open/close ports dynamically in the RTP proxy (maybe it should
be called Forwarding Engine in the general case).
February 2000.
Last updated by Henning Schulzrinne