Skip Headers
Oracle® Communications Converged Application Server Administration Guide
Release 5.0

Part Number E17647-03
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

22 Production Network Architectures and Configuration

This chapter describes common network architectures used in production deployments, and explain how Oracle Communications Converged Application Server is configured to run in those architectures:


Most production (enterprise deployment) installations of Converged Application Server contain one or more of the following characteristics:

A combination of these network elements can make it difficult to understand how elements interact with one another, and how a particular combination of elements or configuration options affects the contents of a SIP message or transport protocol datagram.

The sections that follow attempt to describe common Converged Application Server network architectures and explain how servers are configured in each architecture. The sections also explain how information in SIP messages and transport datagrams is affected by each configuration. Figure 22-1 shows the typical Open Systems Interconnect (OSI) model layers that can be affected by different network configurations.

Figure 22-1 OSI Layers Affected by Converged Application Server Network Configuration

Surrounding text describes Figure 22-1 .

Layer 3 (Network) and Layer 4 (Transport) contain the source or destination IP address and port numbers for both outgoing and incoming transport datagrams. Layer 7 (Application) may also be affected because the SIP protocol specifies that certain SIP headers include addressing information for contacting the sender of a SIP message.

Single-NIC Configurations with TCP and UDP Channels

In a simple network configuration for a server having a single NIC, one or more network channels may be created to support SIP messages over UDP and TCP, or SIPS over TLS. It is helpful to understand how this simple configuration affects information in the OSI model, so that you can understand how more complex configurations involving multihomed hardware and load balancers affect the same information.

Figure 22-2 Single-NIC Network Channel Configuration

Surrounding text describes Figure 22-2 .

Figure 22-2 shows a single engine tier server instance with a single NIC. The server is configured with one network channel supporting SIP over UDP and TCP. (SIP channels always support both UDP and TCP transports; you cannot support only one of the two.) Figure 22-2 also shows two clients communicating with the server, one over UDP and one over TCP.

For the TCP transport, the outgoing datagram (delivered from Converged Application Server to the UA) contains the following information:

Incoming TCP datagrams (delivered from the UA to Converged Application Server) contain the following information:

For outgoing UDP datagrams, the OSI layer information contains the same information as with TCP transport. For incoming UDP datagrams, the OSI layer information is the same as TCP except in the case of incoming datagram Layer 4 information. For incoming UDP datagrams, Layer 4 contains either:

By default Converged Application Server allocates ports from the ephemeral port number range of the underlying operating system for outgoing UDP datagrams. Converged Application Server allows external connections to use an ephemeral point as the destination port number, in addition to the port number configured in the network channel. In other words, Converged Application Server automatically listens on all ephemeral ports that the server allocates. You can optionally disable Converged Application Server's use of ephemeral port numbers by specifying the following option when starting the server:


You can determine Converged Application Server's use of a particular ephemeral port by examining the server log file:

<Nov 30, 2005 12:00:00 AM PDT> <Notice> <WebLogicServer> <BEA-000202> <Thread "SIP Message Processor (Transport UDP)" listening on port 35993.>

Static Port Configuration for Outbound UDP Packets

Converged Application Server network channels provide a SourcePorts attribute that you can use to configure one or more static ports that a server uses for originating UDP packets.


Oracle does not recommend using the SourcePorts custom property in most configurations because it degrades performance. Configure the property only in cases where you must specify the exact ports that Converged Application Server uses to originate UDP packets.

To configure the SourcePorts property, use a JMX client such as WLST or directly modify a network channel configuration in config.xml to include the custom property. SourcePorts defines an array of port numbers or port number ranges. Do not include spaces in the SourcePorts definition; use only port numbers, hyphens ("-") to designate ranges of ports, and commas (",") to separate ranges or individual ports. See Example 22-1 for an example configuration.

Example 22-1 Static Port Configuration for Outgoing UDP Packets


Multihomed Server Configurations Overview

Engine tier servers in a production deployment frequently utilize multihomed server hardware, having two or more NICs. Multihomed hardware is typically used for one of the following purposes:

The configuration requirements and OSI layer information differ depending on the use of multihomed hardware in your system. When multiple NICs are used to provide redundant connections within a subnet, servers are generally configured to listen on all available addresses (IP_ANY) as described in "Multihomed Servers Listening On All Addresses (IP_ANY)".

When using multiple NICs to support different subnets, you must configure multiple network on the server for each different NIC as described in "Multihomed Servers Listening on Multiple Subnets".

Multihomed Servers Listening On All Addresses (IP_ANY)

The simplest multihome configuration enables a Converged Application Server instance to listen on all available NICs (physical NICs as well as logical NICs), sometimes described as IP_ANY. To accomplish this, you configure a single network channel and specify a channel listen address of

Note that you must configure the address directly on the server's network channel. If you specify no IP address in the channel, the channel inherits the listen address configured for the server instance itself. See "Configuring Engine Servers to Listen on Any IP Interface".

Multihomed Servers Listening on Multiple Subnets

Multiple NICs can also be used in engine tier servers to listen on multiple subnets. The most common configuration uses Converged Application Server to proxy SIP traffic from one subnet to another where no direct access between subnets is permitted. Figure 22-3 shows this configuration.

Figure 22-3 Multihomed Configuration for Proxying between Subnets

Surrounding text describes Figure 22-3 .

To configure the Converged Application Server instance in Figure 22-3 you must define a separate network channel for each NIC used on the server machine. Example 22-2 shows the config.xml entries that define channels for the sample configuration.

Example 22-2 Sample Network Channel Configuration for NICs on Multiple Subnets

<NetworkAccessPoint ListenAddress="" ListenPort="5060" Name="sipchannelA" Protocol="sip"/>
<NetworkAccessPoint ListenAddress="" ListenPort="5060" Name="sipchannelB" Protocol="sip"/>

Understanding the Route Resolver

When Converged Application Server is configured to listen on multiple subsets, a feature called the route resolver is responsible for the following activities:

  • Populating OSI Layer 7 information (SIP system headers such as Via, Contact, and so forth) with the correct address.

  • Populating OSI Layer 3 information with the correct source IP address.

For example, in the configuration shown in Figure 22-3, Converged Application Server must add the correct subnet address to SIP system headers and transport datagrams in order for each UA to continue processing SIP transactions. If the wrong subnet is used, replies cannot be delivered because neither UA can directly access the other UA's subnet.

The route resolver works by determining which NIC the operating system will use to send a datagram to a given destination, and then examining the network channel that is associated with that NIC. It then uses the address configured in the selected network channel to populate SIP headers and Layer 3 address information.

For example, in the configuration shown in Figure 22-3, an INVITE message sent from Converged Application Server to UAC B would have a destination address of The operating system would transmit this message using NIC B, which is configured for the corresponding subnet. The route resolver associates NIC B with the configured sipchannelB and embeds the channel's IP address ( in the VIA header of the SIP message. UAC B then uses the VIA header to direct subsequent messages to the server using the correct IP address. A similar process is used for UAC A, to ensure that messages are delivered only on the correct subnet.

IP Aliasing with Multihomed Hardware

IP aliasing assigns multiple logical IP addresses to a single NIC, and is configured in the underlying server operating system. If you configure IP aliasing and all logical IP addresses are within the same subnet, you can simply configure Converged Application Server to listen on all addresses as described in "Multihomed Servers Listening On All Addresses (IP_ANY)".

If you configure IP aliasing to create multiple logical IP addresses on different subnets, you must configure a separate network channel for each logical IP address. In this configuration, Converged Application Server treats all logical addresses as separate physical interfaces (NICs) and uses the route resolver to populate OSI Layer 4 and Layer 7 information based on the configured channel.

Load Balancer Configurations

In addition to providing failover capabilities and distributing the client load across multiple servers, a load balancer is also an important tool for configuring the network information transmitted between clients and servers. The sections that follow describe common load balancer configurations used with Converged Application Server.

Single Load Balancer Configuration

The most common load balancer configuration utilizes a single load balancer that gates access to a cluster of engine tier servers, as shown in Figure 22-4.

Figure 22-4 SIngle Load Balancer Configuration

Surrounding text describes Figure 22-4 .

To configure Converged Application Server for use with a single load balancer as in Figure 22-4, configure one or more network channels for each server, and configure the public address of each channel with the Virtual IP address of the load balancer. In this configuration, Converged Application Server embeds the load balancer IP address in SIP message system headers to ensure that clients can reach the cluster for subsequent replies. Chapter 21, "Managing Network Resources" presents detailed steps for configuring network channels with load balancer addresses.


Although some load balancing switches can automatically re-route all SIP messages in a given call to the same engine tier server, this functionality is not required with Converged Application Server installations. See "Alternate Configurations" in Chapter 1, "Overview of the Converged Application Server Architecture," for more information.

Multiple Load Balancers and Multihomed Load Balancers

Multiple load balancers (or a multihomed load balancer) can be configured to provide several virtual IP addresses for a single Converged Application Server cluster. To configure Converged Application Server for use with a multihomed load balancer, you create a dedicated network channel for each load balancer or local server NIC, and set the channel's public address to the virtual IP address of the appropriate load balancer. In this configuration, the route resolver associates a configured channel with the NIC used for originating SIP messages. The public address of the selected channel is then used for populating SIP system messages. See "Understanding the Route Resolver".

Network Address Translation Options

In the most common case, a load balancer is configured using destination NAT to provide a public IP address that clients use for communicating with one or more internal (private) Converged Application Server addresses. Load balancers may also be configured using source NAT, which modifies the Layer 3 address information originating from a private address to match the virtual IP address of the load balancer itself.

With the default route resolver behavior, an Converged Application Server engine originates UDP packets having a source IP address that matches the address of a local NIC (the private address). This can be problematic for applications that try to respond directly to the Layer 3 address embedded in the transport packet, because the local server address may not be publicly accessible. If your applications exhibit this problem, Oracle recommends that you configure the load balancer to perform source NAT to change the transport Layer 3 address to a publicly-accessible virtual IP address.

IP Masquerading Alternative to Source NAT

If you choose not to enable source NAT on your load balancer, Converged Application Server provides limited IP masquerading functionality. To use this functionality, configure a logical address on each engine tier server using the public IP address of the load balancer for the cluster. (Duplicate the same logical IP address on each engine tier server machine). When a local server interface matches the IP address of a configured load balancer (defined in the public address of a network channel), Converged Application Server uses that interface to originate SIP UDP messages, and the Layer 3 address contains a public address.


Using the Converged Application Server IP masquerading functionality can lead to network instability, because it requires duplicate IP addresses on multiple servers. Production deployments must use a load balancer configured for source NAT, rather than IP masquerading, to ensure reliable network performance.

You can disable IP masquerading functionality by using the startup option: