SIP Realm Bridging
This section explains how to configure the internal routing among realms known as realm bridging. Realm bridging lets you cross-connect SIP interfaces. You can use one of the following two methods for bridging realms:
- local policy bridging: use this method to enable dynamic internal routing between realms if your SIP interfaces do not have the SIP NAT function applied.
- SIP NAT bridging: use this method if your SIP interfaces have the SIP NAT function applied.
About SIP NAT Bridging
Each SIP NAT has a presence in two realms, trusted and untrusted. The SIP NAT bridge is the conduit for packages in and out of the home realm. It creates a bridge between realms by providing address translations; removing all references to the original IP addressing from the packets sent to the destination network.
With the SIP NAT bridge, an untrusted (or public) home network can reside within the Oracle® Enterprise Session Border Controller, while the other entities (the backbone network, the Internet, or customer networks) are all trusted (or private). One of the primary functions of the SIP NAT bridge is to protect networks from one another so that address bases can remain hidden. Using a SIP NAT bridge, no one network has direct access to the data of other networks.
Establishing a SIP NAT bridge lets you route every SIP Request message through the backbone. Without using this functionality, it would appear as though all messages/sessions were coming from the Oracle® Enterprise Session Border Controller’s SIP proxy (the SIP server that receives SIP requests and forwards them on behalf of the requestor).
The following diagram illustrates this unprotected (or public) and protected (or private) division.
SIP NAT Bridge Configuration Scenarios
You can configure the SIP NAT bridge functionality in a many-to-one or a one-to-one relationship. For example, multiple customer SIP NATs can be tied to a single backbone SIP NAT, or a single customer SIP NAT can be tied to a single backbone SIP NAT.
You might need to use several SIP NATs on the customer side while using only one on the backbone side in a many-to-one relationship. Or you might configure one SIP NAT on the backbone side for every one that you configure on the customer side in a one-to-one relationship.
You can route all customer side SIP NAT requests to the corresponding backbone SIP NAT regardless of the Request URI. If a request arrives from the customer network with a Request URI that does not match the customer SIP NAT external address or the local policy that would route it to the backbone SIP NAT; the route home proxy value is used.
Many to One Configuration
In the many-to-one scenario, multiple customer SIP NATs are tied to a single backbone SIP NAT. The following diagram illustrates the many-to-one SIP NAT bridge configuration.
One-to-One Configuration
In the one-to-one scenario, a single customer SIP NAT is tied to a single backbone SIP NAT. On the backbone SIP NAT side, you configure the home proxy address to match the home address of the customer SIP NAT. On the customer side, you configure the home proxy address to match the home address of the backbone SIP NAT.
The following diagram illustrates the one-to-one SIP-NAT bridge configuration.
SIP NAT Bridge Configuration
You create a bridge between SIP NATs by pointing them at one another. You point the SIP NATs at each other by configuring the home address and home proxy address to create the bridge. In addition, you can configure the route home proxy on the customer’s side of a SIP NAT to force all requests to be routed to the corresponding backbone SIP NAT, regardless of the Request URI. You need to force requests when elements in the customer’s network send requests with a Request URI that does not match the customer’s SIP NAT external address. Or when the Request URI does not match a local policy element that would route the requests to the backbone SIP NAT.
You also need a home network to create a SIP NAT bridge. If you do not have a real home network, you need to create a virtual one. You also need to configure instances of the SIP NAT to create the SIP NAT bridge within your network.
Creating a Virtual Home Network
A virtual home network is a home network that resides entirely within the Oracle® Enterprise Session Border Controller, as does a real home network. The difference between the two is the real home network also has a physical connection to the Oracle® Enterprise Session Border Controller.
The internal home realm/network is usually configured with addresses within the special loopback range (127.0.0.0/8) as described in RFC 3330. This applies to the SIP port addresses for the home realm's SIP interface, and all home addresses for SIP NATs. The address 127.0.0.1 should not be used because it conflicts with the default loopback interface setup by the system for inter-process communication.
To create a virtual home network:
One-to-One Configuration
In the one-to-one scenario, a single customer SIP NAT is tied to a single backbone SIP NAT. The home proxy address field value of the backbone SIP NAT must match the home address of the customer SIP NAT. On the customer side, the home address of the customer SIP NAT should be defined as the home address of the customer, the home proxy address field value should match the home address of the backbone SIP NAT, and route home proxy should be set to forced.
The following table lists the field values you need to set to create a one-to-one SIP NAT bridge.
| SIP NAT Entity | Field | Sample Values |
|---|---|---|
| Backbone SIP NAT | home address | IPv4 address of the home realm. For example:
127.0.0.110 |
| N/A | home proxy address | IPv4 address of the home proxy from the
perspective of the external realm.
127.0.0.120 |
| Customer SIP NAT | home address | 127.0.0.120 |
| N/A | home proxy address | 127.0.0.110 |
| N/A | route home proxy | forced |
Shared Session Agent
Usually, the same set of servers (the external proxy) is used for all SIP NATs to the backbone network. In order to support redundant servers in the backbone of a SIP NAT bridge, the original egress realm as determined by the incoming Request URI needs to be retained after a local policy lookup.
When a request arrives at the Oracle® Enterprise Session Border Controller, it determines the matching (target) session agent and, after the local policy is examined, sets the new outbound session agent to the one from the selected target.
If the target session agent’s realm is set to *, the Oracle® Enterprise Session Border Controller retains the original session agent’s realm ID. Because the target session agent does not have a realm ID defined, the original egress realm is retained.
