sip-proxy, test-sip — Session Initiation Protocol (SIP) proxy
sip-proxy [-hv] [-d ] dbglev-f cfgfile
test-sip [-hv] [-d ] dbglev-f [cfgfile-r] [-t ]test_expr
The sip-proxy provides proxying service for the Session Initiation Protocol (RFC 3261 et al.). This is the first version implemented in the Kernun firewall and as such it supports mainly Internet telephone calls and related services.
Program test-sip tests syntax and partially semantics
of the configuration; for test expression syntax, see test-expr(5).
Format of the proxy configuration file is described in sip-proxy.cfg(5).
RFC describes two modes of proxy operation, stateful and stateless. The Kernun firewall SIP proxy behaves something in between of them. It provides almost full control of security aspects (allowing and denying requests, checking messages format, watching time spent and data transferred etc.). On the other hand, it does not take the control of application-level aspects (like resending requests and responses, acknowledging sessions etc.), these remain completely on the UAs responsibility.
In normal circumstances, clients register themselves via the proxy
and after it they can either invoke or accept calls.
In the case of using of public addresses or
controlling via the configuration,
clients can accept calls without registration.
Data of all registered clients are stored into a special file
(see the map-file configuration item desciption).
The proxy works both in transparent (see transparency(7)) and in non-transparent mode. The latter is recommended,
however it requires to configure the outbound proxy
on all clients and the plug-to configuration item
in the proxy configuration.
In the transparent case, the proxy hides its role
in the communication process and it can cause problems in some cases.
The proxy remembers transparency mode for every registration
and subsequent incoming calls are forwarded according to it. Thus,
if a client (phone) has registered transparently, the data sent
from the proxy to it in future incoming calls will use the caller
address as the IP source address
(like if the source-address client mode used).
The proxy assumes that responses
will be sent transparently to caller address and so they will reach
the proxy again.
In all other cases, the proxy forwards messages using its own address.
It tries to find a proper route, takes the corresponding interface address
and checks whether it also listens on this address. Then, it uses this
address (and the first bound port) as the source address.
If some of these cheks fail, the session is rejected.
Specially, for every outgoing direction,
you must have proper non-transparent listening
socket opened to be able to receive responses and incoming calls.
The source-address is kept in the configuration
for special cases, but in normal circumstances, it is not needed.
For the security reason, the proxy allows the administrator to hide
some important data (e.g. internal addresses)
usually stored into SIP messages headers. This can
be done via the hide configuration item
of the session-acl configuration sections.
In this case, the proxy hashes (using the hash-salt)
private data and presents itself to outer world, instead of real client
or server.
The session identification (carried in the Call-ID
header) is rewritten always, so the proxy acts as a terminal UAC/UAS
of the call, from the Call-ID point of view.
The proxy usually runs as two processes (not counting the configuration resolving process - see resolving(7)): the single child process manages all the sessions and the parent process manages the child and restarts it after a failure. You can learn more in udpserver(7) manual page, although the sip-proxy does not use the udpserver library, in fact. However, it uses the same operation logic.
The proxy uses common Kernun mechanism for network
input/output operations. Configuration allows for specifying
several parameters like buffer sizes and timeouts, both for
control and data connections. They can be included in
the ctrl-conn and data-conn
configuration sections,
respectively. For more detailed information, see netio(7).
The proxy uses common Kernun mechanism for logging (see logging(7)). For every session, the SESSION-START (SIPS-800-I), the ACL (SIPS-821-I and SIPS-822-I), the SESSION-INIT (SIPS-801-I) and the SESSION-END (SIPS-809-I) messages are logged. For every request, the SIPR-800-N message is logged, reporting both the request and the response. For every used data channel, a couple of DATA-END (SDPC-800-N) messages are logged, reporting amount of data and termination time of both sides of the channel.
The proxy reads its configuration file and starts listening
on specified IP sockets (address/port couples), as specified in
the listen-on configuration section (see listen-on(5)).
Proxy listens for both UDP and TCP protocols.
If support of transparent connections (see transparency(7)) is requested by item transparent in
section listen-on, the corresponding NAT redirections
are established during proxy startup and removed upon exit.
The proxy uses two layers of ACL (see access-control(7)) named
session-acl and request-acl.
When the first request of a session arrives,
configuration is consulted,
proper session-acl is selected and according to it,
the session is served or not.
In the latter case, the request is ignored, by default.
This feature can prevent against DoS attacks caused by sending lots
of unauthorized packets.
Regular termination of session according to the RFC
(i.e. with replying and waiting for specified time,
client deresolving, etc.) can be forced by
the reject-gracefully item of particular
session-acl section.
Subsequently, protocol-specific parameters of the request
is checked against set of request-acl entry conditions
and proper mode of operation is selected.
Additionally to the general Kernun ACL concept,
request-acl brings a new entry condition item:
request-uriThis item contains a set of regular expressions
and/or strings describing URIs used in request that
is to be dealt by this request-acl.
By this item, the administrator can switch traffic
to different plug-to servers according
to the Request URI format.
Subsequent requests within the same session are not checked again, in this version.
The sip-proxy handles following signals:
SIGUSR1Log level increasing.
SIGUSR2Log level decreasing.
SIGINFOOperation status logging; parent process logs info about all children, child process dumps registration map and all tables content.
SIGHUP,
SIGINT,
SIGQUIT,
SIGTERMImmediate termination; proxy immediately closes all connections and terminates.
SIGWINCHReopen logfile; if the proxy logs into a file, sending this signal causes the file will be reopened. This feature helps admin to rotate logfiles.
The program options are as follows:
-hPrint usage information and exit.
-vDisplay version information and exit.
-d dbglevSet debuging level to a specific number. Permitted values are 3 through to 9, 3 being the least and 9 the most verbose. See logging(7) for details. This setting is relevant only till configuration reading is finished.
-f cfgfileRead cfgfile
for configuration information.
-rResolve names in configuration prior to testing.
-t test-exprTest configuration according to given expression.
Format of the test-expr
is described in test-expr(5).
Currently, the sip-proxy doesn't resolve domain names used in SIP messages and UA addresses. The DNS querying should slow down the proxy, too much.