Steering Pools
Steering pools define sets of ports that are used for steering media flows through the Oracle Communications Session Border Controller. These selected ports are used to modify the SDP to cause receiving session agents to direct their media toward this system. Media can be sent along the best quality path using these addresses and ports instead of traversing the shortest path or the BGP-4 path.
For example, when the Oracle Communications Session Border Controller is communicating with a SIP device in a specific realm defined by a steering pool, it uses the IP address and port number from the steering pool’s range of ports to direct the media. The port the Oracle Communications Session Border Controller chooses to use is identified in the SDP part of the message.
Note:
The values entered in the steering pool are used when the system provides NAT, PAT, and VLAN translation.Configuration Overview
To plan steering pool ranges, take into account the total sessions available on the box, determine how many ports these sessions will use per media stream, and assign that number of ports to all of the steering pools on your Oracle Communications Session Border Controller. For example, if your Oracle Communications Session Border Controller can accommodate 500 sessions and each session typically uses 2 ports, you would assign 1000 ports to each steering pool. This strategy provides for a maximum number of ports for potential use, without using extra resources on ports your Oracle Communications Session Border Controller will never use.
- IP address—IP address of the steering pool.
- start port—Port number that begins the range of ports available to the steering pool. You must define this port to enable the system to perform media steering and NAT operations.
- end port—Port number that ends the range of ports available to the steering pool. You must define this port to enable the system to perform media steering and NAT operations.
- realm id—Identifies the steering pool’s realm. The steering pool is restricted to only the flows that originate from this realm.
Note:
The combination of entries for IP address, start port, and realm ID must be unique in each steering pool. You cannot use the same values for multiple steering pools.Each bidirectional media stream in a session uses two steering ports, one in each realm (with the exception of audio/video calls that consume four ports). You can configure the start and end port values to provide admission control. If all of the ports in all of the steering pools defined for a given realm are in use, no additional flows/sessions can be established to/from the realm of the steering pool.
Note:
If your signaling interface and steering-pool use the same IP address over TCP, you must ensure the steering-pool port range does not include the signaling interface's port number. If it does, the system cannot properly process signaling traffic on that interface.Allocation Strategies for Steering Pools
You can configure the SBC with three types of steering pools to allocate network ports for specific types of network traffic. These pool types include audio/video, MSRP and mixed media types. Establishing these pool types provides more efficient use of media ports. The SBC provides you with a means of monitoring port usage by type to troubleshoot and refine these configurations.
By default, the SBC does not allocate steering pool ports based on media type. These default allocations can establish scenarios, including sequential allocation and port release, wherein port usage is inefficient. By configuring or monitoring your realms for traffic type use, you can plan for and adjust configuration based on expected port usage:
- Audio/Video sessions—Consume 4 ports, including two audio ports supporting the two traffic directions and two additional ports for RTP and RTCP
- MSRP sessions—Consume 2 ports supporting the two traffic directions
- Hairpin Audio sessions—Consume 8 ports, including four audio flows supporting the two traffic directions, two for RTP, and two for RTCP
Per recommendation in RFC 3550, the SBC allocates RTP and RTCP ports for audio calls sequentially. This behavior can reduce the number of ports you have configured for a steering-pool.
For example, if you have configured 100 ports on a realm and it receives 100 MSRP calls, the SBC allocates the 100 ports for the MSRP call flows. When the users terminate these sessions, those terminations happen randomly, leaving multiple non-sequential ports open.
If the users terminate 20 random sessions, the number of ports that become available are not likely to support 5 A/V calls. This is because the SBC may not be able to find open, sequential ports to support RTP and RTCP. This can cause calls to fail, with the system reporting no ports available as the reason.
This feature provides you with a means of establishing multiple steering-pool objects for a realm that use your configured allocation strategy as a means of determining pool affinity based on traffic type. The SBC recognizes the traffic type and chooses the appropriate steering-pool based on port-allocation-strategy and current pool capacity:
- mixed—(Default) Supports all types of sessions
- single—Recommended for MSRP sessions
- pair—Recommended for audio and video sessions
The SBC tracks pool utilization and, assuming the port-allocation-strategy is appropriate, allocates traffic preferred for an empty pool to use ports from a pool that is not empty rather than reject the call. In addition, the system supports the use of steering pool ports from a parent realm by flows in a child realm. This adds an additional option for establishing allocation flexibility.
Consider a realm with three steering pools, including a mixed, a single and a pair. System port allocation behavior would include:
- The SBC directs MSRP sessions to the single pool. If the single pool runs out of ports, the SBC directs MSRP sessions to the mixed pool. If both of these pools are exhausted, the SBC drops new MSRP sessions and increments the 'no ports' counter.
- The SBC directs audio sessions to the pair pool. If the pair runs out of ports, the SBC directs audio sessions to the mixed pool. If both of these pools are exhausted, the SBC drops new audio sessions and increments the 'no ports' counter.
Notice that the SBC restricts traffic types when using the single and pair allocation strategies. The mixed pool, however, supports both traffic types.
To mitigate against the lack of consecutive ports described above, you could configure two steering-pool objects for same realm, one set to pair and the other to single. This configuration also restricts port utilization to specific pools by not including any steering-pool set to mixed.
Ultimately, you evaluate and monitor your deployment's needs for pool allocation and configure pools to suit those needs.
Configuration
You configure this functionality using the port-allocation-strategy parameter within steering-pool elements. The default is mixed.
ORACLE(steering-pool)#port-allocation-strategy singleImportant configuration detail includes:
- Do not overlap port ranges configured on the same interface regardless of allocation strategy. The system throws a verify-config error identifying any overlapping steering-pool port range configuration, but it does not prevent you from saving and activating the configuration.
- The port-allocation-strategy parameter is real time configurable, allowing you to change an allocation strategy during operation. Established calls using this pool's strategy persist until the users terminate them. Ensuing calls use your updated strategy.
- The SBC selects ports from a child realm's pools when sessions start on that child realm. If a child realm's ports are exhausted, the SBC can allocate ports from the parent realm as long as the strategy is appropriate.
Steering Pool Allocation Examples
When determining the best port allocation strategies for your deployment, consider the examples in this section.
Basic Example
This example presents a realm with 3 steering-pool elements configured to the following strategies:
- SP1—mixed
- SP2—single
- SP3— pair
When MSRP calls arrive at this realm, the system allocates ports from SP2. If SP2 becomes exhausted, the system allocates ports for new MSRP calls from SP1. If both SP2 and SP1 become exhausted, the system rejects MSRP calls to this realm.
Similarly, when audio calls arrive at this realm, the system allocates ports from SP3. If SP3 becomes exhausted, the system allocates ports for new audio calls from SP1. If both SP3 and SP1 become exhausted, the system rejects audio calls to this realm.
Configuration Change Example
When a call is established with a steering pool port, configuration changes do not affect that call. After a configuration change, however, the system uses that port's updated strategy for ensuing allocations.
This example presents a realm with 3 steering-pool elements configured to the following strategies:
- SP1—mixed
- SP2—single
- SP3— mixed
Note:
Port allocation to pools of the same type depends on the port range available. When it begins allocating ports from a pool, the system chooses the lowest port available. But calls terminate randomly, so the system picks the topmost port available in a pool on ensuing calls, which may not be the lowest port number available.When MSRP calls arrive at this realm, the system allocates ports from SP2. If SP2 becomes exhausted, the system allocates ports for new MSRP calls from SP1 and SP3. If both SP1 and SP3 become exhausted, the system rejects MSRP calls to this realm and increments the no ports counter.
Similarly, when audio calls arrive at this realm, the system allocates ports from SP1 and SP3. If SP3 becomes exhausted, the system allocates ports for new audio calls from SP1. If both SP3 and SP1 become exhausted, the system rejects audio calls to this realm.
If you change the port-allocation-strategy of SP2 from single to pair, then perform the save-config and activate config commands, the system begins to allocate audio calls to SP2. With this new configuration, the system is able to assign audio calls to all three pools. If SP1, SP2 and SP3 become exhausted, the system rejects audio calls to this realm.
If MSRP calls arrive at this realm, the system allocates ports for these calls using SP1 and SP3. If SP1 and SP3 become exhausted, the system rejects MSRP calls to this realm
Parent/Child Realm Allocation Example 1
Note that the following example presents a typical port utilization scenario. The difference here is that the system is using the parent realm's ports. In this example, either the child realm has no steering pools, or all of the child realm's applicable ports are in use.
Case 1—Assume the parent realm has 3 steering-pools:
- SP1—mixed
- SP2—single
- SP3— pair
In this case, an MSRP call arriving at the child realm uses the parent realm's SP2. If SP2 runs out of ports, the system tries to use SP1. Audio calls to the child realm use the parent realm's SP3. If SP3 runs out of ports, the system again tries to use SP1.
Case 2—In this case, all of the parent realm pools are mixed. Here, both MSRP and audio calls to the child realm can use SP1, SP2 and SP3.
Parent/Child Realm Allocation Example 2
Similar to Parent/Child Realm Allocation Example 1, the system here uses a child realm's steering pool ports first, then begins to use the parent realm's ports when the child realm's ports are in use. Utilization detail still uses the mixed, single, pair strategy rules.
- Case 1—Assume a child realm has:
- SP4—mixed
- SP5—mixed
If you have configured 200 ports, the system uses all of those ports before using parent realm ports.
- Sub Case 1—Assume the parent realm has:
- SP1—mixed
- SP2—single
- SP3—pair
The system receives MSRP calls to the child realm, which then uses SP2 in the parent realm. If parent realm SP2 becomes exhausted, the system starts using SP1. Audio calls to the child realm use the parent realm's SP3 and then SP1 when SP3 is exhausted.
- Sub Case 2—Assume all of the parent realm's pool strategies are mixed. In this case, all MSRP and audio calls to the child realm can use SP1, SP2 and SP3.
- Case 2—In this case, assume the parent realm uses the same
allocation for Case 1, Sub-case 1 and the child realm has:
- SP4—mixed - 100 ports
- SP5—single - 80 ports
- SP6—pair - 60 ports
Consider the results when there are 180 MSRP calls to the child realm. The system handles the first 80 using SP5 ports and the next 100 using SP4 ports. When MSRP call number 181 arrives, the system uses the parents realm's SPs, not the child realm's SPs. Similarly, when all 60 pair ports are used, the system uses any available mixed ports from SP4, and then uses the parent realm SPs.
The following cases assume the child realm's ports are all used.
- Sub Case 1—Incoming MSRP calls to child realm use SP2, in the parent realm, for port allocation. If SP2 ports are used, the system uses SP1. Audio calls to child realm use SP3, in the parent realm, for port allocation. If SP3 ports are used, the system uses SP1.
- Sub Case 2—If the parent realm's pools are all mixed, all calls to child realm can use SP1, SP2 and SP3.
- Sub Case 3—If the parent realm's pools are all single, the system terminates all audio calls to the child realm, and indicates that no ports are available.
- Sub Case 4—If the parent realm's pools are all pair, the system terminates all MSRP calls to the child realm, and indicates that no ports are available.
Monitoring Port Allocation
You can troubleshoot your port allocation configuration and report on port usage, including the number of audio, MSRP calls and ports assigned using following commands:
- show sipd
- show mbcd
- show mbcd realms
- show mbcd realms <identifier>
- show mbcd realms <identifier> detailed
You can see status on steering-pool ports using the show mbcd realm <identifier> detailed command. On a per-realm basis, this command displays used and free ports for each steering pool whether configured as mixed, single or pair. This command also displays the 'no ports' counter. This command allows you to monitor port utilization on a realm and adjust your allocation configuration based on your traffic.
ORACLE#show mbcd realm Realm172 detailed
-- Period -- -- Lifetime --
Active High Total Total PerMax High
Ports Used 0 0 0 0 0 0
Free Ports 0 0 0 0 0 0
No Ports Avail - - 0 0 0 -
Ingress Band OK OK 0 0 0 OK
Egress Band OK OK 0 0 0 OK
Ingr Pri Band OK OK 0 0 0 OK
Egr Pri Band OK OK 0 0 0 OK
BW Allocations 0 0 0 0 0 0
Band Not Avail - - 0 0 0 -
Icmp Sent - - 0 0 0 -
Icmp Received - - 0 0 0 -
Total Bandwidth=0K
-- Period -- -- Lifetime --
Active High Total Total PerMax High
-- MIXED PORTS --
Ports Used 0 0 0 0 0 0
Free Ports 0 0 0 0 0 0
-- SINGLE PORTS --
Ports Used 0 0 0 0 0 0
Free Ports 0 0 0 0 0 0
-- PAIRED PORTS --
Ports Used 0 0 0 0 0 0
Free Ports 0 0 0 0 0 0