In a tenanted system, for planning and design purposes, system resources are classified as follows:
Landlord resources. The resources located on the landlord facilities and/or used only by the landlord personnel (such as a set or an attendant), or pertinent only as a system-wide resource (such as a circuit descriptor or a class of service). Members of the landlord group can always call members of any other tenants, but members of other tenants must be given permission to call members of tenant 1.
Tenant resources. The resources located on the tenant premises, specific to that tenant, and/or dedicated to the tenant (such as sets and trunks).
Shared tenant resources. The resources common to some but not all tenants (such as an attendant shared by two out of three tenants).
Common resources. The resources shared by all tenants, including the landlord. This includes resources such as trunks, centralized attendants, message centers, and centralized voice mail.
Public resources. The resources used by the public at large (such as telephones located in the reception area of a multi-tenant facility). The difference between public resources and landlord resources are the restrictions needed to prevent public access to tenant data (such as an internal directory).
Remote tenant resources. The resources located in a remote location (in the case of networked tenants) or at a branch office installation.
A tenant status can be set to Occupied, Locked Out or Vacant.
If a tenant's status is set to Occupied:
the tenant's members behave as programmed in the Tenants form.
If a tenant's status is set to Locked Out:
the tenant's members can only call the Emergency Services number.
the tenant's members can receive calls from the default tenant (tenant 1).
all permissions granted to other tenants function as if the tenant's status was set to Occupied.
If a tenant's status is set to Vacant:
the tenant's members behave as if they were part of tenant 1 (landlord group).
all permissions granted to other tenant groups are denied.
Note: Before setting a tenant's status to Vacant, you must clear its programming in the Tenants form. As a result, the permissions granted to other tenants are no longer available, resulting in a loss of shared resources. Before changing the status of a tenant to Vacant, verify that it will not cause an appreciable loss of resources to other tenants.
In a non-tenant-based system, dialing zero rings all attendants in the system. In a tenant-based system, dialing zero from a set only rings the attendants assigned to that set's tenant (as programmed in the IP Consoles and DNI Consoles forms). You can give other tenants permission to use a given tenant's attendant using the Tenants form. This automatically gives the tenant's attendant permission to call the other tenants' sets.
For example, if tenant 3 gives tenant 2 permission to use its (tenant 3) attendants, tenant 2's sets can call tenant 3's attendants, but not tenant 3's sets (unless also given permission); in addition, tenant 3's attendants are automatically given permission to call tenant 2's sets.
Inward Non-dial-in trunk selection is carried out by the CO based on the service agreement between the system owner and the PSTN. Typically, the landlord purchases directory numbers from the PSTN, and makes arrangements in the leasing agreement to have the CO switch incoming non-dial-in calls on specific trunks (click for example).
Inward calls on DID trunks are presented by the CO on any available channel in the link. For some digital trunks, such as Digital E&M, Digital CO, and Digital DID, it is possible to have the CO switch calls for particular DID number over specific channels in the link. In this case, the management of these trunks for tenanting purposes is similar to the management of inward non-dial-in trunks.
For PRI links, while the CO does not offer the capability of extending specific DID calls on specific channels, the PRI Min/Max functionality can be used to dedicate minimum and maximum tenant resources (consider the case where there is a risk of a high traffic Call Center tenant starving out other tenants).
To route incoming dial-in calls to tenant-specific answer points, associate specific DIDs with tenant specific channels. Use digit modification specified in the Trunk Attributes form to direct the call to the desired answer point (see the Dial-in Trunks Incoming Digit Modification columns).
For PRI links, however, tenant DIDs cannot be presented on specific channels. In this case, presenting the call to tenant specific answer points would only work if the digit modification scheme defined in the Trunk Attributes form is applicable to all tenants; this may not be the case if tenants use different carriers since different carriers may use different numbering plans.
If trunks are given tenant numbers, and dialing devices are given tenant numbers, then when hunting for a trunk to use in a trunk group, the hunting algorithm selects a trunk based on the tenant of the dialing device.
Default system behavior permits only members of a tenant to seize devices belonging to that tenant. If a trunk group is constructed using a mixture of trunks belonging to several tenants, then when the various tenants dial digits terminating to the same trunk groups, each tenant seizes its own trunk, and is then restricted from seizing other tenants' trunks.
IP Trunks are not tenantable resources. You can use Interconnect Restriction or Class of Restrictions to prevent tenant members from using IP trunks to access other nodes in the network.
If system nodes are connected using IP or TDM DPNSS trunks, you can prevent tenant members from accessing these trunks by disabling the "Public Network Access via DPNSS" option in the members' Class of Service. This also restricts access to local IP trunks.
Tenant Night Switching Control allows one or more tenants (such as a night security desk console) to switch all tenants into day or night service.
Tenant-based night switching allows a tenant to assume day/night1/night2 switching behavior independently of the day/night service status of the system or other tenants. Tenant 1 day/night service always follows the system's day/night service status.
Attendant console events causing a change in the day/night status are restricted to day/night status of the tenant to which the console belongs, except as modified by Night Service Leader definitions.
If a "Dialed Day/Night Service - Activate" Feature Access Code causes a change in the day/night status, this change is limited to the tenant to which the set from which the feature access code was entered belongs, except as modified by Night Service Leader definitions.
The CP SERVICE DAY/NIGHT1/NIGHT2 maintenance command puts the landlord (tenant 1) and any other tenants that have specified tenant 1 as Night Service Leader into the specified day/night service.
Night Service behavior of redirected calls to defined alternate answer points depends on the night service status of the answer point (click for example).
Any circularity resulting from night service rerouting is handled as usual using forwarding/diversion/rerouting call control counters (click for example).
Night Service allows for the redirection of calls to alternate answer points for individual trunks. The answer point used depends on the selected mode of operation (day, night1, or night2). An answering point can be a single device (attendant console, station, trunk, or night bell) or a hunt group.
A Night Service Leader is a tenant that is defined as a Night Service Leader to some other tenant. If a Night Service Leader goes to night service, then the other tenant also goes to night service.
Tenant-based night service provides day/night1/night2 status to each tenant in the system. A change in the day/night status of a Night Service Leader will cause a corresponding change in the day/night status of its followers.
To avoid circularity, a tenant who is a night service leader should not have another tenant as a Night Service Leader. For example, if tenant 3 is the Night Service Leader for tenants 3 and 4, then in the Tenants form, the Night Service Leader field value for tenant 3 should be "3".
Multi-tenant service provides call restriction functionality on a tenant group basis. A tenant assigns permissions to other tenants in the Permissions Granted section of the Tenants form. The Permission Acquired section of the form shows which tenants have granted permissions to a given tenant.
Permissions can be configured to allow members of tenant A to call members of tenant B while barring members of tenant B from calling members of tenant A.
By default, members of a specific tenant are barred from dialing other tenant resources internally unless given permission by another tenant in the Tenants form.
Connection control is unidirectional; if members of tenant 1 can connect to members of tenant 2, members of tenant 2 may not necessarily be able to connect to tenant 1. This allows for a master tenant who can call everyone but whom everyone may not be able to call.
Permissions can be configured to allow tenants to share trunks.
A trunk is assigned to a tenant by entering the tenant's number in the Analog Trunks or Digital Trunks form.
The list of tenants that can share a particular trunk is defined in the trunk tenant's Tenants form entry.
When trunks and dialing devices are given tenant numbers, hunting for a trunk to use in a trunk group selects a trunk based on the tenant of the dialing device.
Each tenant can have its own Music on Hold source, as programmed in the Tenants form.
Tenant Music on Hold sources can be embedded or are connected through dedicated analog ports.
The maximum number of Music on Hold sources that can be deployed depends on the system configuration. See the Engineering Guidelines for more information.
Callers placed on hold hear the Music on Hold of the holder's tenant.
External callers placed on hold by an Attendant hear the Music on Hold of the tenant to which the DID number or answer point is assigned.
Internal calls to the landlord's attendants hear the default (system) Music on Hold.
You cannot dial, forward, transfer, or reroute a call to a directory number that corresponds to a tenant's Music on Hold source. If this happens, the user sees "INVALID DIALING" on the set's display or hears reorder tone, and the call is not allowed.
Background music is provided by a single system-wide source.
Music on Hold is presented to held parties in the following order:
Music programmed and configured for the tenant
Music programmed and configured for the system
Music programmed and configured for the held party
If no Music on Hold has been programmed and configured, the held party is connected to silence.
When changing or busying a music source, any caller listening to that music source hears silence, even when the music source is returned to service. This is because each music source is allocated the next available channel when it goes off-hook or is returned to service.
If a music source is no longer needed, you must delete it from the Tenants and Analog Sets forms.
To share the voice mail system with all tenants:
all voice mail ports must be assigned to a single tenant in the VM Ports form
the voice mail tenant must have calling permission from all other tenants
all tenants must have calling permission from the voice mail tenant.
Note: Assign the voice mail ports to the landlord (tenant 1) unless you don't want all tenants to have permission to call the landlord. Assigning the voice mail ports to the landlord automatically gives them permission to call all the other tenants.
Note: The voice mail system is only aware of Day/Night service changes invoked for the landlord. And although tenants can change Day/Service independently of the landlord, the voice mail greetings are based on the landlord's service mode. So, for example, when the landlord is in Day Service, the tenant's callers hear the landlord's open for business greeting even when the tenant is in Night Service.
To assign specific voice mail ports to each tenant:
assign one or more voice mail port to each tenant in the VM Ports form.
To assign different voice mail hunt group numbers for different tenant:
assign the voice mail ports for each hunt group to the desired tenant(s) in the VM Ports form.
To use Record-A-Call in a tenanted system:
all voice mail ports must be assigned to Tenant 1 (landlord)
all tenants that are allowed to use Record-A-Call must have calling permission from the landlord.
