Beruflich Dokumente
Kultur Dokumente
0
Project Planning Guide
*1PA31003-S5020-A300-1-7619*
1P A31003-S5020-A300-1-7619
Siemens AG 2004
Information and Communication Networks,
Hofmannstrae 51, D-81359 Mnchen, Germany
Reference No.: A31003-S5020-A300-1-7619 Printed in the Federal Republic of Germany.
Subject to availability. Right of modification reserved.
5453TOC.fm
Nur fr den internen Gebrauch
Content
Content
1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Prerequisite Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Purpose of This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 How to Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Related Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0
1-1
1-1
1-1
1-1
1-1
1-1
1-2
2 Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.2 Technical Requirements Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.3 Key Customer Contact Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.4 Project Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.4.1 Project Definition Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.4.2 Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.4.3 Design Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.4.4 Integration Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.4.5 Validation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.5.1 Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.5.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.5.3 Data Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.5.4 Voice Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
2.5.5 SIP Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
2.5.6 Gateway Port Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
2.6 OpenScape Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.6.1 Infrastructure Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
2.6.2 OpenScape Application Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.6.3 Additional Devices and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.6.4 Deployment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
2.6.5 Deployment Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.6.6 Typical Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.7 OpenScape Security Tips for the Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.7.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
A Deploying Multiple Gateways for Scalability and in Geographically Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
A.1 Customer Deployments with Multiple Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
A.2 Topologies with Multiple Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
A.2.1 Gateways to PSTN and Corporate Network Topology . . . . . . . . . . . . . . . . . . . . A-2
A.2.2 Branch Office with Local PSTN and Voice Access . . . . . . . . . . . . . . . . . . . . . . . A-4
A31003-S5020-A300-1-7619, July 2004
HiPath OpenScape V2.0, Project Planning Guide
0-3
5453TOC.fm
Content
A.2.3 Branch Office with PBX for local PSTN and Voice Access . . . . . . . . . . . . . . . . . . A-6
A.3 Routing Dial Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
A.3.1 Dial Plan Secondary AOR Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
A.3.2 Incoming Call Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
A.3.3 Gateway Selection by Access/Barrier Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
A.4 Routing Needs for OpenScape Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
A.4.1 Multipoint Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
A.4.2 HiPath OpenScape Media Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
A.4.3 SIP Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
B Required Licenses and Software Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1 Infrastructure Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 OpenScape Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 OpenScape Administration Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4 MCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.5 Routing Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.6 Trace File Accumulator (TFA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.7 Early Deployment Mode (EDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.8 HiPath OpenScape Media Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.9 End Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.10 OpenScape Order Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-1
B-1
B-1
B-2
B-2
B-3
B-3
B-3
B-3
B-4
B-5
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Z-1
0-4
Preface
1.1
5453intro.fm
Preface
About this Guide
This user guide describes the project planning guide for HiPath OpenScape V2.0.
1.1.1
Prerequisite Knowledge
This guide is intended for Siemens service personnel and Siemens partners to help with the
project planning of HiPath OpenScape.
1.1.2
an executive summary to the CIO - what is required and the impact to his IT network
infrastructure
a guideline for sales consultants during the pre-sales phase and an outline of the specification and implementation phase
1.1.3
Chapter 2, Planning which describes the various project planning aspects of OpenScape
1.1.4
Related Information
The following information sources are available for HiPath OpenScape V2.0:
Online help
The online help provides explanations covering all areas of the user interface.
HiPath OpenScape V2.0 Installation Guide (A31003-S5020-S100) - provides the user with
detailed information on how to install HiPath OpenScape V2.0 as well as how to upgrade
from V1.0 SPCR to V2.0.
1-1
5453intro.fm
Preface
Documentation Feedback
1.2
Indirect channels: a separate password and profile is allocated in the Siemens Enterprise Business Area (SEBA) website for each partner company. This profile determines what the partner company can see or do. As only the local company and/or ICN
CS IC can determine whether a contractual relationship exists with the partner company, the LC must register the partner company.
KMOSS - https://kmoss.icn.siemens.de.
Documentation Feedback
To report a problem with this document, call your next level of support:
When you call, be sure to include the following information. This will help identify which document you are having problems with.
1-2
Planning
2.1
Executive Summary
5453planning.fm
Planning
Executive Summary
This planning guide describes the basics needed for the customer especially the CIO in determining how HiPath OpenScape fits into the customers environment. The areas covered include
project phases
hardware/software requirements
2-1
5453planning.fm
Planning
Technical Requirements Questions
2.2
Ask the following questions. If the answer is no to any, then stop and do not proceed further.
1.
2.
3.
Does the customer have a PKI infrastructure? If not, are they willing to install or purchase
certificates from a third party?
4.
If no LC Server is deployed, then is the customer willing to allow schema changes in their
Active Directory for Windows LC Server deployment?
5.
Will OpenScape users be in a single forest? If not, can these users be moved to one forest?
6.
Is the customer willing to allow schema changes in their Active Directory for OpenScape
deployment? If not, is the customer willing to have ADAM (Active Directory in Application
Mode) deployed in their environment?
a) Assuming a process for AD schema updates exist, how long does this take?
b) If too long, then a 2nd forest is required for trials which will eventually involve migrating
the trial users back to the 1st forest. If not acceptable, then will users want to have a
2nd account?
7.
Will the customer allow full access rights to E2000/2003 mailbox stores?
8.
Is the customer willing to allow the addition of groups and account at the root domain and
child domain levels in the default ou=users?
9.
Will the customer allow AD groups and accounts to be created with fixed names, chosen
by OpenScape, that cannot be modified?
10. For the HiPath OpenScape Media Server, will the customer allow the installation of Windows 2000 Advanced Server, US English version and locale setting?
11. Will the customer accept the connection between the HiPath OpenScape Media Server
and Exchange as not encrypted? If not, will they deploy an Exchange front end server for
security?
12. If the customer deploys optiPoint 400 SIP Phones, will the Active Directory user accounts
for the phone users be configured in the same domain as the Active Directory user account
for the LCS services?
For more information, refer to the HiPath OpenScape Professional Services (HOSc PS) Sales
Kit at the SEBA website or https://netinfo.icn.siemens.de/es/products/
prod_hipath_openscape_professional_services_v1_0/product/sk.
2-2
5453planning.fm
Planning
Key Customer Contact Profiles
2.3
Name
Phone #
Comment
Project Manager
Data Network
Technical Lead
Refer to Section
2.5.3 on page 2-8
Voice Network
Technical Lead
Refer toSection
2.5.4 on page 2-10
2.4
Project Phases
The project methodology provides a project guideline including a structured project approach
(i.e. project phases, well defined milestones and project tasks) and well defined project organization (i.e. project roles, responsibilities, tasks and required skills).
This methodology makes the project approach visible to all stakeholders, simplifies the initial
project planning and project control, ensures and increases project quality.
Key project parameters include timeline/milestones, content, quality and budget.
A31003-S5020-A300-1-7619, July 2004
HiPath OpenScape V2.0, Project Planning Guide
2-3
5453planning.fm
Planning
Project Phases
See process diagram below. For more details, refer to the HiPath OpenScape Professional Services documentation at https://netinfo.icn.siemens.de/es/products/
prod_hipath_openscape_professional_services_v1_0/product.
2-4
5453planning.fm
Nur fr den internen Gebrauch
2.4.1
Planning
Project Phases
Define and agree to the project goals, scope, approach and organization.
2.4.2
Analysis Phase
Analyze the customers environment (i.e. data and voice network infrastructure assessment,
business processes, data security analyses, and Microsoft infrastructure analyses).
2.4.3
Design Phase
Provide solution and describe in detail within the OpenScape Solution Design Document. Furthermore, the test plan and training concept are also defined.
2-5
5453planning.fm
Planning
Requirements
2.4.4
Integration Phase
2.4.4.1
Prepare the customers environment either in Production Mode or Early Deployment Mode (see
Section 2.6.1.1 on page 2-14.
2.4.4.2
Installation Phase
Subsequently, the OpenScape System will be installed and configured accordingly. During the
deployment phase, the entire technology deployment takes place. Meanwhile, all OpenScape
end users are trained.
2.4.5
Validation Phase
This phase starts with the tests as outlined in the test plan. After that the OpenScape system
will be used by the designated pilot users. This phase ends with the OpenScape pilot sign-off.
After successful deployment testing follows the final project sign-off.
The OpenScape project ends with a project review and customer feedback meeting called the
Project Conclusion Workshop.
2.5
Requirements
Figure 2-1
2-6
5453planning.fm
Planning
Requirements
2.5.1
Hardware
2.5.1.1
Assumptions - (3 events per user per hour) where events include phone calls, portal calls, instant messages and status changes)
Server
100/250 Users
Processor/Memory/HD
500/750 Users
Processor/Memory/HD
OpenScape Server
P4/2 GB/
P4 Xeon/2 GB
MCU Server
P4/1 GB/>10GB HD
P4/1 GB (1 - 2 servers*)
Media Server
P4/2GB/>18 GB HD
two P4 Xeon/2 GB
Note: * The number of MP servers is dependent on the amount of conference resources used
(also multiprocessors units can be used).
2.5.1.2
Minimal Configuration
The OpenScape, MCU, LCS and MS SQL can be installed on the same server (P4 Xeon/2 GB).
The HiPath OpenScape Media Server needs to be on a separate 2nd server (P4/2 GB).
2.5.1.3
Assumptions - (6 events per user per hour) where events include phone calls, portal calls, instant messages and status changes)
Server
100/250 Users
Processor/Memory/HD
500/750 Users
Processor/Memory/HD
OpenScape Server
P4/2 GB/
two P4 Xeon/2 GB
MCU server
P4/1 GB/>10GB HD
P4/1 GB (1 - 2 servers*)
Media Server
P4/2GB/>18 GB HD
four P4 Xeon/2 GB
Note: * The number of MP servers is dependent on the amount of conference resources used
(also multiprocessors units can be used).
A31003-S5020-A300-1-7619, July 2004
HiPath OpenScape V2.0, Project Planning Guide
2-7
5453planning.fm
Planning
Requirements
2.5.2
Software
Refer to Appendix B, Required Licenses and Software Prerequisites for further details.
2.5.3
Data Network
The HiPath OpenScape connects to and is part of the customers existing messaging infrastructure. Like any other server/application, it is the customers responsibility to ensure the
proper evaluation, planning and design of the network, capacity, and bandwidth which are essential to a successful installation and deployment.
2.5.3.1
Active Directory
OpenScape system installation and configuration will require the following roles and tasks (one
person may have two or more of these roles):
1.
2.
3.
2-8
Schema Administrator
Make Active Directory schema modifications required for the LC Server (note: this in
only required for the first LC Server installation in the forest; this is not required if customer already has an LC Server in any domain in the same forest)
Make Active Directory schema extensions required for OpenScape (note: a preparation step as well as domain preparation steps)
Add the OpenScape Services Groups of the child domains to this root group as members
Domain Administrator
A31003-S5020-A300-1-7619, July 2004
HiPath OpenScape V2.0, Project Planning Guide
5453planning.fm
Nur fr den internen Gebrauch
4.
5.
Assign the OpenScape LC Server as the home server for OpenScape users
6.
7.
Perform OpenScape installation and configuration tasks. This activity will be done by
Siemens personnel, SI or VAR.
DNS Administrator
8.
Planning
Requirements
One for the optiPoint 400 SIP phones if they are deployed
One for the MS SQL Server if it is deployed on a different machine than the OpenScape main server
Exchange Administrator
Provide access rights to OpenScape service account on the Exchange mailbox and
public folder stores for Exchange servers where OpenScape users have mailboxes
2.5.3.2
Firewall Requirements
The firewall must be configured to publish the web site to direct web requests to the OpenScape
server. Also, for access from the outside, the proper ports for http and https must be opened
(80 and 443, respectively).
Portal Access
2-9
5453planning.fm
Planning
Requirements
In a customer environment, there may be a need for a user to access their portal through the
internet. This requires going through a firewall.
To enable this capability, the firewall needs to be able to configure server certificates. A certificate is required for a proxy, that is, if the HTTPS is bridged ending up with one HTTPS connection from the browser to the proxy and one HTTPS connection from the proxy to the portals Web
application.
If there is no proxy, HTTPS is tunneled directly from the browser to the portals Web application.
This is not secure and is not recommended.
HiPath OpenScape is managed through WMI which uses RPC (Remote Procedure Calls) to
access the OpenScape Server. Therefore, OpenScape could be managed through a firewall by
configuring RPC Dynamic Port Allocation. Refer to Microsoft Knowledge Base Article 154596
for more information. It is recommended to use an application like Remote Desktop to connect
to a server within the firewall instead of allowing RPC calls through the firewall for security reasons.
2.5.4
Voice Network
PBX administrator:
Identify and configure available trunk circuits (i.e. T1, E1, analog as required by the SIP
gateway) to be used by the OpenScape SIP gateway for inbound and outbound calls.
Create DID phone numbers for all OpenScape users. These DID numbers will serve as the
one-number service for these users. Each OpenScape user needs a DID phone number
that will be used by callers to reach OpenScape users via the PSTN.
There are a number of cases where a given customer may wish to deploy multiple SIP
gateways, e.g., multiple sites or more trunk capacity needed. For a detailed description of
such scenarios and the configuration tips, refer to Appendix A, Deploying Multiple Gateways for Scalability and in Geographically Distributed Systems.
2.5.5
SIP Phone
The Siemens optiPoint 400 standard phone offers a SIP variant which is full interoperable with
OpenScape. Several features of this phone may have planning implications and should be taken into account during the project planning phase. They are as follows:
2-10
5453planning.fm
Nur fr den internen Gebrauch
1.
Planning
Requirements
Power-over-LAN
This SIP phone is equipped with a power-over-LAN interface on the LAN port and complies
with the IEEE802.3af standard. Eight-wire Ethernet cables are required for this phone. If
this interface is used to supply power to the phone, the power source must be a limited
power source PowerHub compliant with IEC 60950. Another power option for the phone is
an external AC adaptor which is not included with the phone and must be ordered separately.
2.
3.
Terminal IP address
2-11
5453planning.fm
Planning
Requirements
4.
Audio Mode
CODEC: Determine the optimal audio transfer codec for the customer's environment.
G711 preferred is used for uncompressed audio transmission suitable for broadband internet connections. G729 preferred is used for compressed audio transmission suitable for
connections with different bandwidths, G729 always is used for compressed audio transmission suitable for connections with low bandwidths.
COMPRESSION: IF the compressed audio mode is selected, then use this function to select one of the two compression encodings. The default value is G729.
5.
6.
7.
Programmable Keys
This SIP phone is equipped with 12 function keys of which 11 are user programmable in
two levels the function key "Stop/Escape" is not programmable. Five of these keys come
already preassigned in the first level.
8.
2.5.6
Gateway ports are required for calls where an OpenScape user is connected with a port via
the gateway. These are, for example, connections to CO lines or to phones connected to a
PBX. When OpenScape users use an Associated Device as their Preferred Phone, at least
one gateway port is used for every call since the caller itself needs to be reached via a gateway port. In the case of Associated Devices, if the called party also happens to be CO or PBX
line, two gateways ports will be required, one to connect to the callers Preferred Phone and
one to connected to the called party.
2-12
5453planning.fm
Planning
Requirements
The following requirements were taken into account in the calculation: each OpenScape user
has 0.1 Erlang for the external traffic via a gateway channel. Loss of accessibility is estimated
at 1 to 1.2%. A 0.1 Erlang means that the station is busy for 10% of working hours (3.6CCS/
Line). This should not be estimated for call centers or similar organizations.
Here are the gateway port requirements under three traffic scenarios:
A - 0% of OpenScape users on Associated devices; no additional conferencing traffic.
B - 50% of OpenScape users on Associated devices; no additional conferencing traffic (Associated devices require a gateway connection for all calls).
C - 50% of OpenScape users on Associated devices; default assumptions about additional adhoc conferencing:
1.
2.
3.
With those assumptions, the following table can be used for planning the size of your system:
The number of ports will vary based on application traffic requirements that are not covered in
the assumptions used by this table.
# Users
Scenario A
Scenario B
Scenario C
(0% Associated Devices) (50% Associated Devices) (50% AD + conferencing)
100
18
30
51
250
36
63
98
500
64
116
172
750
91
168
242
Table 2-3
Please note that the actual number of gateways required in order to provide the required number of ports in Table 2-3 is a function of:
1.
Gateway port capacity: higher capacity gateways may be available from gateway vendors
that provide all the required ports on a single gateway with a single IP address
2.
Multiple gateways configurations: multiple gateways may be deployed to satisfy the higher
port requirements. However, such configurations may have some limitations and will therefore need to be planned carefully. Please refer to Appendix A, Deploying Multiple Gateways for Scalability and in Geographically Distributed Systems for details.
2-13
5453planning.fm
Planning
OpenScape Configurations
2.6
OpenScape Configurations
Version 2 of HiPath OpenScape supports a broad variety of deployment options, which are dependent on customer environments and functional requirements.
An OpenScape Application deployment requires various components:
Additional devices or clients, which are used by the user or the system to connect to
the current communication infrastructure and to the OpenScape application
Multiple OpenScape systems can be deployed in the network as well. However, the features
are not completely transparent in such an environment. Mainly, the users of a other OpenScape
are handled like external users and information (like presence information) is not shared between different OpenScape systems.
2.6.1
Infrastructure Components
OpenScape is an application based on the Live Communication Service (LCS) product of Microsoft and requires
OpenScape installation requires Active Directory schema extensions. If the customer does not
allow Active Directory changes the system needs to be deployed in Early Deployment Mode,
which does require additional software components, but does not require a schema change in
Active Directory.
LCS deployments require Active Directory schema changes as well and are still required.
2.6.1.1
Production Mode: This is the recommended mode. OpenScape schema extensions to the Active Directory are configured.
2-14
5453planning.fm
Nur fr den internen Gebrauch
Planning
OpenScape Configurations
Early Deployment Mode: This mode can be used as alternative when the customer does not
allow the Active Directory to be extended for HiPath OpenScape. Note that LCS schema extensions are still required.
There can only be one mode for the whole Active Directory forest at a given time. It is possible
to migrate from EDM to Production Mode once the Active Directory schema can be extended.
The advantage of running HiPath OpenScape in Production Mode is better performance especially in a larger deployment in terms of number of users and multiple locations.
Using the Early Deployment Mode requires the following additional components
2.6.2
2.6.3
SIP Gateways
SIP phones
2-15
5453planning.fm
Planning
OpenScape Configurations
OpenScape Client
The portal interface does not require any client installation. However, for Outlook or
Messenger integration OpenScape client installation is necessary.
2.6.4
Deployment Rules
There is a set of rules which need to be adhered to for the system to work successful. The next
section depicts then more concrete implementation scenarios.
1.
2.
All server components of one OpenScape system need to be installed in the same domain
with the exception of RD (see rules 5 and 6 below).
3.
An OpenScape installation requires one or more LCS installation in the same forest
4.
5.
The Routing Dispatcher (RD) needs to be installed on each LCS in the forest.
An RD installation is not required if
7.
The LCS can be installed in a different domain (implies also to RD in rule 5.).
8.
Users on multiple LCS in different domains can be supported with one OpenScape installation and as well with multiple OpenScape installations.
9.
OMC can be installed in different domains (there is always an OMC installed on the OSCore system) of the same forest.
10. All Windows 2003 components can be installed on the same server or separate servers.
This includes:
2-16
LCS with RD
MS-SQL
A31003-S5020-A300-1-7619, July 2004
HiPath OpenScape V2.0, Project Planning Guide
5453planning.fm
Nur fr den internen Gebrauch
OS-Core
MCU-MC
MCU-MP
TFA
EDM
OMC
Planning
OpenScape Configurations
11. An existing MS-SQL 2000 installation can be extended to be used for an OpenScape installation.
12. An MCU-MC does not require a separate server and should reside with one MCU-MP.
13. MCU-MP residing on a separate machine guarantees voice quality in a higher traffic model
scenario. Up to 4 MPs can be deployed, but a single MP is only bound by the CPU performance and will not limit itself to 72 channels. E.g. a dual processor machine can support
144 channels.
14. There is only one MS per OpenScape system installation.
15. MS requires Windows 2000. It is not recommended to install additional software components on this server.
16. Multiple Exchange servers are supported, but
2-17
5453planning.fm
Planning
OpenScape Configurations
2.6.5
Deployment Models
Figure 2-2
2-18
5453planning.fm
Nur fr den internen Gebrauch
Figure 2-3
Planning
OpenScape Configurations
2-19
5453planning.fm
Planning
OpenScape Security Tips for the Administrator
2.6.6
Typical Configurations
The following table allows to identify typical configurations based on the number of users and
the traffic model. The normal traffic model assumes a call volume of 3 calls per user per hour
and the high traffic model assumes a call volume of 6 calls per user per hour.
Traffic Scenario
100/250 Users
Normal
High
Table 2-4
2.7
Machine 1
OS-Core
LCS + RD
MS-SQL
MCU (MC+MP)
TFA
EDM (optional)
Machine 2
Media Server
Machine 1
OS-Core
LCS + RD
MS-SQL
Machine 2
Media Server
Machine 3
MCU (MC+MP)
500/750 Users
Machine 1
OS-Core
LCS + RD
MS-SQL
Machine 2
Media Server
Machine 3
MCU (MC+MP)
Machines 4, 5, 6 (if required)
Machine 1
LCS + RD
Machine 2
OS-Core
MS-SQL
Machine 3
Media Server
Machine 4
MCU (MC+MP)
Machines 5, 6, 7(if required)
Typical Configurations
There is a document on the SEBA and KMOSS website that provides security tips to help a
system administrator secure the OpenScape environment and enhance a companys own security policy.
These tips are not intended to replace or substitute for a companys own security policy.
On the KMOSS website, this document can be found at https://kmoss.icn.siemens.de/livelink/
livelink.exe?func=ll&objId=2322890&objAction=View&nexturl=%2Flivelink%2Flivelink%2Eexe
%3Ffunc%3Dll%26objId%3D1242024%26objAction%3DBrowse.
2-20
5453planning.fm
Nur fr den internen Gebrauch
2.7.1
Planning
OpenScape Security Tips for the Administrator
Kerberos
OpenScape supports a cross-realm scenario where the SIP phone user and the LCS are
homed in different domains/realms. More than one domain controller (DC) and corresponding
Kerberos Distribution Center (KDC) are involved when the Kerberos client on the phone tries
to get a ticket to access the LCS service. The different domains need to be in the same forest
and a trust relationship needs to be set up between the domains. Cross forest Kerberos authentication is not supported.
2-21
5453planning.fm
Planning
OpenScape Security Tips for the Administrator
2-22
mutiplegateways.fm
Deploying Multiple Gateways for Scalability and in GeoCustomer Deployments with Multiple Gateways
A.1
OpenScape V2 is an application that runs on top of the Microsoft Live Communications Server
2003 (here referred to as LCS). As such it leverages the infrastructure and topologies the LCS
supports. This is true too for the support of multiple Gateways and in regards to dial plans and
routing.
A.2
The LCS supports many different topologies. The ones shown here are typical examples.
Microsoft recommends to set up an LCS as Front End Server (FES) which interfaces to all the
Gateways in the system (see Appendix A Setting Up IP-PSTN Connectivity, Microsoft Office
Live Communications Server 2003 Reference Guide Published: August, 2003). This has the
advantage to limit the impact of potentially complex routing rules as well as IPSec setup to this
Server and not to have to replicate these through the system.
In this chapter we do not address complex dial plans. The examples given assume access code
based Gateway selection. Please see Section A.3 on page A-7 on more advanced dial plans.
Most of the scenarios are shown with separate inbound and outbound gateways. You can use
separate gateways or a single gateway to handle incoming and outgoing calls.
Furthermore we show most of the scenarios using an LC Server as FES to connect the LCS
network to the Gateways. This is not a requirement to connect Gateways to the LCS network.
You can connect the Gateways directly to e.g. your OpenScape LC Server as well. You will have
to modify the example routes accordingly.
A-1
mutiplegateways.fm
A.2.1
A.2.1.1
The OpenScape LC Server connects via Gateways to the PSTN and Corporate Voice Network.
A-2
mutiplegateways.fm
Nur fr den internen Gebrauch
A.2.1.2
Deploying Multiple Gateways for Scalability and in GeographiTopologies with Multiple Gateways
Here, the FES connects the SIP world to the PSTN and the Corporate Voice//TDM Network.
A-3
mutiplegateways.fm
A.2.2
A.2.2.1
This example expands the scenario above with a Branch Office Deployment that allows users
in a remote location (Location B) to allow these Branch Office users to use local Gateways to
the PSTN and Corporate Voice Network.
Such a configuration is especially desirable for the PSTN aspect as users otherwise would have
to have a telephone number with the country and area code of the main office (Location A). So
a Branch office that has only PSTN access but uses the main office for access to the Corporate
Voice Network is possible as well.
A-4
mutiplegateways.fm
Nur fr den internen Gebrauch
A.2.2.2
Deploying Multiple Gateways for Scalability and in GeographiTopologies with Multiple Gateways
This example expands the scenario above with a Branch Office Deployment that allows users
in a remote location (Location B) to allow these Branch Office users to use local Gateways via
FES to access the PSTN and Corporate Voice Network.
Such a configuration is especially desirable for the PSTN aspect as users otherwise would have
to have a telephone number with the country and area code of the main office (Location A). So
a Branch office that has only PSTN access but uses the main office for access to the Corporate
Voice Network is possible as well.
A-5
mutiplegateways.fm
A.2.3
Branch Office with PBX for local PSTN and Voice Access
A.2.3.1
Many customers have existing corporate voice networks and manage a large number of PBXs.
Many of the existing PBX installation have Least Cost Routing set up.
This example can take advantage of the Least Cost Routing feature in the PBX.
As in the Branch office example above users in Location B can access PSTN and Corporate
Voice Network locally. Again this allows us to provide users in Location B with telephone numbers that have country and area codes appropriate to their geographic location.
A-6
mutiplegateways.fm
Nur fr den internen Gebrauch
A.2.3.2
Many customers have existing corporate voice networks and manage a large number of PBXs.
Many of the existing PBX installation have Least Cost Routing set up.
This example can take advantage of the Least Cost Routing feature in the PBX.
As in the Branch office example above users in Location B can access PSTN and Corporate
Voice Network locally. Again this allows us to provide users in Location B with telephone numbers that have country and area codes appropriate to their geographic location.
A.3
A.3.1
Each Live Communication Server (LCS) user is assigned a Primary AOR (Address of Record
- SIP address as published in AD) which is also used as Primary AOR for HiPath OpenScape.
In addition each HiPath OpenScape user can be assigned up to two Secondary AORs which
represent the internal extension number and the public E.164 DID number. These Secondary
AORs are also stored in Active Directory (or ADAM), but are unknown to LCS.
All Secondary AORs consist of a numeric user part and the domain part of its Primary AOR,
e.g. a user with Primary AOR tim@siemens.com may have the Secondary AORs 1234@siemens.com and 15615551234@siemens.com.
A-7
mutiplegateways.fm
The extension and DID Secondary AORs can be configured manually for each user or system
wide number conversion rules can be set up to derive the numeric part of these Secondary
AORs from one of the following Active Directory user attributes: Telephone Number, Home
Phone, Pager, Mobile, or IP Phone.
An example for user Tim is:
Primary AOR in Active Directory: tim@siemens.com
Telephone Number in Active Directory: (561)555-1234
OpenScape Servers number conversion rules for
Extension: retain trailing 4 digits of Telephone Number field and prefix with digit 2
DID: retain all digits of Telephone Number field and prefix with digit 1
Tims Secondary AORs would then be:
Extension Secondary AOR: 21234@siemens.com
DID Secondary AOR: 15615551234@siemens.com
As these Secondary AORs are not known to LCS itself special attention will need to be given
to the routing of these Secondary AORs. This is because LCS is not aware of Telephone Numbers, but only of Active Directory Users, which do not normally follow a telephone number routing hierarchy, but follow a domain based model.
A.3.2
HiPath OpenScape version 1 supports only a single Secondary AOR and therefore the PSTN
trunks had to be provisioned to present the called party number as an extension. In HiPath
OpenScape version 2 this is not necessary anymore since both a public E.164 DID number and
an extension are supported.
A.3.2.1
PSTNs usually provide the extension number as called party number to the gateway. CO trunks
may also be provisioned to provide only partial digits, called Dialed Number Identification Service (DNIS). In these cases the gateway shall append the domain part of the users Primary
AOR to the received digits.
An example for a call from the PSTN to Tim:
Called Party Number provided by PSTN to GW: 21234
A-8
mutiplegateways.fm
Nur fr den internen Gebrauch
Number conversion rules for Extension: retain trailing 4 digits of Telephone Number field
and prefix with digit 2
Tims Extension Secondary AORs would then be: 21234@siemens.com
Extension Secondary AOR provided by GW to LC Server: sip:21234@siemens.com
The HiPath OpenScape Routing Dispatcher deployed on the LC Server will intercept this call
to sip:21234@siemens.com and route it to that users assigned OpenScape Server for further
processing.
A.3.2.2
It is also possible to get the CO trunk provisioned to provide called party numbers as fully qualified E.164 numbers. The E.164 number should have the format Country Code + National
Destination Code + Subscriber Number. This number should not contain any access or barrier codes.
In these cases, as in the short number dialing, the gateway shall append the domain part of the
users Primary AOR to the received digits.
If such a configuration is requested from a service provider, then the DID Secondary AORs
must be configured using E.164 numbers. If Active Directory already contains the users E.164
numbers, then the DID number conversion rules should be set up to have the DID Secondary
AORs configured for the users match the DID Secondary AORs received from the gateway.
An example for a call from the CO to Tim:
Primary AOR in Active Directory: tim@siemens.com
Telephone Number in Active Directory: (561)555-1234
Number conversion rules for DID: use Telephone Number field and prefix with digit 1
Tims DID Secondary AORs would then be: 15615551234@siemens.com
Called Party Number provided by CO trunk to GW: 15615551234
DID Secondary AOR provided by GW to LC Server: sip:15615551234@siemens.com
A.3.2.3
Normally, gateways, SIP phones, and terminal adapters will append a single configurable domain to the target telephone number e.g. they see 1234 as the incoming number and add siemens.com as the domain, thus making this 1234@siemens.com.
This will pose a problem if you have a Primary or Secondary AOR scheme that has multiple
different domains used as the base of the AORs. 1234@siemens.com will never reach
1234@icn.siemens.com unless you have some special static routes that handle this.
A-9
mutiplegateways.fm
Therefore we limit ourselves to addressing scenarios that use a single domain as the domain
used for AORs and secondary AOR. OpenScape provides no special support for AORs in multiple domains and therefore we recommend a single domain for the Primary or Secondary
AORs.
A.3.3
To support multiple gateways, PBX-style barrier codes can be used. For example we can design a system where a user would dial 9+PSTN number to dial into the public network and 8 +
internal number to dial into the corporate voice network.
In an environment with multiple sites it is often desirable to connect locally to the public or corporate network instead of routing all calls through a central GW.
In this chapter we develop routing tables for the topology described in Section A.2.3 on page
A-6.
Location A has the following number spaces and access codes:
Location A and B have a number overlap. As long as none of the OpenScape secondary AOR
overlap with the other numbers in the overall system, OpenScape will not have an issue, but it
will be impossible to dial PBX users in Location A and B that have the same number. To solve
this we will have to make some tough choices:
1.
Use a special code to dial internal PBX users in Location B. So we define that all PBX
users in Location B will have to be dialed as 8xxxxx when dialed from within the LCS
network.
2.
Alternatively we could allow the users to use an access code to allow calling Location
B PBX users. E.g. Access code 8 to call PBX users in Location B.
3.
Have users in location B always dial a number that allows us to differentiate calls e.g.
they dial internal numbers as 277xxxxx and their OpenScape Number space is
27774xxx. Unfortunately LCS only support suffix matching so 277* may match Location A PBX users as well as Location B PBX users. Therefore we would have to make
the users in Location A dial 492xxxx to contact the Location A PBX users.
A-10
mutiplegateways.fm
Nur fr den internen Gebrauch
In this case we choose option 1 as this solved the PBX number overlap as well as potential
overlaps when we move PBX users to OpenScape in the future.
For option 1 with gateway directly connected to the OpenScape LC Server, the routing table
would be1:
0*@*
->
PBX GW Location B2
8*@*
->
PBX GW Location B2
9*@*
->
2*@*
->
For option 1 with gateway connected to OpenScape LC Server via FES, the routing table in the
FES would be:
0*@fes.foo.com3
->
PBX GW Location B2
8*@fes.foo.com3
->
PBX GW Location B2
9*@fes.foo.com3
->
2*@fes.foo.com3
->
The routing table in the LCS Home Server for OpenScape would be:
*@foo.com4
->
*@FQDN5
->
2*@*
->
0*@*
->
8*@*
->
9*@*
->
Notes:
1-
The routing tables in this example are not complete. You will have to add additional routes as described in Section A.4 on page A-12.
2-
This requires the Gateway to strip off the first digit before dialing out
3-
4-
foo.com means the user SIP URI domain name (i.e. SIP:userA@foo.com)
5-
FQDN is the Fully Qualified Domain Name of the LCS Home Server for OpenScape
A-11
mutiplegateways.fm
A.4
A.4.1
Multipoint Controller
A route for the MCU has to be set on the OpenScape home server only. Please refer to the
OpenScape Installation Guide; specifically, the chapter on Installing MCU and the section in the
appendix on the OpenScape RTC Tool.
A.4.2
A route for the Media Server has to be set on the OpenScape home server only. Please refer
to the Media Server documentation and the section in the appendix on the OpenScape RTC
Tool in the OpenScape Installation Guide.
A.4.3
SIP Gateways
In addition to routing the numbers to gateways, gateways also need trusted static routes to
route requests that are part of a session of an incoming call to the gateway. Otherwise the LCS
would not trust the responses of these requests.
So if you have a gateway vega100.iris.boreas.net, you would need a route entry on the OpenScape LC Home Server to route *@vega100.iris.boreas.net to the gateway.
Also of course a gateway will need a trusted static port for incoming calls as described in the
additional gateway documentation and the section in the appendix on the OpenScape RTC
Tool in the OpenScape Installation Guide.
A-12
licenses.fm
Required Licenses and Software Prerequisites
Infrastructure Components
B.1
Infrastructure Components
Server License
required?
MS Exchange Server
2000/2003
CALs
required?
CAL License
Type
Quantity
User Mode
1 Server license + 1
CAL/user
Note 1
MS LCS
Version 1.0.4949
Yes
Yes
Note 1
No
No
Note 1: If the customer is licensed for Microsoft Exchange under Software Assurance or an
Enterprise Agreement before October 1, 2003, the customer is likely already licensed for Live
Communications Server 2000. Refer to Microsoft for details as licensing provisions are subject to change at Microsofts discretion. Some helpful links are: http://www.microsoft.com/education/?id=livecommservertransition and http://www.microsoft.com/office/livecomm/howtobuy/
default.mspx.
Note 2: Active Directory Application Mode (ADAM) is a part of Microsofts fully integrated
directory services available with Windows Server 2003. ADAM can be downloaded at http://
www.microsoft.com/downloads/details.aspx?FamilyId=9688F8B9-1034-4EF6-A3E52A2A57B5C8E4&displaylang=en.
B.2
Component
Server License
required?
CALs
required?
License Type
Quantity
OpenScape Base
Package
Yes
n/a
User
B-1
licenses.fm
Component
Server License
required?
CALs
required?
License Type
Quantity
OpenScape User
Package
n/a
Yes
User
No
No
OpenScape
Routing Dispatcher
No. Included in
OpenScape
Base Package
No
n/a
n/a
MS Windows
Server 2003
Standard or Enterprise Edition
Yes
Yes
User Mode
CAL, and
Server Mode
server
MS SQL Server
2000 and SP 3
Standard or Enterprise Edition
Yes
No
Processorbased
Note 1
No
n/a
n/a
Microsoft ADAM
(refer to Note 2 in
Section B.1)
No
n/a
n/a
No
B.3
The only license needed per client is MS Windows 2000, MS Windows 2003, or MS XP Professional.
B.4
MCU
Component
Server License
required?
CALs required?
License
Type
Quantity
OpenScape MCU
No
n/a
n/a
B-2
licenses.fm
Component
Server License
required?
CALs required?
MS Windows Yes. One for each server. Up No. Only one set of
Server 2003
to 4 servers may be required CALs is sufficient to
Standard or Ento support all 288 ports
access all Win200x
terprise Edition
servers
B.5
License
Type
Quantity
Server
Routing Dispatcher
B.6
B.7
B.8
Component
Media Server
Server License
required?
CALs required?
No. Included in
No CALs.
Base OpenScape Thirty Media Server
system
ports included but additional ASR/TTS
sessions licenses
may be required
CAL
License
Type
Quantity
n/a
1 ASR/TTS session
is provided in Base
OpenScape package. Up to 29 more
may be purchased.
MS Windows
2000 Advanced
Server + SP4 minimum
Standard Edition
Yes
User
n/a
Speechify TTS
Scansoft V2.0
Yes. Already in
OpenScape
product structure
No
No
n/a
B-3
licenses.fm
Component
Server License
required?
CALs required?
CAL
License
Type
Quantity
OSR Scansoft
Yes. Already in
OpenScape
product structure
No
n/a
n/a
MSDE 2000 +
SP3
No with purchase
of Win2K Server
No
n/a
n/a
VocalOS
(Vocalocity)
No with purchase
of Win2K Server
No
n/a
n/a
Note 3: According to Microsoft, the fact that no additional CALs are required for the Media
Server is based on the assumption that all access to the Media Server is directed through
OpenScape and LCS. If in the future, we decided to add features to the Media Server that may
enable direct access to it (without going through OpenScape), additional Windows CALs may
be required.
B.9
End Points
End Point
Server License
required?
CALs
required?
CAL
License Type
Quantity
OptiPoint 400
n/a
Already covered
by OpenScape
user license
n/a
n/a
Windows Messenger
Version 5.0
n/a
n/a
n/a
n/a
MS Windows 2000 or
MS Windows XP Professional
n/a
n/a
n/a
B-4
licenses.fm
B.10
This section shows three examples of OpenScape V2.0 orders and lists all the required components. The examples include some variations in Microsoft licensing agreements.
Item
Number of OpenScape users; accessible from various endpoints like multiple PCs, SIP phone, voice/self-service portals
150
90
400
72
30
150
10
25
48
24
4 x 48
70
10
100
No
Yes
Yes
Enterprise Agreement
No
No
Yes
25 user packages
15
10
25
10
25
Hourly
Hourly
Hourly
Hourly
Hourly
Hourly
Hourly
Hourly
Hourly
Customer Configuration
OpenScape Components
Microsoft Components
B-5
licenses.fm
Item
150
90
145
*Note: For the successful implementation of the HiPath OpenScape project, HiPath OpenScape Professional Services are required (refer to HOSc PS description).
B-6
5453IX.fm
Index
Index
Hardware 2-7
High Traffic Call Model 2-7
configuration
minimum complete server 2-15
Kerberos 2-21
Key Customer Contact Profiles 2-3
M
minimum complete server
configuration 2-15
Multipoint Controller A-12
N
Normal Traffic Call Model 2-7
F
feedback, documentation 1-2
File Transfer Protocol (FTP) Server 2-12
Firewall Requirements 2-9
Fully Qualified E.164 Number Dialing A-9
P
Portal Access 2-9
Power-over-LAN 2-11
Production Mode 2-14
Project Phases 2-3
R
requirements 2-7, 2-8
Root Domain Administrator 2-8
Z-1
5453IX.fm
Index
T
Technical Requirements 2-2
Topologies with Multiple Gateways A-1
Trace File Accumulator (TFA) B-3
V
Validation Phase 2-6
Z-2
www.siemens.com/hipath
The information provided in this document contains merely general descriptions or characteristics of performance which in case of actual use do
not always apply as described or which may change as a result of further
development of the products.
An obligation to provide the respective characteristics shall only exist if
expressly agreed in the terms of contract.
*1PA31003-S5020-A300-1-7619*