| Oracle® Communications Service Broker VPN Implementation Guide Release 6.1 Part Number E29462-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker VPN Implementation Guide Release 6.1 Part Number E29462-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure and provision the services of the Oracle Communications Service Broker VPN. It describes how to populate the VPN data model to configure and provision VPN services.
After installing the Service Broker VPN software and performing the initial setup, you configure and provision VPN services by populating the VPN data model by using the VPN Provisioning API.
Figure 4-1 shows an overview of the VPN data model.
The objects in the data model represent the logical components of the system, such as subscribers, user devices, end users, and policies. Collectively, the state of the data objects determines the features, behavior, and availability of VPN services.
In terms of the data model, the general steps for implementing VPN services are:
Configure the settings of the VPN service provider.
Add an administrative user as an AdminUser object for each subscriber organization to which VPN services will be deployed. Create additional provider and subscriber administrators as appropriate.
Add a VPNSubscriber object for each VPN subscribing organization.
Configure the private numbering plan and VPN features for a VPN subscriber as attributes of the VPNSubscriber object.
To specify the policy, configure the usage policy for the subscriber by using VPNProfile, AccessControlItem, and WorkingTime objects.
Add users for each subscriber by creating VPNUser, Person, and VPNClosedUserGroup objects.
In a production deployment, the tasks would be partitioned between the provider administrator and subscriber administrators. For example, provider administrators typically configure global VPN settings and create administrator accounts, whereas subscriber administrators typically add and manage end users, user devices, groups, and policies for their VPN subscription.
Subscriber administrator tasks should be exposed in the web application created for the purpose.
The VPNServiceProvider object defines the provider organization, and includes information such as the provider name, address, and description. It also includes settings that have global scope, such as a global call barring list that applies to users across all VPN subscribers in the system.
Only one VPNServiceProvider instance exists in the data model. The service provider object is created automatically; you only need to configure it.
Figure 4-2 shows the attributes of the VPNServiceProvider and related objects.
Figure 4-2 VPNServiceProvider, VPNSubscriber, Administrator Objects
A service provider can have any number of VPNSubscriber object instances. The provider and each subscriber instance are associated with one or more AdminUser objects. A subscriber administrator identifies the subscriber for which it is the administrator by its vpnID attribute value.
To view the existing attributes of the provider, use the "Get VPN Service Provider" operation in the VPN Provisioning API. You can modify the provider settings using the "Modify VPN Service Provider" operation.
An administrative account represents an individual or application that performs the configuration, provisioning, and maintenance tasks for the VPN. When security is enabled for the VPN Provisioning API, requests to the API must contain the valid credentials of an administrative user. To create an administrator account, use the AdminUser object.
The data model defines two types of administrative accounts:
Provider administrator (role 1)
Subscriber administrator (role 4)
The administrator's role determines the privileges associated with the account, as described in the following sections.
A provider administrator can create additional administrative user accounts using the "Create Administrator" operation. Operations also exist for getting and modifying existing administrator account information.
Provider administrators have full access to the operations in the VPN Provisioning API. The API operations can affect any subscriber instance in the system. For example, a provider administrator can add VPN users for any subscribing organization.
The VPN application services includes a built-in provider administrator named admin. After installing the VPN application software, you use this account to create additional administrator accounts.
Note:
The admin user password is set when you configure the database used to store application data for the VPN application. See "Configuring Data Persistence" for more information.The built-in admin user has several characteristics that user-created provider or subscriber administrators do not:
It is created automatically.
It cannot be deleted.
Its attributes control whether API access requires authentication and whether the VPN Provisioning API service validates the data submitted with the Batch Loader tool.
To create additional provider administrators, you use the "Create Administrator" operation, specifying a role value of 1 for the new user. Note that the role value of an existing administrative user account cannot be modified.
Subscriber administrative accounts are intended to be used by the individuals or applications in the subscribing organization that perform the subscriber-specific configuration and administration tasks for the VPN. For example, this administrator can create and manage policy profiles, configure subscriber settings, and add users and groups.
While provider administrators have full access to the operations in the VPN Provisioning API, subscriber administrators can access only a subset of those operations.
Furthermore, subscriber administrators can access the operations only in the context of their own VPN subscriber instance. That is, the API ensures that an administrator for one VPN subscriber cannot get or modify the data associated with other subscribers.
Before you create a VPNSubscriber instance, an administrator for the subscriber must exist. Therefore, the first step in provisioning VPN services to a newly subscribing organization is to create the administrator for the new subscriber.
To create a subscriber administrator, you invoke the "Create Administrator" operation, passing 4 as the new administrator's role value. Note that the role value of an existing administrative user account cannot be modified.
A VPNSubscriber object contains the configuration settings and user data for a single organization. This object defines the private numbering plan, usage policy, user devices, and other VPN properties for the organization. You must create a VPNSubscriber object for each organization to which you are deploying VPN services.
Figure 4-2 shows the data model of the VPNSubscriber and adjacent objects in the VPN data model.
The VPN subscriber also defines the scope of on-net calling within the VPN. Calls between users within the subscriber organization are subject to number translation, reduced charging rates, and other on-net calling features.
To create a subscriber, first create the administrator for the VPNSubscriber instance, specifying the unique ID of the VPN subscription as the vpnID attribute of the administrator object. You cannot create a VPNSubscriber instance unless an AdminUser for it exists.
You create the VPNSubscriber object by using the "Create VPN Subscriber" operation, passing as its vpnID the same value you specified for the corresponding attribute of the administrator. Additional subscriber-related operations exist for getting all subscribers in the VPN, getting information on a specific subscriber, and deleting a subscriber.
After creating the subscriber object, the provider or subscriber administrator can configure the private numbering plan for the subscriber, and other features of the VPN, as described in the subsequent sections.
A partner VPN relationship defines an association between two or more subscribing organizations. Members of the partner organizations can be subject to reduced charging rates for calls between them. Also, subscriber administrators can define call screening or blocking conditions based on the partner relationship.
While charging differentiation may apply to partner calls, other features of the VPN, such as short code dialing, do not apply to partner VPNs.
To specify a partner relationship for a subscriber, you use the following attributes of the VPNSubscriber object:
partnerVPNSwitch: Determines whether the VPN Partner feature is enabled for the subscriber.
partnerVPN: Identifies the partner organization by VPN ID.
The VPN application distinguishes calls between partner organization users for purposes of call charging. The VPN application identifies calls from partner on-net users by using the call type PARTNER_ONNET_TO_ONNET.
The private numbering plan describes the schema for allocating device extensions, and other dialing properties in the VPN. Device extensions, or short codes, are the abbreviated numbers that on-net users dial to call other on-net users.
The subscriber administrator assigns an extension to a mobile device by creating a VPNUser object that represents the device. This object contains the private number of the device (or on-net extension), as well as the actual, public number of the device. The Service Broker VPN uses this mapping to perform number translation for the device.
For a PBX device, the VPNUser object maps a range of public numbers to private extensions. In this case, the VPN user actually represents multiple devices.
In general, the design of the private numbering plan varies by subscriber, and is based upon factors such as the size of the organization and its existing numbering plan and network services. For example, a small organization can use shorter extension numbers, whereas a larger organization must use longer extension numbers.
An organization may choose to allocate mobile device extensions based upon its employees' existing desktop telephone extensions, for example, by adding a numeric prefix to the existing extension. Thus, an end user with a desktop number of 445 would get a mobile device extension of 8445.
Whereas the VPN self-management application contains the actual logic that allocates the user extensions, the VPNSubscriber object can specify restrictions on what those extension numbers can be. Specifically, the subscriber administrator can restrict the length of extensions and specify an exclusion list that blocks certain numbers or patterns of numbers from being allocated.
You restrict the length of extension numbers by using the maxExtensionNumberLength attribute of the VPNSubscriber object. The maximum extension length can be from 2 through 10 digits. The VPN application uses this value to validate new extension requests and to determine whether a dialed number is a public call or a private call.
When an on-net user dials a number that is longer than the maximum extension length, the VPN application immediately regards the number as a public number, without checking the private number store. If the dialed number is the same length or shorter than the maximum extension length, the VPN application first checks the store of allocated extensions, and regards the call as public only if the extension does not match one in the store.
A number allocated as a private extension must be unique within the organization's private telephone network. The subscriber should also avoid allocating numbers that conflict with public numbers.
The maximum extension length setting can help prevent conflicts between an organization's private extensions and public telephone numbers. However, telephone services may exist on the network with numbers that are the same length or shorter than the maximum extension length value. For example, an internal voice mail service or a public number such as the 911 emergency service in the U.S., present potential extension number conflicts.
The VPN Provisioning API provides the following mechanisms that help prevent extension number conflicts:
Exclusion list: Specifies numbers and number patterns that cannot be allocated as extensions. If the API client application attempts to allocate an extension in the exclusion list, an error is generated and the attempt fails.
Escape code: A numeric prefix which, if dialed by a user, directs the VPN application to forego number translation of the subsequently dialed number.
You specify an exclusion list using the exclusionList attribute of the VPNSubscriber object. The attribute can contain specific numbers or number ranges. To specify a range, use a wildcard symbol (*). For example, if an exclusion list includes 111*, the Service Broker VPN will not allocate any extension that starts with 111, such as 1112 or 1114. If the client application attempts to allocate an excluded number, the API returns the following error message:
Phone extension[1114] is not allowed because it conflicts with [111*] in VPN's Exclusion List
An escape code enables end users to make direct calls from an on-net device. By dialing an escape code before a number, the end user directs the VPN application to bypass the usual number translation logic.
For example, a network has a preexisting voice mail service at the number 113 and a mobile user at the same extension. Given an escape code of 8 in the subscriber's dialing plan, an end user can reach the voice mail service by dialing 8113. Alternatively, the end user can reach a device assigned the extension by dialing 113 without the escape code.
To specify an escape code, use the escapeCode attribute of the VPNSubscriber object. An escape code can consist of one or two digits. If you configure an escape code, be sure to configure an exclusion list that prevents the allocation of extensions that begin with the escape code digits.
Note that if the subscriber requires an escape code for off-net calls and permits private calling, users who make a call using the private call marker do not also enter the escape code. See "Enabling Private Calling" for information about private calling and the private call marker attribute.
To provision an end user on the VPN, the administrator identifies the user's mobile device as an on-net device by using the VPNUser object. Figure 4-3 shows the data model for VPNUser objects and related objects.
Each VPNUser object represents an end user's device (whereas the Person object represents the end user). The device represented by the VPN user can be a mobile device or a PBX device (or more typically, a range of PBX devices). Both types of users are represented by the VPNUser object. The memberType attribute determines whether the user is a mobile device or a PBX device.
A VPN user for a mobile device may optionally be associated with a Person object. The Person object represents a human user on the VPN. A VPN user can reference only one Person, but multiple VPN users can reference the same Person object. In other words, an end user can have multiple devices on the network, but a device can have only one owner.
A closed user group is a collection of VPN users. A group provides a convenient way to manage the policy for multiple users at a time. You specify a group with the ClosedUserGroup object.
You create users, virtual users, and other objects related to end users in the context of a particular subscriber. The subscriber to which the user belongs is determined by the URL path used to invoke the create operation; the subscriber is not specified as a parameter in the operation body.
The following sections provide more information about user-related objects.
The subscriber administrator must create a VPNUser object for each mobile VPN on-net device.
The VPN user maps a private extension on the VPN to a device's public telephone number. The VPN application uses this mapping to perform the number translation for calls to the device.
The VPN user can define the usage policy for the device (in the form of the home and roaming profile), or the device can be subject to the policy specified for its group.
Use the "Create VPN User" operation to create a VPNUser object for the mobile device, specifying 0 as the value of the memberType attribute.
A PBX-based user represents a set of PBX-connected telephones that, depending on the policy, the VPN service can regard as on-net devices.
Configuring a PBX-based VPN user is similar to configuring a mobile VPN user. In both cases, the VPNUser object maps a public number to a private extension. Also the same policy restrictions that apply to mobile devices can apply to PBX on-net devices. However, unlike a mobile device, the PBX user typically represents multiple devices.
To configure PBX devices with a VPN user, you use wildcards in its public number and private extension values. The VPN application uses the wildcarded portion of the number to match a private number to its public number.
For example, given a VPN user with a private number value of 3* and a public number of 001415553*, the VPN application would route calls made to the extension 37722 to the public number 0014155537722. All other extensions belonging in the PBX system identified by 3 would be similarly mapped.
To create a PBX-based VPN user, invoke the "Create VPN User" operation, specifying 1 as the value of the memberType attribute.
The Person object represents a human user in the VPN. The end user attributes include the person's name, unique ID, and VPN instance.
An instance of a Person object is associated with a device through the personID attribute of the VPNUser object. A Person object can have any number of on-net devices. By associating devices to human users in this manner, the Person object enables administrators to list devices in the VPN by end user.
Use the "Create Person" operation to create a Person object. Use the personID attribute of the VPN user object to map the end user to a mobile device.
A VPNClosedUserGroup object represents a collection of one or more VPN users. User groups provide a convenient mechanism for managing policy for multiple devices at a time.
User groups can also provide conditions for on-net calling. That is, you can define an access control rule that permits or blocks a call depending on whether the call is between members of the same group.
User groups in the data model can be nested, providing inheritance for the restrictions defined in groups. A child group that defines its own restrictions also inherits the restrictions defined in the parent group, which may in turn inherit from its parent, and so on.
A user who belongs to a child user group is subject to the rules of both the user's immediate group and any parent group in the hierarchy to which the child belongs.
The VPN application applies group rules in a bottom-to-top manner. When evaluating a call, the VPN application first checks the call restriction rules in the user's immediate group. If the call does not match a rule in the user's group, it checks the rules in the groups immediate parent, and so on. When a rule matches the call, the rule action is applied without evaluating additional rules in a parent group.
A group cannot have more than one parent group, but a parent can have multiple child groups.
A general approach for designing nested groups involves defining parent groups that contain restrictions that are appropriate for a wide range of users, and child groups that specialize the restrictions for a subset of users.
You can create a closed user group using the "Create User Group" operation. You then add members to the group by identifying the group in the closedUserGroupID attribute in each VPNUser object to be associated with the group.
A VirtualUser object represents an external number that has a private extension in the VPN. The virtual user role is useful for external parties that VPN users must frequently call, such as a corporate travel agent or health care insurance provider.
Depending on the provider's charging plan implementation, calls to and from virtual users may be subject to reduced charging rates. The VPN application identifies calls involving virtual users in call accounting records with the call types VIRTUAL_ONNET_TO_ONNET and ONNET_TO_VIRTUAL_ONNET.
In addition to charging differentiation, the virtual user role can serve as a basis for access control decisions. The administrator may define access control rules that permit or block calls to virtual users based on call type, time of day, and other factors.
The VirtualUser object contains the settings for the virtual user. The object maps a private extension to the public number of the external user, as shown in Figure 4-4.
You create a virtual user for a subscriber by invoking the "Create Virtual User" operation. The VPN Provisioning API also provides operations for getting all virtual users for a subscriber and for getting detailed information for a specific virtual user.
Administrators can control activities on the VPN using call control rules. For example, rules can limit the length of calls, block international calls, or permit calls only during working hours.
The VPN data model provides two primary mechanisms for specifying call control rules:
Blacklists identify telephone numbers to be blocked either as outgoing call destinations or incoming call sources.
Profiles can block or permit calls based on a variety of conditions, such as the time of day or the off-net status of the called party.
Note:
An end user can bypass a policy restriction by using the private call feature, if enabled for the subscriber. See "Enabling Private Calling" for more information.Various objects in the VPN data model can define call control rules. The VPN application evaluates the rules by objects in the following order:
VPNServiceProvider
VPNSubscriber
VPNUser
ClosedUserGroup
Parent ClosedUserGroup
If the VPN application evaluates all rules without encountering a match, it permits the call. If the VPN application encounters a matching rule that specifies a blocking action, the call is immediately blocked without further rule evaluation.
Note that if the VPN application encounters a matching rule that allows the call, subsequent rules are evaluated.
A blacklist specifies numbers that are blocked as either call destinations or call sources. A call screening blacklist controls incoming calls, while a call barring blacklist controls outgoing calls.
As shown in Figure 4-5, the administrator can configure call barring blacklist items in either the VPNServiceProvider or VPNSubscriber object. The call screening blacklist is an attribute of the subscriber only.
The administrator can apply a blacklist by specifying a telephone number or number range as the blacklist attribute value. Number ranges are specified with wildcards ("*"). The following examples cause the blacklisting results indicated:
A value of "*" blocks all calls. For example:
"callBarringBlackList":["*"]
Prefixes that end in wildcards block calls that start with those prefixes (for example, "4321*" blocks "43211234" and "2281*" blocks "228138").
Complete phone numbers (for example, "55523940" or "55523941") block calls specifically to those numbers.
A VPNProfile object defines a VPN usage policy. The policy can limit calls by duration or restrict calls by call type, time of day, or other conditions.
An administrator can apply different policies based on whether users are in-network or roaming. As shown in Figure 4-6, the VPNUser and VPNClosedUserGroup objects can apply profiles.
Figure 4-6 Data Model Related to Profiles
The callScreeningList and callBarringList attributes of the VPNProfile object contain and array of access control items. An access control item defines an access rule, which specifies a condition and the result of a match: whether the matched call is blocked or permitted.
Note that call screening and call barring blacklists, which are attributes of VPNServiceProvider and VPNSubscriber objects, define blocking conditions based on the called or calling number only. Access control rules, however, can block or permit calls based on a variety of conditions. See "Using Access Control Rules" for more information about access control rules.
When an access rule is matched, the server event log indicates the name of the matching profile and the reason for the match. The event log is written to the server.log file located in the managed server directory. The event log provides detailed information on activities of the managed server.
By default, if an on-net user calls another on-net user by dialing that user's public phone number rather than the user's extension, the VPN application treats the call as an on-net to off-net call. The administrator can direct the VPN application to regard such calls as on-net calls by setting the forcedOnNet attribute of the VPNSubscriber object to true.
If forced functionality is enabled, instead of immediately treating a dialed number that exceeds the maximum extension length as a public number, the VPN application checks the data store for the number. If it finds that the dialed number is the public number of a user in the data store, the call is forced to on-net status.
All call processing functions and policies that apply to other types of on-net calls apply to forced on-net calls as well.
If private calling is enabled for a subscriber, end users can enter a private call marker before dialing a number. A private call marker is one or two numbers or symbols, such as an asterisk (*), and distinguishes the call as a private call.
A private call is a mobile-originated call that bypasses policy restrictions applicable to on-net calls. The VPN application identifies the call as a private call in charging records, allowing the provider to implement dual invoicing. In dual invoicing, the provider applies charges for privates calls to the private account of the end user.
In charging records, a private call is identified by the Dual-Invoicing attribute. For a private call, the value of this attribute is PRIVATE_CALL. Providers should use this value to implement alternate charging, in which an end user's personal use of the network is charged separately from the user's business-related use.
To initiate a private call, the end user dials the private call marker digits before dialing the number. The provider administrator specifies the value of the private call marker as the value of the privateCallMarker attribute of the VPNServiceProvider object. The private call marker value specified for the provider applies to all subscribers for which private calling is enabled.
Call restriction policies, caller identification, and other VPN features are bypassed for the call.
If the subscriber configuration requires the use of an escape code to dial off-net numbers, use the private call marker to preempt that requirement. That is, when making a call using the private call marker, the end user does not precede the public number with the escape code to reach the external destination.
Administrators can enable private calling for a subscriber by setting the privateCallEnable attribute to true in the Subscriber object.
Calling line identity presentation is a telephone service that presents the caller number to the called party's device, if the device is capable of displaying this type of information. This enables the called party to identify the caller before answering the call.
The VPN application can present private numbers or public numbers as the call source to on-net call recipients. You can configure the identity presentation mode by using the privateNumberCLI property, which is an attribute of the VPNSubscriber object.
When privateNumberCLI is set to true, private identity presentation varies depending on the call type:
For an on-net to on-net call and for an on-net to PBX on-net call, the VPN application presents the private number of the caller.
For an on-net to virtual on-net, partner on-net, or off-net call, the VPN application presents the public number of the caller.
For a PBX on-net to on-net call, the VPN application presents the private number (PBX extension) of the caller's fixed-line telephone.
When privateNumberCLI is set to false, the VPN application always presents the caller's public number to the called party.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
