Sorry I'm such a rock. I've read this section 10 times but I still don't understand how to set up so that the rtp gets through.
6.2.7. SIP
Session Initiation Protocol (SIP) is an ASCII (UTF-8) text based signalling protocol used to
establish sessions between peers in an IP network. It is a request-response protocol that resembles
HTTP and SMTP. A session might consist of a Voice-Over-IP (VOIP) telephone call or it could be
a collaborative multi-media conference. Using SIP with VOIP means that telephony can become
another IP application which can integrate into other services.
SIP does not know about the details of a session's content and is only responsible for initiating,
terminating and modifying sessions. Sessions set up by SIP are typically used for the streaming of
audio and video over the Internet using the UDP protocol but they might also involve traffic based
on the TCP protocol. Although UDP based VOIP sessions are a common use, communication using
other protocols such as TCP or TLS might be involved in a session.
SIP is defined by the IETF standard RFC 3261 and is becoming popular as the standard for VOIP. It
is comparable to H.323 but a design goal with SIP is to make it more scalable that H.323. (For
VOIP see also Section 6.2.8, “H.323”.)
SIP Components
The following components are the logical building blocks for SIP communication:
User Agents These are the end points or "peers" that are involved in the peer-to-peer
communication. These would typically be the workstation or device used in an
IP telephony conversation. The word peer will often be used in this section in
this context.
Proxy Servers These act as routers in the SIP protocol, performing both as peer and server
when receiving peer requests. They forward requests to a peer's current
location as well as authenticating and authorizing access to services. They also
implement provider call-routing policies.
The proxy is typically located on the unprotected side of the D-Link Firewall
and this is the proxy location supported by the NetDefendOS SIP ALG.
Registrars A server that handles SIP REGISTER requests is given the special name of
Registrar. The Registrar server has the task of locating the host where the
other peer is reachable.
The Registrar and Proxy Server are logical entities and my in fact reside in the
same physical server.
SIP Media-related Protocols
SIP sessions make use of a number of sub-protocols:
SDP Session Description Protocol (RFC4566) is used for media session initialization.
RTP Real-time Transport Protocol (RFC3550) is used as the underlying packet format for
delivering audio and video streaming via IP using the UDP protocol.
RTCP Real-time Control Protocol (RFC3550) is used in conjunction with RTP to provide
out-of-band control flow management.
SIP Usage Scenarios
The NetDefendOS SIP ALG supports the following usage scenarios:
1. Internal to External The SIP session is between a peer on the protected side of a
D-Link Firewall and a peer which is on the external,
unprotected side. Communication typically takes place across
the public Internet.
2. Same Network A refinement of the internal to internal scenario is the case
where the two peers in a session reside on the same network.
In all these three scenarios the proxy server is assumed to be on the unprotected side of the D-Link
Firewall.
SIP Configuration Options
The following options can be configured for a SIP ALG object:
Maximum Sessions per ID The number of simultaneous sessions that a single peer can be
involved with is restricted by this value. The default number
is 5.
Maximum Registration Time The maximum time for registration with a SIP Registrar. The
default value is 3600 seconds.
SIP Request-Response Timeout The maximum time allowed for responses to SIP requests. A
timeout condition occurs after this wait. The default is 180
seconds.
SIP Signal Timeout The maximum time allowed for SIP sessions. The default
value is 43200 seconds.
Data Channel Timeout The maximum time allowed for periods with no traffic in a
SIP session. A timeout condition occurs if this value is
exceeded. The default value is 120 seconds
SIP Setup Summary
For setup we will assume a scenario where there is an office with VOIP users on a private internal
network and the network's topology will be hidden using NAT. This scenario is illustrated below.
The SIP proxy in the above diagram could alternatively be located remotely across the Internet. The
SIP proxy server should be configured with the feature Record-Route Enabled to insure all SIP
traffic to and from the office peers will be sent through the SIP Proxy. This is recommended since
the attack surface is minimimized by allowing only SIP signalling from the SIP Proxy to enter the
local network. The steps to follow are:
Note
SIP User Agents and SIP Proxies should not be configured to employ NAT Traversal
in a setup. For instance the Simple Traversal of UDP through NATs (STUN) technique
should not be used. The NetDefendOS SIP ALG will take care of all traversal issues
with NAT in a SIP setup.
1. Define a SIP ALG object using the options described above.
2. A Service object is used for the ALG which has the above SIP ALG associated with it. The
Service should have:
• Destination Port set to 5060
• Type set to UDP
3. Define two rules in the IP rule set:
• A NAT rule for outbound traffic from user agents on the internal network to the SIP Proxy
Server located externally. The SIP ALG will take care of all address translation needed by
the NAT rule. This translation will occur both on the IP level and the application level.
Neither the user agents or the proxies need to be aware that the local users are being
NATed.
• An Allow rule for inbound SIP traffic from the SIP proxy to the IP of the D-Link Firewall.
This rule will use core (in other words NetDefendOS itself) as the destination interface.
The reason for this is due to the NAT rule above. When an incoming call is received,
NetDefendOS will automatically locate the local receiver, perform address translation and
forward SIP messages to the receiver. This will be executed based on the ALGs internal
state.
A SAT rule is not needed since the ALG takes care of the mapping of the individual user IP
address behind the gateway to the public Internet address. When a user behind a D-Link
Firewall registers with a SIP proxy it sends its SIP URI (to uniquely identify it) to the firewall's
public IP address. When an exernal user then initiates a call, the SIP traffic arrives at the public
IP address and the ALG performs the necessary translation to the user's internal IP address.
4. Ensure the peers are correctly configured. The SIP Proxy Server plays a key role in locating the
current location of the other peer for the session. The proxy's IP address is not specified
directly in the ALG. Instead its location is either entered directly into the client software used
by the peer or in some cases the peer will have a way of retrieving the proxy's IP address
automatically such as through DHCP.
Handling Data Traffic
The setup steps above take care of the SIP communication for establishing peer-to-peer
communications. The two IP rules are always needed so that peers can access the SIP proxy but no
rules are needed to handle the actual data traffic involved in, for example, a VOIP call. The SIP
ALG automatically takes care of establishing the NetDefendOS objects required for allowing the
data traffic to traverse the D-Link Firewall and these are invisible to the administrator.
Tip
Make sure there are no preceding rules already in the IP rule set disallowing or
allowing the same kind of traffic.
Depending on the SIP environment, the NetDefendOS SIP ALG can operate in hidden-topology
environments with private IP addresses, as well as open environments with public IP addresses. SIP
is a highly configurable protocol and the following describes the configuration required.
Author
Topic: What is the best way to allow a SIP connection through the DFL-210? (Read 7525 times)