At Your Service
June 2001

Jonathan Rosenberg Selecting The Right SIP Proxy Server

BY JONATHAN ROSENBERG


The technology community has adopted the term "proxy" to refer to any software or hardware agent that acts on behalf of another. In fact, "proxy" is now used so widely -- often without any context -- that it no longer has meaning. A quick search turned up references to HTTP proxies, address resolution protocol (ARP) proxies, simple network management protocol (SNMP) proxies, and last but not least, session initiation protocol (SIP) proxies.

The Internet Engineering Task Force (IETF) SIP specification defines many details about the behavior of a SIP proxy -- how it processes a request it receives, how it forwards that request, and how it processes the responses it gets. However, the specification emphasizes that a proxy is just a logical function that an actual piece of software or hardware executes. When you go out into the market and buy a "proxy server," you get much more than simply a logical function. There is a world of difference between the proxy server functionality specified by the SIP standard and a proxy server product that's deployed into a service provider's network.

There are two important aspects to this difference between the SIP proxy server specification and real products designed for carrier networks. The first is the support infrastructure that must be present in the product; the second is the specific set of features related to exactly where and how a proxy is used in a network.

Support Infrastructure
Support infrastructure refers to all of the server components required to run, manage, maintain, operate, and actually use a proxy in a live SIP-based network. Manageability is an important aspect: operators need to be able to monitor the status of the server, receive notifications when failures or error conditions occur, and configure the server when needed. This job is complicated by the fact that management is handled in many different ways. Some operators prefer SNMP, some prefer command line interfaces (CLI), and some prefer GUI tools. Further, management is more complex in a network with multiple homogeneous instances of a server (for load balancing and fault tolerance purposes). In such a case, the server's management capabilities need to allow an operator to set a parameter once and have it reflected in each server.

Another aspect of support infrastructure is scalability; the operator should be able to see a linear increase in system capacity as more servers are added to the system. Additionally, a SIP proxy server needs to provide failure detection and recovery so that a single server failure does not cause an interruption in service. Finally, the server needs to reliably provide extensive logging and event reporting capabilities to facilitate troubleshooting and bill generation.

Network Element
Perhaps more importantly, a proxy server needs to be viewed as one element in a complete network design. Like any network element, a proxy exists to provide a specific set of functions, which are best encapsulated into a discrete element. For example, an IP network consists of, in principle, just routers. However, there are many different types of routers -- edge routers, border routers, core routers, and access routers. Each of these provides the same basic IP packet-forwarding logic, but differs substantially in the features and functions surrounding that logic. Many companies offer one type of router, but not the others.

The same pattern holds true for a VoIP network, which contains many elements that provide the functionality to deliver services. At dynamicsoft, we have developed the Service Delivery Architecture, our vision of how converged communications networks will develop. In this architecture, there are many different types of proxy servers -- access proxies, edge proxies, firewall control proxies, core proxies, and user feature proxies. Each plays a distinct role in a SIP network architecture.

Edge Proxy
Let's take a closer look at the roles of these specialized SIP proxy servers. An edge proxy (EP) sits at the edge of a wholesale provider, or carrier, network. It represents the one and only server facing the public Internet. It is the sole point of contact for communications application service providers (ASPs) who send SIP traffic to the service provider. Because of this role, an edge proxy needs to provide extensive security and accounting capabilities. It must support secure VoIP connections (using protocols like SSL) between the communications ASP and the provider.

It needs to mask the internal addresses of proxy servers and gateways to prevent attacks on the signaling network. It needs to support access lists that control which customers can gain access to the network. It needs to communicate with billing servers to record the call details from each customer. Additional security functions, such as message validation and call rate limiting, will also occur at an edge proxy. Edge proxies do not require a great deal of routing logic. When an EP completes processing of an incoming call, that call is forwarded to a firewall control proxy.

Firewall Control Proxy
A firewall control proxy (FCP) is responsible for manipulating rules in a firewall or network address translator (NAT), which allow authorized media to enter and exit a service provider network. To do this, it inspects (and possibly manipulates) the fields of SIP and SDP messages, using a control protocol to pass instructions to the firewall or NAT. Because of its control capabilities, the FCP needs to remain isolated from the public Internet -- which is precisely why a separate edge proxy is needed. When an FCP has completed its processing, it forwards the message to the core proxy.

Core Proxy
A core proxy (CP) represents the central routing intelligence in a service provider's network. When a call arrives at the network, it may need to be routed to a set of gateways, to a specific customer, to an application server farm, to a media server, or to a voicemail system. The top-level routing decision for all calls takes place at the core proxy. As a result, flexibility in routing logic and performance are the primary requirements for a core proxy.

User Feature Proxy
The user feature proxy (UFP) is responsible for routing calls to end users. The UFP receives SIP registration messages from end users and stores their contact information in a database. It is responsible for managing that data and timing it out if the user doesn't refresh it. An incoming call arrives at the UFP, and the registration data is used to route the call to the end user. The proxy may also authenticate calls from end users, making sure they are authorized before permitting them to make outgoing calls. A UFP will also provide some basic calling features such as call forwarding and call screening. These can be provided using a call processing language (CPL) script, an XML-based language specified by the IETF.

Access Proxy
Finally, there are access proxies (AP). An access proxy is the peer of an edge proxy, but it sits in the communications ASP domain rather than the service provider's network. When an end user makes a call to a phone number on the public switched telephone network (PSTN), the UFP will route the call to the access proxy. The access proxy determines which provider will terminate the call, based on various factors such as cost. As a result, it needs to support flexible least-cost routing tables. It maintains secure persistent connections with its providers. The AP generates extensive call logging data so it can verify bills from service providers.

Conclusion
So, the next time you're selecting a SIP proxy server, ask yourself: what type of proxy server does my network implementation require? Is it an edge proxy, firewall control proxy, core proxy, user feature proxy, or access proxy? The specific implementation, a proxy's features and performance, and a vendor's reputation and record of deployments are all factors you should take into account as you make this important decision. Remember: just because a product is called a "proxy" doesn't mean it's the right one for the job at hand.

Jonathan Rosenberg is chief scientist at dynamicsoft, Inc. For more information, please visit the company's Web site.

[ Return To The June 2001 Table Of Contents ]