4 Managing Network Resources

The following sections describe how to configure network resources for use with Oracle WebLogic Communication Services:

4.1 Overview of Network Configuration

The default HTTP network configuration for each Oracle WebLogic Communication Services instance is determined from the Listen Address and Listen Port setting for each server. However, Oracle WebLogic Communication Services does not support the SIP protocol over HTTP. The SIP protocol is supported over the UDP and TCP transport protocols. SIPS is also supported using the TLS transport protocol.

To enable UDP, TCP, or TLS transports, you configure one or more network channels for a Oracle WebLogic Communication Services instance. A network channel is a configurable WebLogic Server resource that defines the attributes of a specific network connection to the server instance. Basic channel attributes include:

  • The protocols supported by the connection

  • The listen address (DNS name or IP address) of the connection

  • The port number used by the connection

  • (optional) The port number used by outgoing UDP packets

  • The public listen address (load balancer address) to embed in SIP headers when the channel is used for an outbound connection.

You can assign multiple channels to a single Oracle WebLogic Communication Services instance to support multiple protocols or to utilize multiple interfaces available with multi-homed server hardware. You cannot assign the same channel to multiple server instances.

When you configure a new network channel for the SIP protocol, both the UDP and TCP transport protocols are enabled on the specified port. You cannot create a SIP channel that supports only UDP transport or only TCP transport. When you configure a network channel for the SIPS protocol, the server uses the TLS transport protocol for the connection.

As you configure a new SIP Server domain, you will generally create multiple SIP channels for communication to each engine tier server in your system. Engine tier servers can communicate to SIP data tier replicas using the configured Listen Address attributes for the replicas. Note, however, that replicas must use unique Listen Addressees in order to communicate with one another.

Note:

If you configure multiple replicas in a SIP data tier cluster, you must configure a unique Listen Address for each server (a unique DNS name or IP address). If you do not specify a unique Listen Address, the replica service binds to the default localhost address and multiple replicas cannot locate one another.

4.1.1 IPv4 and IPv6

If your operating system and hardware support IPv6, you can also configure Oracle WebLogic Communication Services to use IPv6 for network communication. IPv6 for SIP traffic is enabled by configuring a network channel with an IPv6 address. You must configure an IPv6 SIP channel on each engine tier server that will support IPv6 traffic. See Section 4.4.2, "Creating a New SIP or SIPS Channel" for instructions.

Note that each SIP network channel configured on an engine supports either IPv6 or IPv4 traffic. You cannot mix IPv4 and IPv6 traffic on a single channel. A single engine can be configured with both an IPv4 and IPv6 channel to support multiple, separate networks.

It is also possible for Oracle WebLogic Communication Services engine and SIP data tier nodes to communicate on IPv4 (or IPv6) while supporting the other protocol version for external SIP traffic. To configure engine and SIP data tier nodes on an IPv6 network, simply specify IPv6 listen addresses for each server instance.

See Section 4.4.2, "Creating a New SIP or SIPS Channel" for information about configuring IPv4 and IPv6 network channels.

4.2 Configuring Load Balancer Addresses

If your system uses one or more load balancers to distribute connections to the engine tier, you must configure SIP network channels to include a load balancer address as the external listen address. When a SIP channel has an external listen address that differs from the channel's primary listen address, Oracle WebLogic Communication Services embeds the host and port number of the external address in SIP headers such as Response. In this way, subsequent communication for the call is directed to the public load balancer address, rather than the local engine tier server address (which may not be accessible to external clients).

If a network channel does not have a configured external listen address, the primary listen address is embedded into SIP headers.

4.2.1 Multiple Load Balancers and Multi-homed Load Balancers

If your system uses two load balancers, you must define two channels on each engine tier server (one for each network connection to each load balancer) and assign the external listen address to the corresponding load balancer. When a particular network interface on the engine tier server is selected for outbound traffic, the network channel associated with that Network Interface Card's (NIC) address is examined to determine the external listen address to embed in SIP headers.

If your system uses a multi-homed load balancer having two public addresses, you must also define a pair of channels to configure both public addresses. If the engine tier server has only one NIC, you must define a second, logical address on the NIC to configure a dedicated channel for the second public address. In addition, you must configure your IP routing policies to define which logical address is associated with each public load balancer address.

4.3 Enabling Domain Name Service (DNS) Support

Oracle WebLogic Communication Services supports multi-home for resolving the transport, IP address and port number of a proxy required to send a SIP message. This matches the behavior described in RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt). multi-home may also used when routing responses in order to resolve the IP address and port number of a destination.

Note:

Because multi-home resolution is performed within the context of SIP message processing, any multi-home performance problems result in increased latency. Oracle recommends using a caching multi-home server in a production environment to minimize potential performance problems.

To configure multi-home support:

  1. Log in to the Administration Console for the Oracle WebLogic Communication Services domain you want to configure.

  2. Select the SipServer node in the left pane of the Console.

  3. Select the Configuration > General tab in the right pane.

  4. Select Enable multi-home Server Lookup.

  5. Click Save to save your changes.

When you enable multi-home lookup, the server can use multi-home to:

  • Discover a proxy server's transport, IP address, and port number when a request is sent to a SIP URI.

  • Resolve an IP address and/or port number during response routing, depending on the contents of the Sent-by field.

For proxy discovery, Oracle WebLogic Communication Services uses multi-home resolution only once per SIP transaction to determine transport, IP, and port number information. All retransmissions, ACKs, or CANCEL requests are delivered to the same address and port using the same transport. For details about how multi-home resolution takes place, see RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt).

When a proxy is required to send a response message, Oracle WebLogic Communication Services uses multi-home lookup to determine the IP address and/or port number of the destination, depending on the information provided in the Sent-by field and through header.

4.4 Configuring Network Channels for SIP or SIPS

When you create a new domain using the Configuration Wizard, Oracle WebLogic Communication Services instances are configured with a default network channel supporting the SIP protocol over UDP and TCP. This default channel is configured to use Listen Port 5060, but specifies no Listen Address. Follow the instructions in Section 4.4.1, "Reconfiguring an Existing Channel" to change the default channel's listen address or listen port settings. See Section 4.4.2, "Creating a New SIP or SIPS Channel" to create a new channel resource to support additional protocols or additional network interfaces.

4.4.1 Reconfiguring an Existing Channel

You cannot change the protocol supported by an existing channel. To reconfigure an existing listen address/port combination to use a different network protocol, you must delete the existing channel and create a new channel using the instructions in Section 4.4.2, "Creating a New SIP or SIPS Channel".

To configure a channel:

  1. Log in to the Administration Console for the Oracle WebLogic Communication Services domain you want to configure.

  2. In the left pane, select the Environment > Servers tab.

  3. In the right pane, select the name of the server you want to configure.

  4. Select the Protocols > Channels tab to display the configured channels.

  5. To delete an existing channel, select it in the table and click Delete.

  6. To reconfigure an existing channel:

    1. Select the channel's name from the channel list (for example, the default sip channel).

    2. Edit the Listen Address or Listen Port fields to correspond to the address of a NIC or logical address on the associated engine tier machine.

      Note:

      The channel must be disabled before you can modify the listen address or listen port.
    3. Edit the External Listen Address or External Listen Port fields to match the public address of a load balancer in the system.

    4. Edit the advanced channel attributes as necessary (see Section 4.4.2, "Creating a New SIP or SIPS Channel" for details.)

  7. Click Save.

4.4.2 Creating a New SIP or SIPS Channel

To create a new SIP or SIPS channel to the configuration of a Oracle WebLogic Communication Services instance:

  1. Log in to the Administration Console for the Oracle WebLogic Communication Services domain you want to configure.

  2. In the left pane, select the Environment > Servers tab.

  3. In the right pane, select the name of the server you want to configure.

  4. Select the Protocols > Channels tab to display the configured channels.

  5. Click New to configure a new channel.

  6. Fill in the new channel fields as follows:

    • Name: Enter an administrative name for this channel, such as SIPS-Channel-eth0.

    • Protocol: Select either SIP to support UDP and TCP transport, or SIPS to support TLS transport. Note that a SIP channel cannot support only UDP or only TCP transport on the configured port.

  7. Click Next.

  8. Fill in the new channel's addressing fields as follows:

    • Listen Address: Enter the IP address or multi-home name for this channel. On a multi-homed machine, enter the exact IP address of the interface you want to configure, or a multi-home name that maps to the exact IP address.

    • Listen Port: Enter the port number used to communicate through this channel. The combination of Listen Address and Listen Port must be unique across all channels configured for the server. SIP channels support both UDP and TCP transport on the configured port.

    • External Listen Address and External Listen Port: Edit these fields to match the public address of a load balancer associated with this channel. When the server selects an interface or logical address to use for outbound network traffic, Oracle WebLogic Communication Services examines the channel that was configured with the same primary Listen Address; if the External Listen Address of this channel differs, the external address is embedded into SIP message headers for further call traffic. See Section 4.2, "Configuring Load Balancer Addresses".

  9. Click Next.

  10. Optionally click Show to display and edit advanced channel properties, such as connection timeout values. Keep in mind the following restrictions and suggestions for advanced channel properties:

    • Outbound Enabled—This attribute cannot be unchecked, because all SIP and SIPS channels can originate network connections.

    • HTTP Enabled for This Protocol—This attribute cannot be selected for SIP and SIPS channels, because Oracle WebLogic Communication Services does not support HTTP transport SIP protocols.

    • Maximum Message Size—This attribute specifies the maximum TCP message size that the server allows on a connection from this channel. Oracle WebLogic Communication Services shuts off any connection where the messages size exceeds the configured value. The default size of 10,000,000 bytes is large. If you are concerned about preventing Denial Of Service (DOS) attacks against the server, reduce this attribute to a value that is compatible with your deployed services.

  11. Click Finish.

4.4.3 Configuring Custom Timeout, MTU, and Other Properties

SIP channels can be further configured using one or more custom channel properties. The custom properties cannot be set using the Administration Console. Instead, you must use a text editor to add the properties to a single, custom-property stanza in the channel configuration portion of the config.xml file for the domain.

Oracle WebLogic Communication Services provides the following custom properties that affect the transport protocol of SIP channels:

  • TcpConnectTimeoutMillis—Specifies the amount of time Oracle WebLogic Communication Services waits before it declares a destination address (for an outbound TCP connection) as unreachable. The property is applicable only to SIP channels; Oracle WebLogic Communication Services ignores this attribute value for SIPS channels. A value of 0 disables the timeout completely. A default value of 3000 milliseconds is used if you do not specify the custom property.

  • SctpConnectTimeoutMillis—Specifies the amount of time Oracle WebLogic Communication Services waits before it declares a destination address (for an outbound SCTP connection) as unreachable. The property is applicable only to SCTP channels (for Diameter traffic). A value of 0 disables the timeout completely. A default value of 3000 milliseconds is used if you do not specify the custom property. See Section 4.8.1.1, "Static Port Configuration for Outbound UDP Packets" for information about creating SCTP channels for Diameter.

  • SourcePorts—Configures one or more static port numbers that a server uses for originating UDP packets.

    Caution:

    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 Oracle WebLogic Communication Services uses to originate UDP packets.
  • Mtu—Specifies the Maximum Transmission Unit (MTU) value for this channel. A value of -1 uses the default MTU size for the transport.

  • EnabledProtocolVersions—Specifies the version of the SSL protocol to use with this channel when Oracle WebLogic Communication Services acts as an SSL client. When acting as an SSL client, by default the channel requires TLS V1.0 as the supported protocol. The server can be configured to use SSL V3.0 as well, if that is the highest version that the SSL peer servers support. You can set one of the following values for this property:

    • TLS1, the default, configures the channel to send and accept only TLS V1.0 messages. Peers must respond with a TLS V1.0 message, or the SSL connection is dropped.

    • SSL3 configures the channel to send and accept only SSL V3.0 messages. Peers must respond with an SSL V3.0 message, or the SSL connection is dropped.

    • ALL supports either TLS V1.0 or SSL V3.0 messages. Peers must respond with a TLS V1.0 or SSL V3.0 message, or the SSL connection is dropped.

To configure a custom property, use a text editor to modify the config.xml file directly, or use a JMX client such as WLST to add the custom property. When editing config.xml directly, ensure that you add only one custom-properties element to the end of a channel's configuration stanza. Separate multiple custom properties within the same element using semicolons (;) as shown in Example 4-1.

Example 4-1 Setting Custom Properties

<network-access-point>
  <name>sip</name>
  <protocol>sip</protocol>
  <listen-port>5060</listen-port>
  <public-port>5060</public-port>
  <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
  <tunneling-enabled>false</tunneling-enabled>
  <outbound-enabled>true</outbound-enabled>
  <enabled>true</enabled>
  <two-way-ssl-enabled>false</two-way-ssl-enabled>
  <client-certificate-enforced>false</client-certificate-enforced>
  <custom-properties>EnabledProtocolVersions=ALL;Mtu=1000;SourcePorts=5060</custom-properties>
</network-access-point>

4.4.4 Configuring SIP Channels for Multi-Homed Machines

If you are configuring a server that has multiple network interfaces (a multi-homed server), you must configure a separate network channel for each IP address used by Oracle WebLogic Communication Services. Oracle WebLogic Communication Services uses the listen address and listen port values for each channel when embedding routing information into SIP message system headers.

Note:

If you do not configure a channel for a particular IP address on a multi-homed machine, that IP address cannot be used when populating Via, Contact, and Record-Route headers.

4.5 Configuring TCP and TLS Channels for Diameter Support

The Oracle WebLogic Communication Services Diameter implementation supports the Diameter protocol over the TCP or TLS transport protocols. To enable incoming Diameter connections on a server, you configure a dedicated network channel using the protocol type diameter for TCP transport, or diameters for both TCP and TLS transport. The Diameter implementation application may automatically upgrade Diameter connections to use TLS as described in the Diameter specification (RFC 3558).

See Chapter 10, "Configuring Diameter Client Nodes and Relay Agents" for more information about configuring network channels for Diameter protocol support.

4.6 Configuring Engine Servers to Listen on Any IP Interface

To configure Oracle WebLogic Communication Services to listen for UDP traffic on any available IP interface, create a new SIP channel and specify 0.0.0.0 (or :: for IPv6 networks) as the listen address. Note that you must still configure at least one additional channel with an explicit IP address to use for outgoing SIP messages. (For multi-homed machines, each interface used for outgoing messages must have a configured channel.)

Note:

If you configure a SIP channel without specifying the channel listen address, but you do configure a listen address for the server itself, then the SIP channel inherits the server listen address. In this case the SIP channel does not listen on IP_ANY.

Note:

Using the 0.0.0.0 configuration affects only UDP traffic on Linux platforms. Oracle WebLogic Communication Services only creates TCP and HTTP listen threads corresponding to the configured host name of the server, and localhost. If multiple addresses are mapped to the host name, Oracle WebLogic Communication Services displays warning messages upon startup. To avoid this problem and listen on all addresses, specify the :: address, which encompasses all available addresses for both IPv6 and IPv4 for HTTP and TCP traffic as well.

4.7 Configuring Unique Listen Address Attributes for SIP Data Tier Replicas

Each replica in the SIP data tier must bind to a unique Listen Address attribute (a unique multi-home name or IP address) in order to contact one another as peers. Follow these instructions for each replica to assign a unique Listen Address:

  1. Access the Administration Console for the Oracle WebLogic Communication Services domain.

  2. Select Environment > Servers from the left pane.

  3. In the right pane, select the name of the server to configure.

  4. Select the Configuration > General tab.

  5. Enter a unique DNS name or IP address in the Listen Address field.

  6. Click Save.

4.8 Production Network Architectures and Configuration

Most production (Enterprise Deployment) installations of Oracle WebLogic Communication Services contain one or more of the following characteristics:

  • Multiple engine tier servers arranged in a cluster.

  • Multiple network channels per engine tier server instance, in support of multiple SIP transport protocols or multiple Network Interface Cards (NICs) on multi-homed hardware.

  • One or more load balancers, or a multi-homed load balancer, performing server failover and possibly Network Address Translation (NAT) for source or destination network packets.

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 Oracle WebLogic Communication Services 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 4-1 shows the typical Open Systems Interconnect (OSI) model layers that can be affected by different network configurations.

Figure 4-1 OSI Layers Affected by Oracle WebLogic Communication Services Network Configuration

Description of Figure 4-1 follows
Description of "Figure 4-1 OSI Layers Affected by Oracle WebLogic Communication Services Network Configuration"

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.

4.8.1 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 multi-homed hardware and load balancers affect the same information.

Figure 4-2 Single-NIC Network Channel Configuration

Description of Figure 4-2 follows
Description of "Figure 4-2 Single-NIC Network Channel Configuration"

Figure 4-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 4-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 Oracle WebLogic Communication Services to the UA) contains the following information:

  • Layer 3 includes the source IP address specified by the network channel (10.1.1.10 in the example above).

  • Layer 4 includes the source port number allocated by the underlying operating system.

Incoming TCP datagrams (delivered from the UA to Oracle WebLogic Communication Services) contain the following information:

  • Layer 3 includes the destination IP address specified by the network channel (10.1.1.10).

  • Layer 4 contains the destination port number specified by the network channel (5060).

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:

  • The destination port number specified by the network channel (5060), or

  • The ephemeral port number previously allocated by Oracle WebLogic Communication Services.

By default Oracle WebLogic Communication Services allocates ports from the ephemeral port number range of the underlying operating system for outgoing UDP datagrams. Oracle WebLogic Communication Services 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, Oracle WebLogic Communication Services automatically listens on all ephemeral ports that the server allocates. You can optionally disable Oracle WebLogic Communication Services's use of ephemeral port numbers by specifying the following option when starting the server:

-Dwlss.udp.listen.on.ephemeral=false

You can determine Oracle WebLogic Communication Services'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.>

4.8.1.1 Static Port Configuration for Outbound UDP Packets

Oracle WebLogic Communication Services 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.

Caution:

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 Oracle WebLogic Communication Services 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 4-2 for an example configuration.

Example 4-2 Static Port Configuration for Outgoing UDP Packets

<network-access-point>
  <name>sip</name>
  <protocol>sip</protocol>
  <listen-port>5060</listen-port>
  <public-port>5060</public-port>
  <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
  <tunneling-enabled>false</tunneling-enabled>
  <outbound-enabled>true</outbound-enabled>
  <enabled>true</enabled>
  <two-way-ssl-enabled>false</two-way-ssl-enabled>
  <client-certificate-enforced>false</client-certificate-enforced>
  <custom-properties>SourcePorts=5060</custom-properties>
</network-access-point>

4.8.2 Multi-homed Server Configurations Overview

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

  • To provide redundant network connections within the same subnet. Having multiple NICs ensures that one or more network connections are available to communicate with SIP data tier servers or the Administration Server, even if a single NIC fails.

  • To support SIP communication across two or more different subnets. For example Oracle WebLogic Communication Services may be configured to proxy SIP requests from UAs in one subnet to UAs in a second subnet, when the UAs cannot directly communicate across subnets.

The configuration requirements and OSI layer information differ depending on the use of multi-homed 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 Section 4.8.3, "Multi-homed 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 Section 4.8.4, "Multi-homed Servers Listening on Multiple Subnets".

4.8.3 Multi-homed Servers Listening On All Addresses (IP_ANY)

The simplest multi-home configuration enables a Oracle WebLogic Communication Services 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 0.0.0.0.

Note that you must configure the 0.0.0.0 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 Section 4.6, "Configuring Engine Servers to Listen on Any IP Interface".

4.8.4 Multi-homed 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 Oracle WebLogic Communication Services to proxy SIP traffic from one subnet to another where no direct access between subnets is permitted. Figure 4-3 shows this configuration.

Figure 4-3 Multi-homed Configuration for Proxying between Subnets

Description of Figure 4-3 follows
Description of "Figure 4-3 Multi-homed Configuration for Proxying between Subnets"

To configure the Oracle WebLogic Communication Services instance in Figure 4-3 you must define a separate network channel for each NIC used on the server machine. Example 4-3 shows the config.xml entries that define channels for the sample configuration.

Example 4-3 Sample Network Channel Configuration for NICs on Multiple Subnets

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

4.8.4.1 Understanding the Route Resolver

When Oracle WebLogic Communication Services 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 4-3, Oracle WebLogic Communication Services 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 4-3, an INVITE message sent from Oracle WebLogic Communication Services to UAC B would have a destination address of 10.2.1.16. 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 (10.2.1.10) 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.

4.8.4.2 IP Aliasing with Multi-homed 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 Oracle WebLogic Communication Services to listen on all addresses as described in Section 4.8.3, "Multi-homed 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, Oracle WebLogic Communication Services 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.

4.8.5 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 Oracle WebLogic Communication Services.

4.8.5.1 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 4-4.

Figure 4-4 SIngle Load Balancer Configuration

Description of Figure 4-4 follows
Description of "Figure 4-4 SIngle Load Balancer Configuration"

To configure Oracle WebLogic Communication Services for use with a single load balancer as in Figure 4-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, Oracle WebLogic Communication Services embeds the load balancer IP address in SIP message system headers to ensure that clients can reach the cluster for subsequent replies. Chapter 4, "Managing Network Resources" presents detailed steps for configuring network channels with load balancer addresses.

Note:

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 Oracle WebLogic Communication Services installations. See Section 15.7, "Alternate Configurations" for more information.

4.8.5.2 Multiple Load Balancers and Multi-homed Load Balancers

Multiple load balancers (or a multi-homed load balancer) can be configured to provide several virtual IP addresses for a single Oracle WebLogic Communication Services cluster. To configure Oracle WebLogic Communication Services for use with a multi-homed 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 Section 4.8.4.1, "Understanding the Route Resolver".

4.8.5.3 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) Oracle WebLogic Communication Services 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 Oracle WebLogic Communication Services 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.

4.8.5.3.1 IP Masquerading Alternative to Source NAT

If you choose not to enable source NAT on your load balancer, Oracle WebLogic Communication Services 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), Oracle WebLogic Communication Services uses that interface to originate SIP UDP messages, and the Layer 3 address contains a public address.

Caution:

Using the Oracle WebLogic Communication Services 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:

-Dwlss.udp.lb.masquerade=false

4.9 Example Network Configuration

Oracle WebLogic Communication Services is compatible with load balancers that are not SIP-aware, meaning that they do not consider existing SIP dialogues when routing requests to servers. This document demonstrates load balancer and Oracle WebLogic Communication Services configuration, as well as SIP and Network Address Translation (NAT) interactions in various configurations.

The following sections describe a sample network configuration for Oracle WebLogic Communication Services using a non-SIP-aware load balancer:

For more information about implementation-dependent issues surrounding NAT see the IETF document, NAT Behavioral Requirements for Unicast UDP at http://tools.ietf.org/wg/behave/draft-ietf-behave-nat-udp/.

4.9.1 Example Network Topology

Figure 4-5 shows the sample network topology described in this section. An Oracle WebLogic Communication Services cluster, consisting of engines WLSS 1 and WLSS 2, is configured on private IP network 10.1/16 (an internal 16-bit subnet). The cluster's public IP address is 1.2.3.4, which is the virtual IP address configured on the load balancer.

The User Agent, UAC A, with IP address 2.3.4.5 never sees the internal IP addresses configured for the Oracle WebLogic Communication Services cluster. Instead, it sends requests to, and receives responses from 1.2.3.4.

The sections that follow discuss configuring the Oracle WebLogic Communication Services cluster and load balancer for this example system.

Figure 4-5 Example Network Topology

Description of Figure 4-5 follows
Description of "Figure 4-5 Example Network Topology"

4.9.2 Oracle WebLogic Communication Services Configuration

The Oracle WebLogic Communication Services cluster configuration specifies the public address as 1.2.3.4, and the public port as 5060 (see Section 4.2, "Configuring Load Balancer Addresses") for each engine. The default route on both Oracle WebLogic Communication Services engines points to the load balancer's 10.1/16 network interface: 10.1.3.4. The Oracle WebLogic Communication Services (servers WLSS 1 and WLSS 2) routing table is shown in Example 4-4.

Example 4-4 Oracle WebLogic Communication Services Routing Table

$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0           *            255.255.0.0     U     0      0        0 eth0
default         10.1.3.4        0.0.0.0         UG    0      0 

4.9.3 Load Balancer Configuration

The load balancer is configured with a virtual IP address of 1.2.3.4, and two real servers, WLSS 1 and WLSS 2, having addresses 10.1.1.1 and 10.1.1.2, respectively. The load balancer also has an internal IP address of 10.1.3.4 configured on the 10.1/16 network. The UAC address, 2.3.4.5, is reachable from the load balancer by static route configuration on the load balancer. The load balancer routing table is shown in Example 4-5.

Example 4-5 Load balancer Routing Table

$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0           *            255.255.0.0     U     0      0        0 eth1
1.2.0.0            *            255.255.0.0     U     0      0 

Because the SIP protocol specification (RFC 3261) dictates the destination IP address and UDP port numbers that user agents must use when sending requests or responses, the NAT configuration of the load balancer must be done in a way that does not violate RFC 3261 requirements. Three setup options can be used to accomplish this configuration:

The sections that follow describe each approach.

4.9.3.1 NAT-based configuration

The default UDP NAT behavior for load balancers is to perform destination IP address translation in the public > private network direction, and source IP address translation in the private > public network direction. This means setting up destination address translation in the UAC > Oracle WebLogic Communication Services (2.3.4.5 > 1.2.3.4) direction without source address translation, and source address translation in the Oracle WebLogic Communication Services > UAC (10.1/16 > 2.3.4.5) direction without destination address translation.

Figure 4-6 illustrates the UDP packet flow for a SUBSCRIBE/200OK transaction.

Figure 4-6 SUBSCRIBE Sequence

Description of Figure 4-6 follows
Description of "Figure 4-6 SUBSCRIBE Sequence"

Note that the source and destination IP addresses of the UDP packets are shown in blue. In the UAC > Oracle WebLogic Communication Services direction, the load balancer translates the destination IP address but not the source IP address. In the Oracle WebLogic Communication Services > UAC direction, the load balancer translates the source IP address but not the destination IP address.

The complete message trace (including IP and UDP headers, as well as the SIP payload) for the sequence from Figure 4-6 is shown in Example 4-6 below.

Example 4-6 Complete SUBSCRIBE Message Trace

No.     Time        Source                Destination           Protocol Info
      1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      2 2.426250    2.3.4.5           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      3 3.430903    10.1.1.1               2.3.4.5           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
    Message Header
        To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
        CSeq: 1 SUBSCRIBE
        Call-ID: 1-25923@2.3.4.5

If Oracle WebLogic Communication Services subsequently sends a NOTIFY request to the UAC, the sequence shown in Figure 4-7 takes place:

Figure 4-7 NOTIFY Sequence

Description of Figure 4-7 follows
Description of "Figure 4-7 NOTIFY Sequence"

As in the previous sequence, the IP address translation takes place in the Oracle WebLogic Communication Services > UAC direction for the source IP address, and UAC > Oracle WebLogic Communication Services direction for the destination IP address.

Note that this setup does not require the load balancer to maintain session state information or to be SIP-aware. The complete message trace from Figure 4-7 is shown in Example 4-7 below.

Example 4-7 Complete NOTIFY Message Trace

No.     Time        Source                Destination           Protocol Info
      1 5.430952    10.1.1.1                2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
    Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
    Message Header
        To: sipp <sip:sipp@2.3.4.5>;tag=1
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
        CSeq: 1 NOTIFY
        Call-ID: 1-25923@2.3.4.5
        Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
        From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
      2 6.430952    1.2.3.4          2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999)
Session Initiation Protocol
    Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
    Message Header
        To: sipp <sip:sipp@2.3.4.5>;tag=1
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
        CSeq: 1 NOTIFY
        Call-ID: 1-25923@2.3.4.5
        Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
        From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Max-Forwards: 70


No.     Time        Source                Destination           Protocol Info
      3 7.431367    2.3.4.5           1.2.3.4          SIP      Status: 200 OK

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
    Message Header
        Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
        From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1
        Call-ID: 1-25923@2.3.4.5
        CSeq: 1 NOTIFY
        Contact: <sip:2.3.4.5:9999;transport=UDP>

Caution:

If NAT is performed on both the source (SNAT) and destination IP addresses, the configuration does not work because the load balancer usually relies on a specific destination port number value to be sent in responses to requests. That port number value is dictated by RFC 3261, and must come from the Via header, which presents a conflict with load balancer's NAT requirements. RFC 3261 requires that responses to SIP requests be sent to the IP address used to send the request (unless maddr is present in the Via, as described in Section 4.9.3.2, "maddr-Based Configuration"). Consequently, in Figure 4-8 below, Step 3, Oracle WebLogic Communication Services sends a 200 OK response to the load balancer internal IP address (10.1.3.4) and port 5060. That response is then dropped.

Figure 4-8 Source and Destination NAT

Description of Figure 4-8 follows
Description of "Figure 4-8 Source and Destination NAT"

The complete message trace from Figure 4-8 is show in Example 4-8 below.

Example 4-8 Complete Failing SUBSCRIBE Message Trace

No.     Time        Source                Destination           Protocol Info
      1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      3 3.430903    10.1.1.1               10.1.3.4           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol

4.9.3.2 maddr-Based Configuration

When the maddr parameter is present in the Via header, the response is sent to the IP address specified in the maddr rather than to the received IP address (even when SNAT is enabled). In the example below, the UAC specifies a maddr set to 2.3.4.5 in the Via header. Consequently the response from the SIP server makes it to the UAC.

Figure 4-9 maddr Sequence

Description of Figure 4-9 follows
Description of "Figure 4-9 maddr Sequence"

The complete message trace from Figure 4-9 is shown in Example 4-9 below.

Example 4-9 Complete maddr Message Trace

No.     Time        Source                Destination           Protocol Info
      1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      3 3.430903    10.1.1.1               2.3.4.5           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
    Message Header
        To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>

4.9.3.3 rport-Based Configuration

RFC 3581 improves SIP and NAT interactions by allowing the client to request that the server send responses to a UDP port number from the request rather than from the Via. In order for both SUBSCRIBE and NOTIFY to work correctly, both the UAC as well as Oracle WebLogic Communication Services must support RFC 3581. Figure 4-10 illustrates the SUBSCRIBE flow.

Figure 4-10 rport SUBSCRIBE Sequence

Description of Figure 4-10 follows
Description of "Figure 4-10 rport SUBSCRIBE Sequence"

The complete message trace from Figure 4-10 is shown in Example 4-10 below.

Example 4-10 Complete Message Trace for rport SUBSCRIBE

No.     Time        Source                Destination           Protocol Info
      1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1
        From: sipp <sip:sipp@2.3.4.5>;tag=1
        To: sut <sip:subscribe@1.2.3.4:5060>
        Call-ID: 1-25923@2.3.4.5
        Cseq: 1 SUBSCRIBE
        Contact: sip:sipp@2.3.4.5:9999
        Max-Forwards: 70
        Event: ua-profile
        Expires: 10
        Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      3 3.430903    10.1.1.1               10.1.3.4           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 2222 (2222)
Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
    Message Header
        To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
        CSeq: 1 SUBSCRIBE
        Call-ID: 1-25923@2.3.4.5

Figure 4-11 illustrates the NOTIFY flow.

Note that while source address NAT is enabled for both directions (UAS > Oracle WebLogic Communication Services and Oracle WebLogic Communication Services > UA), the load balancer can correctly identify the destination address in Step 3 by relying on receiving responses on the same port number as the one used to send requests. This implies that the load balancer maintains state.

Figure 4-11 rport NOTIFY Sequence

Description of Figure 4-11 follows
Description of "Figure 4-11 rport NOTIFY Sequence"

The complete message trace from Figure 4-11 is shown in Example 4-11 below.

Example 4-11 Complete Message Trace for rport NOTIFY

No.     Time        Source                Destination           Protocol Info
      1 5.430952    10.1.1.1                2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
    Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
    Message Header
        To: sipp <sip:sipp@2.3.4.5>;tag=1
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
        CSeq: 1 NOTIFY
        Call-ID: 1-25923@2.3.4.5
        Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
        From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
      2 6.430952    1.2.3.4          2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999)
Session Initiation Protocol
    Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
    Message Header
        To: sipp <sip:sipp@2.3.4.5>;tag=1
        Content-Length: 0
        Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
        CSeq: 1 NOTIFY
        Call-ID: 1-25923@2.3.4.5
        Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
        From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        Max-Forwards: 70


No.     Time        Source                Destination           Protocol Info
      3 7.431367    2.3.4.5           1.2.3.4          SIP      Status: 200 OK

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: (2222)
Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
    Message Header
        Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
        From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
        To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1
        Call-ID: 1-25923@2.3.4.5
        CSeq: 1 NOTIFY
        Contact: <sip:2.3.4.5:9999;transport=UDP