LanScape Centrex Proxy ServerŪ
The LanScape Centrex Proxy ServerŪ
Proxy Server Configuration
Backing up and restoring configuration information
Running Multiple Instances
Running the proxy server as a service
Proxy Plug-in API
Help File Version
The LanScape Centrex Proxy ServerŪ is an
enhanced and highly integrated SIP (Session Initiation Protocol) proxy
server. It has been developed to include a wide range of capabilities
that will simplify the deployment of SIP based VOIP telephony networks.
It is simple to install, configure and deploy on any version of 32 bit
Microsoft Windows operating systems. The LanScape Centrex Proxy ServerŪ
also functions seamlessly with LanScape's VOIP Media Proxy ServerŪ software
to enable you to deploy a fully functional, scalable SIP and RTP media
proxying solution. If you do not understand why there is a need to also
proxy RTP VOIP media streams, please read on. We will describe the reasons
The LanScape Centrex Proxy ServerŪ is primarily used to control and manage
SIP/RTP VOIP calls that enter and leave your specifically configured VOIP
domain. The LanScape Centrex Proxy ServerŪ can perform such tasks as user
authentication, call routing, registrar capabilities and control media
proxying/media stream management. These are just a few of the capabilities
you have at your disposal.
In addition, the LanScape Centrex Proxy ServerŪ allows you to deploy your
VOIP network with added security due to the fact that all call traffic
must pass through the proxy server and optionally be verified via MD5
challenge handshake authentication. A simple VOIP deployment can be as
small as one Centrex Proxy ServerŪ and one VOIP Media Proxy ServerŪ running
on a single machine. Larger deployments can use multiple Centrex Proxy
Servers and multiple VOIP Media Proxy Servers on individual host machines
all accessing the same registration database.
The list of capabilities the LanScape Centrex
Proxy ServerŪ can offer you is quite large and extensive. These capabilities
will be discussed below.
Currently all VOIP systems attempt to connect two or more call endpoints
(peers) that wish to interact with each other. This interaction involves
setting up calls, negotiating media exchange parameters and then finally
exchanging media streams (the voice path). When a VOIP phone call is over,
the call session must be "torn down" and the exchange of voice
media stream data terminated.
If you are new to deploying SIP based VOIP telephony networks, we have
additional information for you that you may not know. If you are a veteran
VOIP developer or a seasoned VOIP IT professional, then you already know
the inherent problems facing the deployment of VOIP networks in today's
IP4 network environment. Specifically, we are speaking of the hostile
nature of todays network environment to VOIP and the role that network
address translation (NAT) and port translation play in the deployment.
From this point forward, we will use the term NAT to represent network
address translation and port translation.
The session Initiation Protocol (SIP) is used to manage call setup and
termination as described above. The RTP protocol is used to exchange the
call's media stream (voice data). SIP is a very useful and relatively
simple protocol that is effective in establishing multimedia interchanges
(VOIP phone calls). However, the SIP protocol was developed without the
ability to overcome network addressing problems caused by NAT. In short,
NAT is the worst thing to happen to VOIP and the SIP protocol. The problems
introduced by NAT completely destroy the ability of call endpoints (peers)
to communicate without errors. It should be noted that the issues NAT
introduces is not specific to the SIP protocol and VOIP networks. The
same problems occur with any other peer to peer networking environment
that encode IP address information and UDP port information in the protocol
packets that are exchanged.
One way to overcome most of the problems NAT introduces is to use other
protocols to assist in discovering proper IP address and port information.
Notice that we have used the phrase "most of the problems".
There is a reason for this. Additional protocols and "NAT discovery
methods" such as STUN, TURN or ICE can be used to obtain this information.
Once this real address and port information is known, it is possible to
"spoof" or "alter" the information that gets placed
in SIP protocol packets. However, with the addition of these new protocols
and methods, comes additional complexity, additional points of failure
and it still does not solve the problems facing user's that deploy symmetrical
NAT routers in their network environment.
Other proprietary protocol schemes used by some companies or VOIP service
provider attempt to "get around" the problems introduced by
NAT. They employ proprietary signaling protocols and servers that allow
peer to peer connectivity to be achieved. However, this also has been
shown not to be a general solution. There are issues facing these proprietary
schemes such as the failure to interoperate with other VOIP networks.
There are also security risks. One such security risk is the use of protocols
that tunnel their VOIP traffic using the HTTP protocol. By using a tunneling
approach, network administrators no longer can treat normal HTTP web traffic
differently from VOIP signaling and media traffic. This is not desirable
in highly secure network environments.
To achieve a secure and general solution for all types of NAT devices that
on the "complexity scale" requires two basic components: A SIP
proxy and a media proxy. With these two network elements properly deployed,
it will not matter if call endpoints are in their own private networks
or in the global IP address space. It will also not matter what kind of
firewall or router the call endpoint are behind. The SIP proxy assists
the call endpoints in setting up and tearing down calls sessions and the
media proxy allows the call endpoints to exchange media securely. Using
this scenario will allow every SIP and RTP compliant application or device
to communicate. It should also be noted that the "media deadlock
problem" associated with deploying VOIP media proxies has been solved
when you deploy your VOIP network using LanScape SIP and media proxies.
For those individuals that argue that adding SIP and media proxies to the
VOIP deployment add an "additional point of failure", we say
this: redundancy. If you are deploying a 24x7 VOIP service and you require
99.9999% up time, plan your load sharing and redundancy architecture appropriately.
Compared to deploying additional protocols and servers to support STUN,
TURN and ICE for NAT resolution, you will still be faced with additional
"points of failure" and undue complexity. Also, we agree that
proxying media adds an extra "hop" to the media stream's network
path. However, we like the fact that all connectivity issues fade and
every SIP/RTP software application and device will work as expected.
LanScape's Centrex Proxy ServerŪ:
The graphic image below shows the user interface of the LanScape Centrex
There are three main areas to the user interface. The first area displays
current critical settings for the proxy such as IP address, WAN IP address,
the server port, etc. The second area of the user interface displays proxy
activity and is depicted above as the "Activity log area". In
this area, you will see all proxy activity as it happens real time. Through
the configuration dialogs, a user can enable or disable certain logging
information types. The third area of the user interface that is of interest
is the "Runtime Statistics" bar. The information that is displayed
there gives you an indication relative to the current registration and
call rates in addition to max number of registrations and calls that have
been processed since the proxy server was started.
List of Capabilities
The following categories will assist you in understanding the capabilities
of the LanScape Centrex Proxy ServerŪ:
The following network capabilities are available to you: Specify your VOIP
domain name. Specify the server's IP address and port. Configure your
outermost router/gateway IP address. Configure the maximum allowed size
of received SIP messages. Enable or disable denial of service attack protection.
Note that the Centrex Proxy ServerŪ uses symmetrical signaling to assist
in overcoming NAT related issues. Symmetrical signaling is just a fancy
way of saying the Centrex Proxy ServerŪ sends and receives SIP protocol
packets using the same configured UDP port.
Call Processing Timeouts:
Allows you to configure call processing timeouts for call operations such
as call rollover, call start response and final call answer.
Local User Directory:
The LanScape Centrex Proxy ServerŪ allows you to configure static registered
user names or extensions so that they always appear in the registry database.
In this way, you can configure call routing based on these static names.
If a call is received by the proxy, it will attempt to apply a user defined
call routing plan and route the call. Also SIP devices that can receive
registry notifications can display local directory information that is
the result of configuring the local directory.
The LanScape Centrex Proxy ServerŪ allows you to configure call routing
lists for any number of registered users. When a phone call is received
by the proxy, it determines the destination of the call and looks up the
call routing plan for the user name (or phone extension). If a call routing
plan is not defined, the call is sent on to the call destination if the
call destination is registered. If a route plan is found, the proxy will
ring all call destinations sequentially in the route list until the call
is answered or the maximum call processing timeout is reached. Call routing
definitions can also use regular expression syntax so you can generically
forward any type of call to a specific destination like a PSTN gateway.
Global iNetŪ Account Support:
If you have key individuals or employees in your organization, you can
purchase optional Global iNetŪ user accounts and allow them to obtain
a directory listing in the Global iNetŪ phone system. The proxy logs in
any configured Global iNetŪ user automatically when it starts. This way,
other Global iNetŪ user can search the online directory server database
via your company name, your last name or whatever and call you. Global
iNetŪ is supported by this proxy server and all LanScape soft phones.
Full control over one or more LanScape VOIP Media Proxy Servers:
To obtain a complete VOIP connectivity solution, the LanScape Centrex Proxy
ServerŪ can control one or more LanScape VOIP Media Proxy servers. The
Centrex Proxy ServerŪ communicates with the media proxies and assigns
media streams to one of the available media proxies via a load sharing
algorithm. All active call media streams will be divided equally among
all available media proxies. LanScape VOIP Media Proxy solutions also
overcome the common "media proxy deadlock issue" most media
proxies are faced with. Communications with subordinate media proxies
are authenticated using an MD5 challenge algorithm for added security.
Full registrar database support:
Full registrar database support using LanScape's integrated (very fast)
registrar database capability or an external registrar database using
any database type you require (Microsoft Access, SQL, Open source MySql,
etc). The only requirement for external registrar database is to have
proper ODBC drivers installed on the host machine. Sharing a registrar
database among multiple Centrex Proxy Servers requires that an external
registrar database be used.
Integrated WAN IP address detection and discovery:
To be useful in the most arcane circumstances, the LanScape Centrex Proxy
ServerŪ can be configured to determine its WAN IP address using: DNS and
a configured domain name, by specifying a static WAN IP address or by
dynamically monitoring your WAN IP address using HTTP requests to a web
server or router configuration page.
Custom DLL Plug-in Interface:
The LanScape Centrex Proxy ServerŪ can use a user supplied plug-in DLL
that it accesses at runtime. With this simple plug-in interface, you have
the ability to alter any incoming or outgoing SIP message the proxy receives
or transmits. The example plug-in that is supplied with the proxy server
gives you a starting point. It include source code and performs realtime
SIP protocol logging to the Sip Log Server application. The Sip Log Server
application is part of your software distribution.
SIP Proxy event log control:
Enable or disable the types of events the Centrex Proxy ServerŪ reports
on its user interface.
SIP protocol logging:
Enable or disable SIP protocol logging to a log file of your choice.
Complete challenge handshake authentication using the MD5 algorithm:
For the most secure VOIP networks, the LanScape Centrex Proxy ServerŪ supports
encrypted authentication using the MD5 algorithm. You have the ability
to configure when authentication should be applied to specific SIP message
types. You can control authentication of the following SIP messages: REGISTER,
INVITE, BYE, SUBSCRIBE and NOTIFY. Using a single authentication "realm"
you can assign one or more login names and password pairs. In this way,
you can authenticate a whole group of users using the same login and password
or authenticate each individual VOIP user by assigning them their own
user name and password.