| 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 the Oracle Communications Service Broker VPN application. It lists considerations for installing the VPN application software, setting up the VPN domain, and connecting VPN services to the external network.
The tasks covered in this chapter take you from installing the Service Broker VPN application software through connecting it to the communications networks on which it will run. At that point, Service Broker VPN services are ready for delivery to subscribing organizations.
Setting up the VPN application involves these tasks:
Install Service Broker VPN software as a Service Broker product installation option.
See "About Installing the Service Broker VPN Application" for installation considerations.
Create and secure the Service Broker VPN domains.
See "Considerations for the Service Broker VPN Domain" for information about Service Broker VPN domains.
Configure the data persistence mechanism. The Service Broker VPN application stores provisioning and statistical information in persistent storage.
See "Configuring Data Persistence" for information about setting up data storage.
Configure basic Service Broker VPN application settings using its MBean interface.
See "Configuring Basic VPN Application Properties" for details.
Enable VPN Provisioning API connectivity by opening an HTTP port in the Signaling Tier configuration.
See "Opening an HTTP Listening Port for the VPN Provisioning Service" for information about configuring the Signaling Tier for VPN Provisioning API connectivity.
Configure the application-facing IM instances used to integrate VPN services with the Service Broker functional architecture.
See "Creating the Application-Facing IM for VPN Services" for information about configuring the modules.
Configure the network-facing IM instances and other settings needed to connect VPN services to the SIP and SS7-based networks.
See "Connecting VPN Services to Telecommunications Networks" for information about configuring network-facing settings.
Configure orchestration for routing messages from the network layer to the VPN application and related services, such as IM- or IM-OCF services.
See "Orchestrating VPN Application Services" for orchestration information.
If using location-based features, such as call barring or screening based on location, configure location awareness features in Service Broker VPN.
See "Configuring Location Interrogation through HLR/HSS Systems" for information about enabling location-based features.
Configure external network components to accommodate VPN services in the telecommunications network.
See "Triggering VPN Services from the Network" and "Configuring Originating and Terminating Service Invocation" for external network considerations.
To install the VPN application software, you select it as an included component of the Service Broker installation in the Oracle Universal Installer.
In the Graphical Installation Mode, you include the VPN application software by selecting it in the Available Product Components page. On the page, the VPN application component appears under Network Applications as Virtual Private Network.
When using the silent installer script, include the VPN application in the installation by adding virtualprivate_network to the DEPENDENCY_LIST of the silentinstall.properties file.
After installing the VPN application software, you can remove it by starting the Oracle Universal Installer and clicking the Deinstall Product button. In the product list, choose the Virtual Private Network application from the Oracle home.
For complete information on installing the VPN applications and other Service Broker software, see Oracle Communications Service Broker Installation Guide.
The Service Broker VPN application is a component of the Service Broker processing domain. Therefore, before you can start configuring and using Service Broker VPN, you must create a processing domain or basic domain, which incorporates the components of both processing and signaling domains.
Oracle Communications Service Broker System Administrator's Guide contains general information on creating and managing Service Broker domains. This section describes specific considerations for working with domains when implementing Service Broker VPN.
Before you create the VPN domain, you should verify the general security settings for the domain. The settings determine the security features that are enabled in the domain you create.
In addition to common security settings applicable to other types of Service Broker products, a Service Broker VPN domain is subject to security settings specific for connections for its RESTful API. In test and evaluation systems, it may not be necessary to secure the connection. In all other cases, the connection must be secured.
The security features applicable to the API connection include Secure HTTP (HTTPS) and SSL-based client certification authentication.
Note:
In addition to SSL-based client certificate authentication, the VPN application authenticates client requests based on user name and password values passed in HTTP headers of API requests. See "Authentication and Authorization" for more information.The security features are controlled by property file settings. By default, the security settings are enabled, so that the domain is configured for maximum security. You should verify and modify the settings if needed.
The following Service Broker properties control the connectivity between API clients and the Service Broker managed server, which serves the RESTful API:
org.eclipse.equinox.http.jetty.https.enabled: Set to true to use HTTPS for the API connection.
org.eclipse.equinox.http.jetty.https.ports: Set to the port number you want to use for the secured HTTP connection.
Set these properties in the properties file located in Oracle_home/ocsb61/admin_server/properties:
For a web domain, edit the admin.properties file.
For a hosted domain, edit the hosting.properties file.
In addition, to allow the client to verify the identity of the managed server when negotiating the HTTPS connection, you must import the managed server's SSL certificate into the client's trusted keystore.
For details on creating and managing security certificates, see Oracle Communications Service Broker System Administrator's Guide.
When creating a secured domain, you must use https as the protocol value in the Domain URL that you pass to the domain creation script.
See Oracle Communications Service Broker Security Guide for complete information on securing the Service Broker installation.
To create a domain for Service Broker SVC, you use the create_domain_interactive.xml domain creation script.
When prompted for a domain type to install, select either Virtual Private Network. You choose the domain type by entering the index number that corresponds to your selection, as indicated in the script output.
For a Service Broker VPN domain, the script prompts you for a password for the built-in VPN provider administrator, as follows:
Enter a value for parameter 'admin.password':
The password you enter is stored in the Service Broker credential store. For information about the credential store, see Service Broker Release 6.1 Security Guide.
The VPN application supports both the service availability and service availability and continuity service mode options.
For general information about creating domains, see Oracle Communications Service Broker Release 6.1 Installation Guide.
Before creating the Service Broker VPN domain, you must set up the database that Service Broker uses to store VPN application data. Application data includes the policy configuration and information for the end users of VPN services. It also includes statistical data generated by the operation of the VPN services.
The VPN application works with these Oracle Database versions:
Oracle Database 10g Release 2
Oracle Database 11g Release 1 or Release 2
Note that VPN application does not support Oracle Coherence in-memory storage or Oracle Berkeley DB file-based storage. You must use Oracle Database for persistence.
To configure data persistence, you first set up the database. You then configure the connection to the database in the Service Broker configuration, as described in the following sections.
The VPN application includes a database configuration script that sets up the tables and schema required for VPN services. The script itself invokes separate SQL scripts, which perform the actual configuration of the database.
A SQL script is available for the VPN service, as well as for the SVC one number and SVC voice mail services. In addition, a SQL script exists for creating the statistical data tables and schema that are common to all services.
Only run the SQL scripts applicable to your implementation. For example, if using VPN services only, just run the VPN SQL script and statistical data script.
Before configuring data persistence, make sure the database is available by network to Service Broker. Also, you should have created a user account in the database for Service Broker. Oracle recommends that you create a user account on the database specifically for the use of the Service Broker VPN service.
To set up the database:
Open the following properties file for editing:
Oracle_home/ocsb61/admin_server/properties/create_db_table.properties
Configure the profile database settings, as follows:
profile.db.server: The IP address of the database server.
profile.db.port: The port on which the database listens for TCP client connections, typically 1521.
profile.db.dbname: The name of the database in which you want to store data, such as orcl for Oracle 11g. This is the database in which the script will create and format tables for the service and statistical data.
profile.db.user: The name of a database user who has privileges to access this database.
For example:
profile.db.server=10.10.1.125 profile.db.port=1521 profile.db.dbname=orcl profile.db.user=ocsb
Save and close create_db_table.properties.
Run the database configuration script:
Oracle_home/ocsb61/admin_server/create_db_table.sh
The script connects to the profile database you specified in common.properties.
Move any SQL script not relevant to your implementation from the SQL script directory to a backup location. The directory where the scripts are located is:
Oracle_home/ocsb60/admin_server/scripts/ddl/
The database configuration script invokes any SQL script it finds in this directory.
The scripts are:
er_vpn.sql: Creates database tables for VPN application services.
er_stats.sql: Creates database tables for statistical information generated by activities of the services.
er_ons.sql: Creates database tables for the SVC one number service.
er_voicemail.sql: Creates database tables for the SVC voice mail service.
At the following prompt, enter the password associated with the database user you identified in common.properties:
Please input password of profile database user
The script reads and applies the SQL scripts in the ddl directory. Informational log messages on the operation of the script appear on the screen.
Now see "Configuring the Database Connection" to configure the connection from the Service Broker Processing Tier.
After preparing the database, you can create the connection to the database in the Service Broker domain.
You can configure the database connection by using the Administration Console user interface or MBeans. The following instructions provide an overview of the procedure using the Administration Console user interface.
For complete information on configuring the database connection, see the information on data persistence in Oracle Communications Service Broker Release 6.1 Installation Guide.
In the Administration Console user interface, expand the OCSB node in the navigation tree.
Expand Domain Management.
Expand Data Store.
Click Persistent Stores.
In the JDBC Store tab, click New.
Note that the New button is not enabled unless the configuration is locked for editing in the user interface. For general information about using the Administration Console user interface, see Oracle Communications Service Broker Release 6.1 System Administrator's Guide.
In the dialog box, enter the following values:
CredentialKey: Use KEY, the default credential key name assigned to the profile database user by the database configuration script.
User: Use oracle_driver for the connection name, unless you have modified the default driver reference attribute for the VPN application.
Connection Factory: In most cases, this should be the built-in driver, oracle.jdbc.pool.OracleDataSource.
For the other fields, enter the values appropriate for your implementation. For more information on configuring the database connection, see Oracle Communications Service Broker Release 6.1 Installation Guide.
Click OK to save your database connection definition to the working configuration.
To enable client access to the VPN Provisioning API, you configure an HTTP listening port in the Service Broker Signaling Tier, as follows:
In the Administration Console user interface, expand the OCSB node in the navigation tree.
Expand Signaling Tier.
Expand SSU Web Services.
Click the General item.
Click the HTTP tab.
In the Server subtab, click the Network Access subtab.
Click the New button.
In the dialog box, enter the values appropriate for your HTTP listener for the VPN Provisioning API. This includes the local server address and port that clients will use to access the VPN Provisioning API.
For more information on configuring HTTP connectivity in the Web Services SSU, see Oracle Communications Service Broker Release 6.1 Signaling Server Units Configuration Guide.
Click OK to save the HTTP network access settings to the working configuration.
Click the Security Context tab.
For the root server context (/), change the default authentication mode to NONE. The default authentication mode, BASIC, should not be used with the VPN application, which uses its own authentication and authorization scheme.
After you commit the changes to the domain configuration, you must restart the managed Signaling Tier managed servers to have them listen for HTTP traffic on the new port.
After installing Service Broker with the VPN application, verify and, if needed, modify the VPN application basic operating settings. The VPN application exposes its basic operating settings as MBean attributes.
You can access the MBean interface by connecting to the Administration Console process with an MBean browser.
The MBean domain that contains the VPN application configuration is:
oracle.axia.app.vpn.vpnconfiguration
The vpnConfig MBean contains these three configuration categories:
callEngine
general
statConfig
To access the MBean configuration attributes:
If is not running, start the Administration Console.
Using a JMX MBean browser, such as the Java Monitoring and Management Console (JConsole) tool, connect to the Administration Console process.
See Oracle Communications Service Broker System Administrator's Guide for information on connecting to the Administration Console process to access configuration MBeans.
In the MBean browser, navigate to the vpnConfig MBean:
oracle:type=oracle.axia.cm.ConfigurationMBean,name=oracle.axia.apps.vpn.vpnconfiguration,version=6.1.0.SNAPSHOT,name0=vpnConfig
Navigate to the appAddress MBean, which is under the General node, and enter the address of the VPN application. You will use this address to identify the application from the SAL IM.
By default, it is sip:vpn@oracle.com.
The other vpnconfig attributes can typically remain at their default values. These attributes include:
imsList and inList settings are used internally by the VPN application to identify the underlying network associated with a particular session. Do not modify these values.
presence contains settings that the VPN uses to get mobile user location from HLR/HSS systems. See "Configuring Location Interrogation through HLR/HSS Systems" for more information on configuring HLR/HSS lookups with VPN services.
enableChargingRf is the switch that directs Service Broker VPN to generate accounting reports for the purposes of offline Diameter-based charging. See "Configuring Offline Charging for VPN Services" for more information.
statConfig lets you configure the busy period threshold value used to trigger notifications. See "Configuring CPS Threshold SNMP Traps" for more information.
maxNumOfRouterActors is the number of router actors in the system. The default value is 2. The minimum value is 1 and maximum is 100. A router actor can be considered a dispatcher for call requests. This is a performance-related setting that in most cases should remain at its default value.
The services of the VPN application are integrated with the Service Broker configuration through an IM in the processing tier. The VPN application works with the IM that serves as the interface to Service Broker applications, IM-ASF-SAL.
Service Broker routes call sessions initiated in external SS7 or IMS networks to the VPN application through an IM-ASF-SAL instance. The Service Broker VPN application initiates requests to external HSS or HLR system for user location interrogation through the IM as well. This section explains how to create the IM-ASF-SAL. See "Configuring Location Interrogation through HLR/HSS Systems" for information on creating the IM instance for the HLR/HSS system.
The IM-ASF-SAL is an application-facing IM specifically intended for use with Service Broker applications, such as Service Broker VPN and SVC.
To create the IM-ASF-SAL instance by using the Administration Console, follow these steps:
Lock the configuration for editing.
In the Processing Tier navigation tree, expand the Interworking Modules node.
Select IM Management.
Click the New button.
In the New dialog box, select IMASFSAL as the type of the module and type a name for the new module.
Click OK and, as indicated by the dialog box, click the Commit icon before modifying the module settings.
Lock the configuration again.
Select the IM instance you created from the navigation tree.
In the SAL Application Address field, specify the application address for the VPN application in SIP address format, such as sip:vpn@oracle.com.
This is the address you configured in "Configuring Basic VPN Application Properties" as the appAddress for the VPN application.
The other IM settings, which include session keep-alive and general SAL settings, are used to control connectivity between other Service Broker components and the VPN application component. In general, you can leave these settings at their default value unless you have specific requirements related to these settings in your network.
For more information on the settings, see Oracle Communications Service Broker Modules Configuration Guide.
Commit your changes to save the configuration and deploy it to the managed servers.
You can now configure orchestration for the VPN application.
The services provided by the VPN application work over SS7-based and IMS networks. To expose VPN services on those networks, you connect the VPN application to the network-facing IMs that connect to the external networks, as described in the following sections.
See "Configuration Walkthrough" for a sample walkthrough of the configuration steps described in this section.
The general steps for connecting VPN services to SIP networks through Service Broker are:
Create, activate, and configure an R-IM-ASF instance to exchange SIP traffic with external SIP networks.
Configure the SIP Signaling Server Unit (SSU) to accept calls from your SIP network nodes and route them to the R-IM-ASF that you created.
See "Configuration Walkthrough" for an example scenario of setting up SIP network connectivity.
The VPN application works with CAMEL Application Part v4 (CAP Phase 4) networks. It does not work with CAP Phase 3 or earlier versions. Therefore, the network-facing IM type to use with the VPN application is the IM-SCF CAP Phase 4.
The general steps for connecting VPN services to SS7 networks through Service Broker are:
Create, activate, and configure an IM-SCF-CAP Phase 4 instance to exchange SS7 traffic with external SS7 networks.
Configure the SSU SIGTRAN to accept traffic from your SS7 network nodes and route them to the IM-SCF-CAP Phase 4 that you created.
By default, Service Broker invokes originating and terminating functions for a session in separate dialogs. This is the recommended mode, particularly if the VPN service is available over both IN and IMS networks, because IMS networks operate in this manner.
To have originating and terminating functions invoked in a single IN dialog (or transaction) instead, set the MTC suppression code parameter. In this case, instead of separately initiated originating and terminating service transactions, the VPN application invokes originating and terminating service in a single transaction. It also adds to the network the MTC suppression code value to the response message.
The external Service Switching Point (SSP) must check messages for the suppression code, and, if present, avoid invoking the terminating functions.
See "Configuration Walkthrough" for an example scenario of setting up SS7 network connectivity.
As with other application-facing IMs, to route messages from network-facing IM to the VPN applications, you must add a filtering criteria for the IM to the orchestration rule.
In the orchestration rule, identify the IM-ASF-SAL you created for the VPN application. Specifically, given an IM named imasfsal_vpn, you edit an SM-LSS module and add an initial filter criteria as shown in Example 2-1:
Example 2-1 OE IFC rule to the IM
<?xml version="1.0" encoding="UTF-8"?>
<Sh-Data>
<Sh-IMS-Data>
<IFCs>
...
<InitialFilterCriteria>
<Priority>1</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:imasfsal_vpn.IMASFSAL@oracle.com</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>
...
</IFCs>
</Sh-IMS-Data>
</Sh-Data>
See "Configuration Walkthrough" for a complete orchestration example.
The VPN application can make call barring and call screening decisions based on the location of the called or calling party.
To enable the VPN service to make location-based decisions, you must enable HLR or HSS location lookups for the VPN services. The VPN application submits a location request when needed. For instance, for a call attempt on an SS7 network, if the VPN application cannot retrieve the location number of the called party from the IDP message, it submits a MAP Any Time Interrogation (ATI) command to the HLR through the IM-PSX configuration you specify.
Service Broker VPN assumes that the location number from a MAP ATI response uses the Country_CodeArea_Code format. For example, it interprets the value 861390 as country code: 86 and area code: 1390. If the MAP element cannot provide responses in this format, the internal Service Broker component that interprets the location information must be customized. For more information, contact Oracle.
To configure HLR or HSS lookups, follow these steps:
Create an IM-R-ASF-SAL instance for the VPN application to use to initiate location requests routed through the Service Broker.
Create an IM-PSX MAP instance that provides the interface to the external HLR or HSS system.
Configure orchestration so that messages to the R-IM-ASF SAL are routed to the IM-PSX you created.
Configure the presence attributes in the vpnconfiguration MBean.
In the oracle.axia.app.vpn.vpnconfiguration MBean, navigate to the presence attributes.
To access the settings, expand the following nodes: vpnConfig, callEngine, and then presence.
Verify and if needed modify the values for the attributes listed in Table 2-1:
Table 2-1 presence MBean Attributes
| Name | Description |
|---|---|
|
impsxDomain |
The domain identifier of the PSX domain for the Service Broker. The default value is ocsb-psx.net. |
|
notifyResFormat |
The content type of HLR interrogation requests. The default value is application/map-phase3+xml. |
|
ocsbHandlingModuleAddress |
The identifier, or alias, of the IM-ASF SAL instance that will accept location requests initiated by the VPN application. The default value is sip:imasfsal_2.IMRASFSAL@ocsb.com |
|
subsinfoType |
The type of information to be requested from the HLR/HSS system. The default value is presence;requested-info=mobile-location |
|
subsReqinitor |
The SIP address of the request initiator. In this case, it should be the SIP address of the installation. The default value is sip:vpn@ocsb.com. |
|
useHSSInIMS |
Set to true if interrogating an HSS system instead of an HLR. This affects the format of the request generated by the VPN application. The default value is false. |
For details on HLR/HSS integration, see the discussion of IM-PSX in Oracle Communications Service Broker Modules Configuration Guide.
The mechanism used to trigger VPN application services for a particular call varies between mobile-originated and PBX-originated calls. The VPN application data model configuration includes an attribute to facilitate a network triggering mechanism.
For mobile-originated calls, the VPN service is typically triggered using the O-CSI record of the subscriber end user. This is the standard subscription-based triggering mechanism in which an O-CSI parameter identifies the services associated with a subscriber in the HLR/VLR for that subscriber.
For PBX-originated calls, the provider may use a dialed number trigger or a trunk-based trigger to trigger VPN services.
In trunk-based triggering, all calls that traverse a specific line between the VPN subscriber's PBX and the MSC trigger the VPN service. This requires that the line is used exclusively by the subscribing organization, and thus all calls on that line should trigger VPN services.
In dialed-number triggering, the SSP triggers the VPN service based on a numeric prefix in the destination number. To use this method, configure the PBX that is local to the subscriber to add an identifying numeric prefix to dialed numbers. The SSP should use this prefix to trigger the VPN service for those calls. When the VPN service receives the call, it removes the prefix from the dialed number before continuing its call handling procedure.
An attribute of the VPN service provider configuration named pbxPrefix identifies the prefix value to the VPN application.
See "Modify VPN Service Provider" in "VPN Provisioning API Reference" for information on how to set the pbxPrefix value.
The call processing activities of the VPN application comprise both originating (O-CSI) and terminating (T-CSI) services. An originating service applies to on-net users who are initiating calls. A terminating service applies to on-net user who are receiving calls. For example, outgoing call barring is an originating service because it applies to the call originator. Incoming call screening is a terminating service because it applies to the called party.
Terminating services can be invoked either in the same IN dialogue as the originating services or in separate IN dialogues. By default, the VPN application is configured to invoke the originating and terminating services in separate dialogs. This matches the mode typically used in IMS networks and allows the greatest compatibility between SS7 and IMS session processing by Service Broker.
To have the session occur in a single dialog, you set the mobile terminated calls (MTC) suppression code in the VPN service provider configuration. This is controlled by the mtcSuppressionPrefix in the service provider configuration settings.
To have the session occur in a single dialog, you must also configure the SSP so that it does not redundantly invoke the terminating services. You can configure the SSP to suppress T-CSI based on the presence of the MTC-Suppression-Prefix header, which the VPN service adds as a prefix to the address in its response messages. The SSP should recognize this code, skip terminating service invocation, and strip the code from the address.
See "Modify VPN Service Provider" in "VPN Provisioning API Reference" for information on how to set the mtcSuppressionPrefix value.
The procedures in this section list the steps for performing an end-to-end configuration of a new Service Broker installation to implement VPN services.
The steps take you through the complete Service Broker configuration from an initial, empty state through VPN service orchestration. The configuration integrates the services of the VPN application with IMS and SS7 networks, along with an external HLR system used to provide location lookup services.
The steps provide sample values for variable data such as module instance names and connectivity settings.
The exact steps, instance names, connection settings, and other values that you use for your implementation may vary based on your network environment and requirements. Nevertheless, the following steps can provide a guideline for the steps needed to perform your own implementation.
Figure 2-1 shows the network components and the Service Broker configuration that results from the sample configuration.
Figure 2-1 Sample Configuration Environment
The walkthrough is organized into three parts:
To configure the Processing Tier by using the Administration Console:
Create an R-IM-ASF instance named rimasf_1. This IM connects the Service Broker Orchestration Engine layer to the external SIP network.
Create an IM-ASF-SAL instance named imasfsal_1. This IM instance serves as the application-facing IM between the Orchestration Engine layer and the VPN application.
Create an additional IM-ASF-SAL instance named imasfsal_2. The VPN application uses this IM to initiate location (presence) requests to external HLR or HSS systems.
Using a JMX client such as JConsole, set the ocsbHandlingModuleAddress attribute of the presence MBean to the name of the IM you created, imasfsal_2. See "Configuring Location Interrogation through HLR/HSS Systems" for more information.
Create an IM-PSX MAP Phase 3 instance named impsxmap3_1. This IM provides the interface to the external HLR or HSS system.
In the case of VPN services, the VPN application uses location lookups to make call screening and barring determinations that are based on location, for example, if the policy bars international calling.
Create an IM-SCF CAP Phase 4 instance named imscfcap4_1. This IM integrates the Orchestration Engine layer with the CAP4 SS7 network.
Update the imasfsal_1 configuration to refer to the default application identity for the VPN application:
Go to imasfsal _1 in the list of interworking modules.
Set the SAL Application Address field to sip:vpn@oracle.com. If this address has been modified from the default, set to the value appropriate for your case. See "Configuring Basic VPN Application Properties" for more information about setting the application identity.
After committing the new impsxmap3_1 instance, configure its settings as follows:
In the General tab, set the Alias to psx_map3.
In the General subtab of the SIP Subscription tab for the IM, set PSX SIP Domain to the domain appropriate for your SIP network, in the form shown by the default value, ocsb-psx.net. The Generate pending NOTIFY value can remain at the default, TRUE.
In the Map Handling tab, set gsmSCF Address to the address that identifies the IM in the network.
In the General tab, update the imscfcap4_1 configuration by setting the Alias value to imscf_ss7.
To configure the Signaling Tier by using the Administration Console:
In the Signaling Tier navigation tree, select the SSU SIP node.
In the SIP Server tab, update the Globally Routable User Agent URI value to the value appropriate for the managed servers in your signaling domain by using this syntax:
sip:host:port
Where host is the externally routable host or IP address of the managed server or managed server cluster in your environment, and port is the port number at which the managed server listens for SIP traffic.
In the Incoming Routing Rule tab, configure an incoming routing rule to the rimasf_1 IM instance. For example:
Name: irr_1
IP Address: any
Alias: sip:rimasf_1.RIMASF@ocsb
In the Signaling Tier navigation tree, click the SSU SS7 SIGTRAN node.
Click the M3UA tab.
In the Local Point Code tab, set the Local Point Code value to the point code in the network for the SSU node, for example, 128.
Click the Connectivity tab.
In the Local Systems subtab, create a new route definition with the following values:
Name: An identifying name for the local system instance, such as local_sys.
Routing Context: 128, or the local point code for the SSU.
SS7 Mode: ITU14
Traffic Mode: loadshare
IP Address 1: The externally routable IP address or host name for the managed server or managed server cluster.
In the Remote Systems subtab of the Connectivity tab, create a new route definition with the following values:
Name: An identifying name for the remote route, such as remote_sys.
Type: sg
IP Address 1: The IP address or host name of the external SS7 network entity to which Service Broker routes traffic.
Click the M3UA tab.
In the Network Mapping subtab, create a new SCTP association mapping with the settings appropriate for your system, as in the following example:
Name: An identifying name for the mapping, such as to_sg.
Side: client
Type: m3ua
Local Port: 2905
Remote Side: sg
Remote port: 2905
In the Network Routing subtab of the M3UA tab, create a new default network route with the settings appropriate for your network, as in the following example.
In this case, it is assumed that both the MSC and HLR system are hosted on the same remote node, identified by the remote point code number of 129:
Name: An identifying name for the default SS7 network route, such as to_msc.
Remote Point Code: The SS7 point code for the remote element, such as 129.
Primary Remote SIGTRAN System: The identifier of the mapping you created earlier, to_sg in this example.
Secondary Remote SIGTRAN System: To specify a backup system, enter the identifier of a secondary system to use if the primary is unavailable.
Expand the SSU SS7 SIGTRAN node and then click the SCCP tab.
In the Local SSNs subtab, create a new SSN definition for the CAP Phase 4 network with the following values:
Name: An identifying name for the subsystem definition, such as imscf.
SSN: The subsystem number associated with the local SCCP application, such as 146.
Description: An optional textual description of the local subsystem definition, such as imscf ssn.
Alias: The alias given for the Service Broker subsystem, which in this case should match the alias you specified earlier for the imscfcap4_1 IM instance (imscf_ss7).
In the Local SSNs subtab, create an additional SSN definition for the CAP Phase 4 network with the following values:
Name: An identifying name for the HLR subsystem definition, such as local_hlr.
SSN: The subsystem number associated with the local SCCP application, which in this case represents the HLR, such as 148.
Description: An optional textual description of the local subsystem definition, such as impsx ssn.
Alias: The alias given for the Service Broker subsystem, which in this case should match the alias for the impsxmap3_1 IM instance (psx_map3).
In the Remote PC and SSN Addresses subtab, create a new address definition for the remote MSC subsystem with the following values:
Name: An identifying name for the remote subsystem definition, such as msc.
Network Indicator: National Network
SSN: The subsystem number for the remote subsystem, in this case, for the MSC, such as 145.
Point Code: The point code for the remote SS7 node that provides the MSC services, such as 129.
Description: An optional textual description of the remote subsystem.
Alias: An alias for the remote subsystem, such as msc.
In the Remote PC and SSN Addresses subtab, create an additional new address definition for the remote HLR subsystem with the following settings:
Name: An identifying name for the remote subsystem definition, such as hlr.
Network Indicator: National Network
SSN: The subsystem number for the remote subsystem, in this case, for the HLR, such as 147.
Point Code: The point code for the remote SS7 node that provides the HLR services, such as 129.
Description: An optional textual description of the remote subsystem.
Alias: An alias for the remote subsystem, such as hlr.
Under the SSU SS7 SIGTRAN node, click the Routing tab and then click the Incoming Routing Rules subtab.
In the Incoming Routing Rules subtab, create two rules that route traffic between the SSU and the IM instances you created earlier, as follows:
The routing rule for the IM-SCF CAP Phase 4:
Name: An identifying name for the rule, such as imscf_rule.
Priority: 0
Module Instance: The identifier of the IM SCF CAP4 IM instance you created earlier, imscfcap4_1.IMSCFCAP4@ocsb.
The routing rule for the IM-PSX MAP Phase 3:
Name: An identifying name for the rule, such as map3_rule.
Priority: 0
Module Instance: The identifier of the IM SCF CAP4 IM instance you created earlier, impsxmap3_1.IMPSXMAP3@ocsb.
In the Incoming Routing Criteria subtab, create a criteria for each IM, as follows:
Select imsf_rule from the Parent list and create a new routing criteria with the following values:
Name: An identifying name for the criteria, such as imscf_criteria.
Session Key: DEST_ADDRESS_ALIAS
Value: The alias of the IM SCF CAP4 IM instance you created earlier, imscf_ss7.
Select the map3_rule from the Parent list and create a new routing criteria with the following values:
Name: An identifying name for the criteria, such as map3_criteria.
Session Key: DEST_ADDRESS_ALIAS application
Value: The alias of the IM-SCF CAP Phase 4 IM instance you created earlier, psx_map3.
To configure the Orchestration Engine logic by using the Administration Console:
In the Processing Tier navigation tree, click the Orchestration Engine node.
Change the default value of Subscriber Profile Receiver to OlpLSSInfoReceiver. In this case, the subscriber profile is served locally, based on the orchestration profile you configure next.
In the Processing Tier navigation tree, click the Supplementary Module node and then SM-LSS.
Select the default orchestration profile and click Update.
The Update dialog box appears. It contains the local iFC logic that controls the application chain applied by Service Broker. The OLP Data field contains the actual iFC text that specifies the orchestration logic.
Add the appropriate iFC text to the OLP Data field. Given the IM names used in this sample walkthrough, the iFC would be as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Sh-Data>
<Sh-IMS-Data>
<IFCs>
<InitialFilterCriteria>
<Priority>1</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>SUBSCRIBE</Method>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:impsxmap3_1.IMPSXMAP3@ocsb.com</ServerName>
<DefaultHandling>0</DefaultHandling>
<Extension>
<ForceB2B/>
</Extension>
</ApplicationServer>
</InitialFilterCriteria>
<InitialFilterCriteria>
<Priority>2</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:imasfsal_1.IMASFSAL@ocsb.com</ServerName>
<DefaultHandling>1</DefaultHandling>
<Extension>
<ForceB2B/>
</Extension>
</ApplicationServer>
</InitialFilterCriteria>
</IFCs>
</Sh-IMS-Data>
</Sh-Data>
This completes the sample configuration of the VPN application. The VPN application is now integrated with Service Broker and its services and external network components. Network messages addressed to the managed server or managed server cluster that hosts the VPN domain should now reach the VPN application.
The remaining chapters in this book explain how configure and provision VPN services for your subscribers, how to enable your subscribers to use those VPN services, and how to charge them for the services they use.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|