The Acme Packet 3800 and 4500 series Session Border Controllers come with an NIU (Network Interface Unit) that includes four Gigabit ports. In rare cases one may need to support Media Aggregation where two of the Gigabit interfaces need to be look like they are “bonded” to accommodate a large number of calls (with media anchored). For example, a wholesale SIP Peering Service Provider may need to handle upwards of 16,000 concurrent calls on one single Realm on the SBC. If calls are using the G.711 codec this would require 1.5GB of bandwidth.
The process used to support Media Aggregation is to assign the same Realm name to two different Steering Pools. For example, on the realm Access it would have more than one steering pool which would reference two different network-interfaces. The same is true for the Core. In the following example NIU ports 0 and 1 are used for Access (public facing) and 2 and 3 are used for Core (private). Note the NIU is considered slot 0 and the ports are 0, 1, 2, 3.
The next step is to verify you have your Access and Core realms configured.
The final step is to create the Steering Pools and define the network-interfaces for each.
At this point the SBC will utilize two ports assigned to Access and two ports assigned to Core to support media thus providing Media Aggregation. SIP signaling continues to only traverse on the sip-interfaces assigned to the Access and Core realms (s0p0 and s0p2) .
At this point the Acme Packet SBC is fully prepared to handle traffic that exceeds 1GB on a single Realm.
Great writeup. Thank you. Any idea how it distributes the load among the two different steering pools?
Mark, you should use the term “media anchoring” rather than “media latching”, as the latter implies something beyond steering media through the SBC.
Scott, when the Acme Packet SBC loads its configuration, it adds all steering-pool ports to a list (one configuration element’s worth at a time). It will then pull them from the front of the list when it allocates them, and return them to the end of the list when they’re freed. So the net effect is that it will cycle through all ports within a single steering-pool, then move onto the next, etc. But since calls do not have fixed durations, over time entropy takes over and the usage of the ports will appear random.
Hello Mark,
if we configure our SD as such, should the distant peer be aware of these changes? I mean, does the peer partner send trafic to both address in the peer side? In fact, I could not imagine how this can work if the distant sends its trafic only to S0P0 that is bounf to Access realm?
Thank you for your assistant.
my mail is iglhamid@gmail.com
Good work Mark!
Hi Hamid, in this config, nothing is going to change in signaling, so the peer party should not know the change as I understand. If the peer party has accessibility to the new media IP, then I don’t see any issue in this config.