SIP 负载均衡理解

ServerIron ADX Advanced Server Load Balancing Guide

ServerIron 是一个产品, SLB是Server Load Balancing的缩写.

Understanding SIP Server Load Balancing

The Session Initiation Protocol (SIP) is a signaling protocol used by numerous IP communication products to create session-oriented connections between two or more endpoints in an IP network. SIP is emerging as the preferred technology for Voice over IP (VoIP) implementations.

Application-aware network switches play a vital role in increasing the uptime and availability of IP based services such as VoIP. Many customers rely on this technology to meet mission-critical application requirements. Together with advanced SIP intelligence, ServerIron switches offer highly scalable, available, and secure load balancing infrastructure for SIP applications.

SIP is an application-layer protocol that can establish, modify, and terminate multimedia sessions, such as Internet telephony. In this implementation, ServerIron SIP Server Load Balancing balances SIP requests and responses, based on a call-ID.

SIP Server Load Balancing is based on a request and response transaction model that is similar to HTTP. Each transaction consists of a request that invokes a particular method on the server, and at least one response. The method is carried within the request message.

Understanding SIP Packet Flow

Figure 2.1 demonstrates the basic operation of SIP signaling protocol; location of an end-point, signal of a desire to communicate, negotiation of session parameters to establish the session, and tear-down of the session after completion.

Figure 2.1

SIP Packet Flow

This example shows packet exchange between two SIP clients, also known as user agent clients (UAC). Each message is labeled with the letter "F" and a number for reference by the text. The session established between the two end clients is facilitated by the SIP proxy server. User1 "calls" User2 using his/her SIP identity, a type of Uniform Resource Identifier (URI) called a "SIP URI." The SIP URI is similar to an email address, typically containing a username and a host name. In this case, it is sip:[e-mail], where brocade.com is the domain of User1's SIP service provider.

SIP is based on an HTTP-like request and response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server, and at least one response. In this example, the transaction begins with User1's SIP phone sending an INVITE request addressed to User2's SIP URI. The INVITE request contains a number of header fields. The fields present in an INVITE include a unique identifier for the call (Call-ID), the destination address, User1's address, and information about the type of session that User1 wishes to establish with User2. The INVITE (message F1 in Figure 2.1) would look like this:

INVITE sip:[e-mail] SIP/2.0

Via: SIP/2.0/UDP pcuser1.brocade.com;branch=dkDKdkDKdkDK1111

Max-Forwards: 50

To: User2 <sip:[e-mail]>

From: User1 <sip:[e-mail]>;tag=1122334455

Call-ID: [e-mail]

CSeq: 123456 INVITE

Contact: <sip:[e-mail]>

Content-Type: application/sdp

Content-Length: 142

Since User1's SIP phone does not know the location of User2's SIP phone, it sends the INVITE message to the SIP proxy server that is serving the brocade.com domain. The address of the brocade.com proxy server is known to the SIP phone through static configuration or through DHCP. The proxy server receives the INVITE request and sends a 100 (Trying) response back to User1's SIP phone. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows User1's SIP phone to correlate this response to the previously sent INVITE. The proxy server consults a database, generally called a location service, that contains the current IP address of User2. It then forwards (or proxies) the INVITE request there. Before forwarding the request, the proxy server adds an additional Via header field value with its own address (the INVITE already contains User1's address in the first Via).

User2's SIP phone receives the INVITE and alerts User2 of the incoming call from User1, that is, User2's phone rings. User2's SIP phone indicates this by a 180 (Ringing) response, which is routed back through the SIP proxy server in the reverse direction. When User1's SIP phone receives the 180 (Ringing) response, it passes this information to User1, using an audio ringback tone.

If User2 decides to answer the call (User2 picks up the handset), the SIP phone sends a 200 OK response to indicate that the call has been answered. The 200 OK contains the Via, To, From, Call-ID, and Casque header fields that are copied from the INVITE request, and a message body with the SDP media description of the type of session that User2 is willing to establish with User1. The 200 OK (message F6 in Figure 2.1) would look like this:

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcproxy.brocade.com

;branch= dkDKdkDKdkDK2222;received=172.1.1.2

Via: SIP/2.0/UDP pcuser1.brocade.com

;branch= dkDKdkDKdkDK1111;received=172.1.1.1

To: User2 <sip:[e-mail]>;tag=dkdkdk1

From: User1 <sip:[e-mail]>;tag=1122334455

Call-ID: [e-mail]

CSeq: 123456 INVITE

Contact: <sip:user2@172.1.1.3>

Content-Type: application/sdp

Content-Length: 131

The 200 OK message is routed back through the SIP proxy server to the User1's SIP phone, which then stops the ringback tone and indicates that the call has been answered. Finally, User1's SIP phone sends an acknowledgement message, ACK, to User2's SIP phone to confirm the reception of the final response (200 OK). This ACK is sent directly from User1's SIP phone to User2's SIP phone, bypassing the SIP proxy server. This occurs because the endpoints have now learned each other's IP address from the Contact header fields through the INVITE/200 OK exchange, which was not known when the initial INVITE was sent. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions.

User1 and User2's media exchange now begins using the format that they have agreed upon through SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages. At the end of the call, User2 disconnects (hangs up) the phone and generates a BYE message. This BYE is routed directly to User1's SIP phone, again bypassing the SIP proxy. User1 confirms receipt of the BYE with a 200 OK response, which terminates the session and the BYE transaction. No ACK is sent. (An ACK is only sent in response to an INVITE request.)

SIP Client Registration

Registration is another common SIP operation. Registration is the means through which the SIP domain's registrar server learns the current location of SIP clients (UAC). Upon initialization, and at periodic intervals, the SIP clients send REGISTER messages to domain's SIP registrar server. The REGISTER messages associate an individual SIP URI (sip:[e-mail]) with the machine (IP address) into which the user is currently logged. The registrar server writes this association to a database, called the location service, where it can be used by the SIP proxy server of the domain. Often, a registrar server and the location service for a domain are co-located with the proxy server for that domain.

SIP Server Load Balancing on ServerIron

Figure 2.2 shows an overview of a ServerIron SIP Server Load Balancing implementation.

Figure 2.2

ServerIron SIP Server Load Balancing Implementation

There are three kinds of SIP servers: proxy server, redirect server, and registrar server.

In Figure 2.2, the ServerIron SIP load balancer (SIP Server Load Balancing) uses the Domain-1 VIP to load balance SIP requests from Client A or Client B among Domain 1 proxy servers and registrar servers.

The SIP Server Load Balancing uses the Domain-2 VIP to load balance SIP requests from Client A (user1) or Client B (user2) among Domain 2 poxy servers and registrar servers.

The ServerIron offers support for the following SIP servers in accordance with RFC 3261:

•	Proxy
•	Redirect

•

Registrar

The ServerIron supports the following methods in accordance with RFC 3261:

•	INVITE
•	REGISTER

•	ACK
•	CANCEL

•	BYE
•	OPTIONS

Additionally, the following methods are supported:

•	SUBSCRIBE
•	NOTIFY

•	Other proprietary methods

Specifications

The SIP Server Load Balancing feature has the following specifications:

•	Certified for ServerIron chassis-based systems.
•	ServerIron SIP Server Load Balancing is stateless.

•	The ServerIron hashes client traffic based on SIP Call-ID. The server persistence is achieved as the call-ID value is maintained for a given SIP dialog.
•	UDP is the only supported transport layer protocol.

•	Pass-through SIP traffic from real SIP servers to SIP clients gets translated. The ServerIron replaces source IP (SIP server real IP) with Virtual IP (VIP)
•	The ServerIron can parse up to 1000 bytes of SIP packet header.

•	The ServerIron does not modify any of the SIP header fields.
•	No SIP Aware NAT support.

•	This implementation is based on RFC 3261.

NOTE: The ServerIron SIP SLB is not implemented as a SIP proxy server, but rather as a load balancer of proxy or registrar traffic.

NOTE: The ServerIron does not modify any of the SIP headers. It also does not perform SIP-aware NAT.

SIP Terminology

This section describes terms and concepts that you might find useful when configuring SIP-LB.

Request-URI

Every SIP user has a URI. One SIP user calls another by setting the SIP URI of the latter in the request message, (also called request-URI), which appears before all message headers.

UAC

A User Agent Client (UAC) is a logical entity that creates a new request. The role of UAC lasts only for the duration of the transaction.

UAS

A User Agent Server (UAS) is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request.

Proxy Server

An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server is primarily a router, which means its job is to ensure that a request is sent to another entity nearer to the targeted user. A proxy interprets and, if necessary, rewrites specific parts of a request message before forwarding it.

Redirect Server

A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs.

Registrar Server

A registrar server accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles.

SIP Message Headers

This section describes SIP message headers that you might find useful when making decisions about SIPServer Load Balancing.

CALL-ID

The call-ID is a header field that appears in all SIP requests and responses. This header field acts as a unique identifier to group together a series of messages. It must be the same for all requests and responses sent by either UAC or UAS in a dialog.

Call-ID is generated by the combination of a random string and the host name or IP address of a particular UAC. There is no length restriction on call-ID. in the first implementation, real server is selected based on hash value of call-ID.

Record-Route

The Record-Route header field is inserted by a proxy in a request to force future requests in the dialog to be routed through the proxy. Example: Record-Route: <sip: server10.Biloxi.com; 1r>

From:

The From header field indicates the LOGICAL identity of the initiator of the request. It contains a URI and, optionally, a display name. This field MUST contain a "tag" parameter, chosen by the UAC.

IP addresses of the host on which the UA is running should not be used as "from" URIs, as these are not logical names.

For example:

From: "Alice" <sip: [e-mail]> ; tag=a48s or From: "Alice" <sip: [e-mail]> ; tag=a48s

To:

The To header field specifies the desired logical recipient of the request. This might not be the ultimate recipient of the request. Normally, the initial To field is set to be the value of the Request-URI. One exception is the REGISTER method.

To: Alice <sip: [e-mail] > or To: Alice <sip: [e-mail] >

Via:

The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. It is a mandatory field for the UAC or UAS SIP proxies, and guarantees that the responses traverse through the same route as the requests.

For example: Via: SIP/2.0/UDP erlang.bell-telephone.com:5060; branch=z9hGbK87asdks7

The branch ID parameter in the Via header field values serve as a transaction identifier, and is used by proxies to detect loops.

Max-Forwards:

The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server.

The Max-Forwards value is an integer in the range 1-255 indicating the remaining number of times that a request message is allowed to be forwarded. The recommended initial value is 70.

SIP Server Load Balancing and Persistence

ServerIron switches offer application-aware advanced intelligence for UDP based SIP server load balancing. The following sections describe some SIP Server Load Balancing scenerios.

Design #1: SIP Server Load Balancing with DSR Mode

Figure 2.3 shows an SIP server farm built around ServerIron application switches for higher availability, accelerated performance, on-demand scalability, and robust security.

Figure 2.3

SIP Server Farm with DSR Mode

The ServerIron application switch provides hash-based, stateless implementation for UDP-based SIP server load balancing. The Call-ID attribute that uniquely identifies a SIP call is used to maintain session persistence. Due to the unique call flow requirements of SIP, most SIP implementations require you to enable direct server return (DSR) mode on the ServerIron switch.

Since User1's SIP phone does not know the location of User2's SIP phone, it initiates a new SIP session by sending INVITE request to SIP Proxy server. It also generates a unique identifier (Call-ID) for the call. Because the SIP proxy server used by User1's SIP phone is actually the virtual IP address hosted on the ServerIron switch, the ServerIron switch receives the INVITE request and, using a hash-based mechanism, identifies the best available SIP server for this INVITE. The ServerIron uses the call-ID attribute value to hash to one of the SIP servers. For all SIP transactions within a dialog that use same call-ID, the ServerIron hashes to same SIP server. A new INVITE message with a different call-ID is again subjected to Server Load Balancing and may be forwarded to a different SIP server.

The proxy server receives the INVITE request and sends 100 (Trying) message to User1's SIP phone. Since the ServerIron switch is configured in DSR mode, the response message that is sourced from the virtual IP address flows directly to User1's SIP phone, bypassing the ServerIron. The proxy server then consults the location service and forwards the INVITE request directly to User2's SIP phone, again bypassing the ServerIron and is sourced from the proxy server's own IP address.

NOTE: The proxy server's IP address must be reachable from all SIP clients.

User2's SIP phone receives the INVITE and alerts User2 of an incoming call. User2 replies with a Ringing message to the proxy server. if User2 answers the call, a 200 OK message is sent to the proxy server. The proxy server forwards this message to User1's SIP phone. Upon receiving the 200 OK message, User1's SIP phone sends an acknowledgement (ACK) message directly to User2's SIP phone, bypassing the proxy server. User1 and User2 SIP phones now begin media exchange and upon completion, a BYE message closes the call.

Some SIP servers may be configured to use virtual IP address (VIP) as the source address for all communications. Figure 2.4 shows SIP packet flows in this type of configuration.

Figure 2.4

SIP Server Farm with DSR and SIP Server Using VIP as Source Address

In this implementation, the SIP proxy server must use same call-ID for both legs of communication (the same call-ID for message exchange with both SIP clients within a given SIP dialog). Session persistence and transaction integrity can only be achieved if the proxy server uses same call-ID.

Design #2: SIP Server Load Balancing with ServerIron non-DSR Mode

Figure 2.5 shows a SIP server farm with proxy servers connected inline (non-DSR mode) with the ServerIron switch.

Figure 2.5

SIP Server Load Balancing with ServerIron non-DSR Mode

To maintain session persistence and transaction integrity, this implementation has the following requirements:

•	The SIP proxy server should use same call-ID for both legs of communication (for example, for message exchange with both SIP clients within a given SIP dialog).
•	For all outbound SIP communications, the proxy server should use the same source port as that used as the destination port for all inbound communications.

NOTE: If the proxy server uses a source port other than the one used as the destination port for inbound communications, then these packets arriving from proxy server go untranslated by the ServerIron. The proxy server IP address must be reachable from all SIP clients in such cases.

SIP Server Health Monitoring

There are two types of SIP servers of particular importance — SIP proxy servers and SIP registrar servers. The ServerIron supports advanced layer-7 application health checks for both server types.

ServerIron switches can be enabled to send REGISTER or OPTION messages to SIP servers to track their health. When an error-free response status (default is 200 OK) is received, then the ServerIron marks the SIP server as being available, and starts assigning new SIP sessions to the available servers.

The switches can also be configured to send health monitoring messages at user-defined frequency and retrial attempts. Our unique system architecture allows a dedicated processor for health monitoring and device management, which significantly increases the reliability and efficiency of health monitoring and therefore improves the overall service availability. By default, 200 OK is considered a valid response code. Optionally, you can configure the switch to accept other response codes that indicate a healthy and available server.

SIP messages with specific SIP methods are switched to the appropriate SIP server. As an example, REGISTER messages are forwarded only to the SIP registrar server; whereas INVITE messages are distributed among SIP proxy servers.

http://www.brocade.com/support/Product_Manuals/ServerIron_AdvSLBGuide/sip.2.2.html