| Oracle® Communications Converged Application Server Concepts Release 5.1 Part Number E27705-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Converged Application Server Concepts Release 5.1 Part Number E27705-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the Oracle Communications Converged Application Server deployment considerations architecture.
This section describes common Converged Application Server network architectures and network configuration considerations for each architecture, particularly in relation to the Open Systems Interconnect (OSI) model. See Oracle Communications Converged Application Server Administration Guide for detailed configuration steps described in this section.
Figure 5-1 shows the OSI model layers that are typically affected by the network configuration requirements for the Converged Application Server deployment.
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.
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 5-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.) The scenario 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:
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 Converged Application Server) 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 Converged Application Server.
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 and setting a static port, as described in Oracle Communications Converged Application Server Administration Guide.
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:
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 Converged Application Server 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 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".
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 0.0.0.0.
See information about configuring engine servers to listen on any IP interface in the Oracle Communications Converged Application Server Administration Guide.
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 5-3 shows this configuration.
To configure the Converged Application Server instance in this scenario, you must define a separate network channel for each NIC used on the server machine. Example 5-1 shows the config.xml entries that define channels for the sample configuration.
Example 5-1 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"/>
When Converged Application Server is configured to listen on multiple subnets, a feature called the route resolver is responsible for the following activities:
Populating OSI Layer 7 information (SIP system headers such as Via and Contact) with the correct address.
Populating OSI Layer 3 information with the correct source IP address.
For example, in the configuration shown in Figure 5-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 5-3, an INVITE message sent from Converged Application Server 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.
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 configure Converged Application Server to listen on all addresses.
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.
A load balancer improves the reliability and scalability of your Converged Application Server deployment. A load balancer distributes requests among the servers in your deployment and monitors their availability.
To perform load balancing functions for your Converged Application Server deployment, you can use the Converged Load Balancer, which is included with the Converged Application Server distribution, or a third-party load balancer.
The Converged Load Balancer is SIP-aware, and performs application-level load balancing functions for your deployment. It can distribute traffic based on message content or request URL context. It implements session affinity for your deployment, ensuring that messages within a session are handled by the same server.
However, the Converged Load Balancer does not perform NAT functions and therefore cannot present a common VIP to external client for your Converged Application Servers.
When using the Converged Load Balancer, you need an IP sprayer or other type of network dispatcher to perform IP-level load balancing and to present a virtual IP (VIP) for the Converged Application Server installation.
The following sections describe considerations related to exposing an external VIP for the Converged Application Server deployment. These sections assume the use of an IP sprayer. However, your deployment may use other technology to perform the network dispatching function, such as the DNS Resource Records (RR) feature in the Linux operating system.
In the simplest scenario, a single IP sprayer gates access to a Converged Load Balancer which distributes messages to a cluster of engine tier servers, as shown in Figure 5-4.
To configure Converged Application Server for use with a single IP sprayer, configure one or more network channels for each server, and configure the external address setting of each channel with the virtual IP address of the IP sprayer. The virtual IP address is the address exposed for the Converged Application Server installation to external clients.
In this configuration, Converged Application Server embeds the external address (or VIP) in SIP message system headers to ensure that clients can reach the cluster for subsequent replies.
Multiple IP sprayers (or a multihomed node that functions as an IP sprayer) can be configured to provide several virtual IP addresses for a single Converged Application Server cluster.
To configure Converged Application Server for multiple VIPs, create a dedicated network channel for each IP sprayer or local server NIC. You then set the channel's external address to the virtual IP address of the IP sprayer to which the channel connects.
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".
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.
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.
Caution:
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:
-Dwlss.udp.lb.masquerade=false
See the Oracle Communications Converged Application Server Administration Guide for more information on startup options.
This section describes Converged Application Server deployment scenarios. In particular, it describes considerations related to SIP, load balancer, and Network Address Translation (NAT), and shows the message flows in such scenarios.
Note:
For more information about implementation-dependent issues surrounding NAT, see the Internet Engineering Task Force (IETF) document NAT Behavioral Requirements for Unicast UDP at the IETF website:When deployed with multiple SIP-aware Converged Load Balancers, the Converged Application Server deployment also typically includes an IP sprayer or network-level load balancer to perform IP-level message distribution.
You can also deploy the Converged Application Server with load balancers that are not SIP-aware, meaning that they do not consider existing SIP dialogues when routing requests to servers. The following sections describe the scenario given a non-SIP aware load balancer and the Converged Load Balancer.
Figure 5-5 shows the sample network topology described in this section. A Converged Application Server 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 Converged Application Server cluster. Instead, it sends requests to, and receives responses from 1.2.3.4.
The sections that follow discuss configuring the Converged Application Server cluster and load balancer for the example system.
The Converged Application Server cluster configuration specifies the public address as 1.2.3.4, and the public port as 5060 for each engine. The default route on both Converged Application Server engines points to the load balancer's 10.1/16 network interface: 10.1.3.4. The Converged Application Server (servers WLSS 1 and WLSS 2) routing table is shown in Example 5-2.
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 5-3.
Example 5-3 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.
The default UDP NAT behavior for load balancers is to perform destination IP address translation in the public to private network direction, and source IP address translation in the private to public network direction. This means setting up destination address translation in the UAC to Converged Application Server (2.3.4.5 to 1.2.3.4) direction without source address translation, and source address translation in the Converged Application Server to UAC (10.1/16 to 2.3.4.5) direction without destination address translation.
Figure 5-6 illustrates the UDP packet flow for a SUBSCRIBE/200 OK transaction.
In the figure, the source and destination IP addresses of the UDP packets are shown under the message path arrow. In the UAC-to-Converged Application Server direction, the load balancer translates the destination IP address but not the source IP address. In the Converged Application Server-to-UAC direction, the load balancer translates the source IP address but not the destination IP address.
Example 5-4 shows the complete message trace (including IP and UDP headers, as well as the SIP payload) for the sequence from Figure 5-6.
Example 5-4 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
Figure 5-7 shows the message sequence that results from the Converged Application Server subsequently sending a NOTIFY request to the UAC:
As in the previous sequence, the IP address translation takes place in the Converged Application Server to UAC direction for the source IP address, and UAC to Converged Application Server 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 is shown in Example 5-5 below.
Example 5-5 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>
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 "maddr-based Configuration"). Consequently, in step 3 in Figure 5-8 below, Converged Application Server sends a 200 OK response to the load balancer internal IP address (10.1.3.4) and port 5060. That response is then dropped.
Example 5-6 shows the complete message trace.
Example 5-6 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
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.
Example 5-7 shows the complete message trace represented by Figure 5-9.
Example 5-7 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>
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 Converged Application Server must support RFC 3581.
Figure 5-10 illustrates the SUBSCRIBE flow.
The complete message trace from the figure is shown in Example 5-8 below.
Example 5-8 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 5-11 shows the NOTIFY message flow.
Note that while source address NAT is enabled for both directions (UAS to Converged Application Server and Converged Application Server to 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.
Example 5-9 shows the complete message trace from the figure.
Example 5-9 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
The Converged Load Balancer does not perform NAT. Accordingly, it does not affect the addressing consideration previously discussed.
Figure 5-12 shows the message flow for a SUBSCRIBE sequence with the Converged Load Balancer present.
|
 Copyright © 2005, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
