Nested Realms
Configuring nested realms allows you to create backbone VPN separation for signaling and media. This means that you can put signaling and media on separate network interfaces, that the signaling and media VPN can have different address spaces, and that the parent realm has one media-only sub-realm.
The following figure shows the network architecture.
In addition, you can achieve enhanced scalability by using a shared service interface. A single service address is shared across many customers/peers, customer specific policies for bandwidth use and access control are preserved, and you can achieve fine-grained policy control.
These benefits are achieved when you configure these types of realms:
- Realm group—A hierarchical nesting of realms identified by the name of the highest order realm.
- Controlling realm—A realms for which a signaling interface is configured. For example, you might configure these signaling interfaces in the following configurations: SIP-NAT, SIP port or H.323 stack. Typically, this is the highest order realm for the parent realm in a realm group.
- Parent realm—A realm that has one or more child realms. A parent realm might also be the child realm of another realm group.
- Child realm—A realm that is associated with a single higher order parent realm. A child might also be the parent realm of another realm group. Child realms inherit all signaling and steering ports from higher order realms.
- Media-only realm—A realm for which there is no configured signaling interface directly associated. Media-only realms are nested within higher order realms.
As these definitions suggest, parent and child realms can be constructed so that there are multiple nesting levels. Lower order realms inherit the traits of the realms above them, including: signaling service interfaces, session translation tables, and steering pools.
Since realms inherit the traits of the realms above them in the hierarchy, you will probably want to map what realms should be parents and children before you start configuring them. These relationships are constructed through one parameter in the realm configuration that identifies the parent realm for the configuration. If you specify a parent realm, then the realm you are configuring becomes a child realm subject to the configured parameters you have established for that parent. And since parent realms can themselves be children of other realm, it is important that you construct these relationships with care.
Configuring Nested Realms
When you are configuring nested realms, you can separate signaling and media by setting realm parameters in the SIP interface configuration, the H.323 stack configuration, and the steering ports configuration.
- The realm identifier you set in the SIP interface configuration labels the associated realm for signaling.
- The realm identifier you set in the H.323 stack configuration labels the associated realm for signaling.
- The realm identifier you set in the steering ports configuration labels the associated realm for media.
Constructing a hierarchy of nested realms requires that you note which realms you want to handle signaling, and which you want to handle media.
In the SIP port configuration for the SIP interface and in the H.323 stack configuration, you will find an allow anonymous parameter that allows you to set certain access control measures. The table below outlines what each parameter means.
| Allow Anonymous Parameter | Description |
|---|---|
| all | All anonymous connections allowed. |
| agents-only | Connections only allowed from configured session agents. |
| realm-prefix | Connections only allowed from addresses with the realm’s address prefix and configured session agents. |
| registered | Connections allowed only from session agents and registered endpoints. (For SIP only, a REGISTER is allowed for any endpoint.) |
| register-prefix | Connections allowed only from session agent and registered endpoints. (For SIP only, a REGISTER is allowed for session agents and a matching realm prefix.) |
Parent and Child Realm Configuration
To configure nested realms, you need to set parameters in the realm configuration.
To configure parent and child realms:
Aggregate Session Constraints Nested Realms
In addition to setting session constraints per realm for SIP and H.323 sessions, you can also enable the Oracle Communications Session Border Controller to apply session constraints across nested realms. When you set up session constraints for a realm, those constraints apply only to the realm for which they are configured without consideration for its relationship either as parent or child to any other realms.
You can also, however, enable the Oracle Communications Session Border Controller to take nested realms into consideration when applying constraints. For example, if a call enters on a realm that has no constraints but its parent does, then the constraints for the parent are applied. This parameter is global and so applies to all realms on the system. For the specific realm the call uses and for all of its parents, the Oracle Communications Session Border Controller increments the counters upon successful completion of an inbound or outbound call.
In the following example, you can see one parent realm and its multiple nested, child realms. Now consider applying these realm constraints:
- Parent Realm 1—55 active sessions
- Child Realm 1—45 active sessions
- Child Realm 2A—30 active sessions
- Child Realm 2B—90 active sessions
- Child Realm 3—20 active sessions
Given the realm constraints outlined above, consider these examples of how global session constraints for realms. For example, a call enters the Oracle Communications Session Border Controller on Child Realm 2B, which has an unmet 90-session constraint set. Therefore, the Oracle Communications Session Border Controller allows the call based on Child Realm 2B. But the call also has to be within the constraints set for Child Realm 1 and Parent Realm 1. If the call fails to fall within the constraints for either of these two realms, then the Oracle Communications Session Border Controller rejects the call.
Impact to Other Session Constraints and Emergency Calls
You can set up session constraints in different places in your Oracle Communications Session Border Controller configuration. Since session agents and SIP interfaces also take session constraints, it is import to remember the order in which the Oracle Communications Session Border Controller applies them: