Session Initiation Protocol

Session Initiation Protocol (SIP) is an application-layer control protocol that can initiate, control, modify or terminate sessions with one or more participants. SIP is typically used for telephone and video calls, streaming multimedia distribution and conferencing. The SIP protocol offers the following features:

•User location

•User availability

•User capabilities

•Session setup

•Session management

Features of SIP

This section outlines the features of SIP in more detail.

•User Location: When a user activates a SIP device (for example, a SIP phone), it registers its current location with a SIP server. The user can then be contacted at the server's domain. Each user can have several devices in different locations registered with a server at the same time.

When someone attempts to contact the user, the message will arrive at the server. The server will then choose one or several of the user's registered locations to forward the message to.

•User Availability: When a SIP device receives a message it can respond in several different ways. The response might be determined by user input – for example the user answering an incoming call. Alternatively, the response might be automatically generated, for example if the device is already in use a “Busy” response might be returned. The server will decide what to do with this response - it might send it back to the caller or it might try sending the original message to a different location.

If the user has no devices registered with the server then they are considered to be unavailable.

•User Capabilities: SIP devices are able to query other SIP devices to learn what capabilities they have. Communication can then take place using the features that both devices support.

•Session Setup: SIP can be used with the Session Description Protocol to establish a direct communication channel between two devices. This communication channel is then used to transmit session data, such as voice data in the case of a telephone call, while the SIP channel is used to send control information, such as a request to disconnect the call. Session data is typically transmitted using the Real-Time Transport Protocol (RTP).

•Session management: SIP controls termination of sessions and transfer of sessions between different devices. It is also possible to change the parameters of an established session using SIP.

SIP supports both IPv4 and IPv6, and operates over TCP and UDP.

The Traffic Manager and the SIP Protocol

The Traffic Manager load-balances SIP traffic between SIP proxy servers, creating a SIP infrastructure with high availability, reliability and extensibility. The figure below shows an example of a SIP network that includes a Traffic Manager. The SIP phones are typically located at the users' individual locations, while the Traffic Manager, the SIP proxy servers and the location database are owned by a SIP service provider.

When working with SIP traffic, the Traffic Manager provides the following features:

•Load-balance SIP requests between SIP proxy servers with customizable load-balancing algorithms.

•Maintain session persistence so all requests that are part of the same session will be sent to the same proxy server (by default, the Traffic Manager persists on the SIP "Call-ID" header).

•Modify SIP request and response packets as they pass through the Traffic Manager using RuleBuilder and TrafficScript rules.

•Issue responses to incoming requests without sending them to a proxy server.

•Monitor the health of the proxy servers in use and direct traffic away from them when they go down.

•Act as a gateway for all SIP data and session data when all clients are in a private network.

•Protect against Denial of Service attacks and malicious data.

Configuring the Proxy Servers to Support Traffic Management

The Traffic Manager is most effective when used in front of a series of SIP proxy servers, such as Oracle/Weblogic SIP server or SIP Express Router (SER). To work in this configuration, the proxy servers must recognize the domain clients use to contact the Traffic Manager as one they are responsible for. For example, if sip:[email protected] resolves to the IP of the Traffic Manager, then the proxy servers must be responsible for the domain example.com. The proxy server will then process the request instead of forwarding it to that domain, which would result in the request looping between the Traffic Manager and the proxy server.

Alternatively, if your proxy servers do not support domains, go to the Virtual Servers > Edit > Protocol Settings page of the Admin UI and enable the rewrite_request_uri option. Enabling this option will tell the Traffic Manager to replace the URI in each request it receives with the URI of the proxy server it sends the request to.

Setting Up a SIP Service on the Traffic Manager

To create a new SIP service, use the Manage a new service wizard. Specify a suitable name for the service, and choose either the SIP over TCP protocol or the SIP over UDP protocol. The default SIP port is 5060 for both TCP and UDP services. This wizard will set up a new SIP virtual server and pool with the details provided.

For your SIP virtual server to operate correctly, it must listen to all the IP addresses used to send or receive a SIP request. To do this, navigate to the Virtual Servers > Edit > Basic Settings page and locate the Listening on setting. Ensure that "All IP addresses" is selected (this is the default).

You can also use both the UDP and the TCP protocols on the same port by creating two virtual servers and assigning one of the protocols to each virtual server.

ATTENTION
When using the Traffic Manager in a SIP infrastructure, SIP requests are sent to the client on a different connection to the one used when they register with a SIP proxy server. As a result, the client's firewall must be configured to allow SIP requests through to the phone. Some firewalls will do this automatically, whereas others will need to be configured to forward requests on port 5060 to the user's phone.

SIP Operation Modes on the Traffic Manager

A SIP virtual server can run in three different operational modes: “SIP Routing”, “SIP Gateway”, and “Full Gateway”. This setting affects how much involvement the Traffic Manager has over control information (SIP messages) and session data (typically RTP data in voice and video communication).

To define the SIP operational mode, edit your virtual server SIP settings in the Traffic Manager admin interface by clicking Virtual Servers > Edit > Protocol Settings > SIP-specific settings.

The different modes of operation are described below:

•SIP Routing: Select this option to load-balance SIP sessions between your SIP proxy servers. The first SIP request and all responses to it will pass through the Traffic Manager and can be inspected and manipulated by RuleBuilder and TrafficScript rules.

The Traffic Manager will not add a Record-Route header field to the request. As a result, future requests that are part of the same session will not pass through the Traffic Manager but will instead go straight to the server that the original request was sent to.

In a typical SIP session, this means the INVITE request and all responses to it will pass through the Traffic Manager. Any subsequent requests that manage this session, such as BYE requests, will not pass through the Traffic Manager.

•SIP Gateway: Select this option to inspect every SIP request that is part of a session. When a request passes through the Traffic Manager, the Traffic Manager will add a Record-Route header field to it so that future requests that are part of this session will be routed through the Traffic Manager. All of these requests and the corresponding responses can be manipulated with RuleBuilder and TrafficScript rules.

In a typical SIP session, all the control messages such as INVITE and BYE will pass through the Traffic Manager, but the session data itself will not. This is the default mode of operation for SIP virtual servers in the Traffic Manager.

•Full Gateway: Select this option to make all session data pass through the Traffic Manager. This mode is useful if all your SIP clients are on the same network as your Traffic Manager and the Traffic Manager is acting as a gateway to the Internet.

In this mode, all control messages such as INVITE and BYE will pass through the Traffic Manager. The Traffic Manager will modify any Session Description Protocol information contained in the body data of a request or response so that the session data also passes through the Traffic Manager.

You can choose to specify a port range that will be used for the session data. You can also specify how long the Traffic Manager will wait before closing the session data connection when no data is being sent over it.

Additional SIP Settings

The Protocol Settings page also offers some additional settings that affect the behavior of the Traffic Manager. These settings are:

Setting	Description
sip_transaction_timeout	SIP requests and responses are grouped into transactions. There are two types of transactions in SIP: INVITE transactions and Non-INVITE transactions. An INVITE transaction consists of an INVITE request, followed by a series of responses. If the final response was not a '200 OK' response then it is followed by an ACK request. A Non-INVITE transaction consists of a request followed by zero or more responses. A client can send several different transactions over the same connection. When no further messages that are part of a particular transaction have been seen for the time specified in sip_transaction_timeout, the Traffic Manager will reclaim the resources associated with the transaction. If the transaction is not complete when it times out, the Traffic Manager will issue a 408 request timeout response to the client.
sip_rewrite_uri	If set, this option tells the Traffic Manager to replace the URI of incoming requests with that of the back-end node the Traffic Manager has selected. For example, if a request arrives with the URI “sip:[email protected]” and the Traffic Manager is responsible for the domain example.com, then the request that is sent to the back-end node will be sip:[email protected]:5070 if the back-end node's IP is 192.0.2.1 and its SIP server is running on port 5070. This setting is useful if your SIP proxies do not check the domain of the user when looking up their location.
sip_follow_route	If set, this option tells the Traffic Manager to follow the routing information contained within incoming requests. If there is a Route header the request will be sent to the corresponding destination. If there is no Route header, the request will be sent to the destination specified by the URI. If the URI points to the Traffic Manager then the request will be sent to the pool as normal. This behavior can be overridden by the sip_dangerous_requests setting. For example, if a request arrives that contains body data and a Route header, the Route will be ignored and the request sent to the pool if sip_dangerous_requests is set to send dangerous requests to a back-end node. If sip_follow_route is set to No then all requests will be sent to the pool and will have a Route header added that corresponds to the chosen node.
sip_dangerous_requests	SIP requests contain their own routing information, and as such it is possible for them to be used to attack a remote computer through an intermediate machine. The Traffic Manager considers a request dangerous if its next destination is an external IP and the request contains body data. The Traffic Manager can handle potentially dangerous requests in several ways: It can send the request to a back-end node. This option is useful if your SIP proxy servers are responsible for domains that do not resolve to the Traffic Manager's IP. This is the default setting for potentially dangerous requests. It can send a 403 Forbidden response back to the client. This option is useful if you want to reject any requests that are not addressed to your Traffic Manager's domain. It can forward the request to its target URI. Selecting this option means SIP requests will be routed normally. Use this setting when you want your virtual server to handle outbound SIP traffic.
sip_max_connection_mem	A client can send multiple SIP requests on the same connection and receive responses to them in any order. To stop a client from having an excessive number of active requests awaiting a response, the Traffic Manager can limit the maximum amount of memory each connection can allocate. This setting specifies how much memory the Traffic Manager should allow each connection to use before refusing new requests with a “413 Request Entity Too Large” response. If this value is set to 0 then the memory limitations are removed, however this will leave the Traffic Manager more vulnerable to a Denial of Service attack.

UDP-based SIP services additionally use the following setting, found in "UDP-Specific Settings":

Setting	Description
sip_udp_associate_by_source	Specifies whether all datagrams sent by the client in a SIP UDP transaction must be sent from the same IP address and port. The setting is enabled by default. If disabled, the IP address from which a datagram has been sent is not taken into account by the Traffic Manager when identifying the transaction to which a datagram belongs. The client IP address to which the Traffic Manager sends response datagrams remains unchanged, even if datagrams are received from an IP address different to that from which the first datagram in a transaction was received.

Setting

Description

sip_udp_associate_by_source

Specifies whether all datagrams sent by the client in a SIP UDP transaction must be sent from the same IP address and port.

The setting is enabled by default. If disabled, the IP address from which a datagram has been sent is not taken into account by the Traffic Manager when identifying the transaction to which a datagram belongs.

The client IP address to which the Traffic Manager sends response datagrams remains unchanged, even if datagrams are received from an IP address different to that from which the first datagram in a transaction was received.

Communicating with UDP-Based SIP Servers

Typically, UDP-based SIP servers respond to requests much like TCP-based SIP servers – by sending the response from the same port on which they received the original request. This behavior is not explicitly required, however, and some SIP servers might respond from a different port or even from a different IP to the one on which it received the corresponding request.

The Traffic Manager caters for this behavior with a configuration setting udp_accept_from on the Pools > Edit > Protocol Settings page (where the pool is used by a UDP service). Use this setting to select how the Traffic Manager receives responses to UDP requests, from the following options:

•Only the IP address and port to which the request was sent.

•Only the IP address it was sent to but any port.

•A specific set of IP addresses but any port.

•Any IP address and any port.

If you choose to only accept responses from a specific set of IP addresses, type a CIDR Mask (such as 198.51.0.0/16) into the box provided.

These settings provide a varying degree of trade-off between security and compatibility. Allowing responses from multiple IP addresses can pose a greater security risk due to the increased possibility of fraudulent responses, yet certain SIP servers might require this functionality to communicate correctly. Select the option that most closely matches your requirements.

An associated setting is provided for SIP (over UDP) Health Monitors. For further details, see Built-in Health Monitors.

To limit the maximum amount of time a server node is permitted to take after receiving a UDP request from a client, set udp_response_time to the required number of seconds. A value of "0" (the default) disables the timeout counter; meaning servers that do not send replies are not automatically marked as having failed.

ATTENTION
Requests sent to an IPv4 address expect a response back from an IPv4 address only. Conversely, requests sent to an IPv6 address allow a response back in either IPv4 or IPv6 form.