SIP Server Redundancy
This section explains how to configure SIP server redundancy. SIP server redundancy involves detecting that an upstream/downstream SIP signaling entity has failed, and adapting route policies dynamically to remove it as a potential destination.
Overview
You establish SIP server redundancy by creating session agents, which are virtual representations of the SIP signaling entities. These agents are then collected into a session agent group, which is a logical collection of two or more session agents that behaves as a single aggregate entity.
Rather than direct signaling messages to a single session agent (IP), the signaling message is directed to a session agent group (SAG). The group will have a set distribution pattern: hunt, round robin, proportionally distributed, and so on. Signaling is spread amongst the agents using this chosen pattern.
You direct the signaling message by configuring a route policy, known as a local policy, which determines where SIP REQUESTS should be routed and/or forwarded. The values in the To and From headers in the SIP REQUEST are matched with the content of the local policy within the constraints set by the session agent’s previous hop value and SIP interface values such as the list of carriers.
To summarize, you need:
- two or more session agents
- a session group containg those session agents
- a local policy which directs traffic to the session agent group
Configuration Overview
You make a session agent group a target by using a local policy to select the next hop from the members of a session agent group. You need to set the replace URI field of the configured local policy to enabled; which causes NAT rules such as realm prefixing to be overridden. The replace URI field allows you to indicate whether the local policy’s value is used to replace the Request-URI in outgoing requests. This boolean field can be set to either enabled or disabled.
When the SIP NAT’s route home proxy field is set to forced, it forces the Request to be forwarded to the home proxy without using a local policy. When this option is set to either disabled or enabled and the Request-URI matches the external address of the SIP NAT, the local policy is used.
However, the local policy only replaces the Request-URI when the original Request-URI matches the SBC’s IP address or hostname. This behavior is in accordance with that described in RFC 3261. The original Request-URI will be the home proxy address value (the home address of the SIP NAT into the backbone) and not the Oracle® Enterprise Session Border Controller (E-SBC) address.
Using strict routing, the Request-URI would be the next hop, but the message would also include a Route header with the original Request-URI. With loose routing, the Request-URI remains unchanged and the next hop value is added as the top Route header.
Sometimes the next hop field value must replace the Request-URI in the outgoing request, even if the original Request-URI is not the E-SBCC. To accomplish this, an option has been added to the local policy that causes the next hop value to be used as the Request-URI and prevents the addition of Route headers. This option is the replace uri value in the local policy.
The following table lists the policy attributes for the local policy:
| Parameter | Description |
|---|---|
| next hop | IP address of your internal SIP proxy. This value corresponds to the IP address of the network interface associated with the SIP proxy. |
| realm | Number of the port associated with the SIP port. |
| replace uri | Stores the transport protocol used for sending an receiving signaling messages associated with the SIP port. |
| allow anonymous | Indicates whether this SIP port allows anonymous connections from session agents. |
Note:
You should also define the ping method intervals for the session agents so that the E-SBC can detect when the agents are back in service after failure.
