CHAPTER18 Core Entities
Mediant 1000 Gateway & E-SBC | User's Manual
In a multi-tenant deployment, each tenant is represented by a dedicated SRD. The different Layer-3
networks (e.g., LAN IP-PBX users, WAN SIP Trunk, and WAN far-end users) of the tenant are
represented by SIP Interfaces, which are all associated with the tenant's SRD. As related
configuration entities (SIP Interfaces, IP Groups, Proxy Sets, Classification rules, and IP-to-IP
Routing rules) are associated with the specific SRD, each SRD has its own logically separated
configuration tables (although configured in the same tables). Therefore, full logical separation (on
the SIP application layer) between tenants is achieved by SRD.
To create a multi-tenant configuration topology that is as non-bleeding as possible, you can
configure an SRD (tenant) as Isolated and Shared:
â– Isolated SRD: An Isolated SRD has its own dedicated SIP resources (SIP Interfaces, Proxy
Sets, and IP Groups). No other SRD can use the SIP resources of an Isolated SRD. Thus, call
traffic of an Isolated SRD is kept separate from other SRDs (tenants), preventing any risk of
traffic "leakage" with other SRDs.
Isolated SRDs are more relevant when each tenant needs its own separate (dedicated) routing
"table" for non-bleeding topology. Separate routing tables are implemented using Routing
Policies. In such a non-bleeding topology, routing between Isolated SRDs is not possible. This
enables accurate and precise routing per SRD, eliminating any possibility of erroneous call
routing between SRDs, restricting routing to each tenant's (SRD's) sphere. Configuring only
one Routing Policy that is shared between Isolated SRDs is not best practice for non-bleeding
environments, since it allows routing between these SRDs.
â– Shared SRD: Isolated SRDs have their own dedicated SIP resources (SIP Interfaces, Proxy
Sets, and IP Groups). This may not be possible in some deployments. For example, in
deployments where all tenants use the same SIP Trunking service, or use the same SIP
Interface due to limited SIP interface resources (e.g., multiple IP addresses cannot be
allocated and SIP port 5060 must be used). In contrast to Isolated SRDs, a Shared SRD can
share its' SIP resources with all other SRDs (Shared and Isolated). This is typically required
when tenants need to use common resources. In the SIP Trunk example, the SIP Trunk would
be associated with a Shared SRD, enabling all tenants to route calls with the SIP Trunk.
Another configuration entity that can be used for multi-tenant deployments is the Routing Policy.
Routing Policies allow each SRD (or tenant) to have its own routing rules, manipulation rules, Least
Cost Routing (LCR) rules, and/or LDAP-based routing configuration. However, not all multi-tenant
deployments need multiple Routing Policies and typically, their configuration is not required.
Isolated SRDs are more relevant only when each tenant requires its own dedicated Routing Policy
to create separate, dedicated routing "tables"; for all other scenarios, SRDs can be Shared. For
more information on Routing Policies, see Configuring SBC Routing Policy Rules.
The figure below illustrates a multi-tenant architecture with Isolated SRD tenants ("A" and "B") and
a Shared SRD tenant ("Data Center") serving as a SIP Trunk:
- 328 -
To Next Page
Loading...
Need help?
General
