SAP CONTACT CENTER
INFRASTRUCTURE
Software version 7.0
Document version 1.1
© SAP AG
©SAP AG 2007
© Copyright 2014 SAP SE. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express
permission of SAP SE. The information contained herein may be changed without prior notice.
Some software products marketed by SAP SE and its distributors contain proprietary software components of
other software vendors.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of
Adobe Systems Incorporated in the United States and/or other countries.

Innovaphone, IP3000 and IP6000 are registered trademarks of innovaphone AG.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc.

Hewlett-Packard is a registered trademark of Hewlett-Packard Company. (Hewlett-Packard®)

HP is a registered trademark of Hewlett-Packard Company. (HP®)

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli,
Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of
IBM Corporation.

Audiocodes and Mediant are trademarks or registered trademarks of Audiocodes Limited.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented
and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

Oracle is a registered trademark of Oracle Corporation.

SNMPc, is a trademark of Castle Rock Computing.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the world. All other product and service names mentioned are
the trademarks of their respective companies. Data contained in this document serves informational purposes
only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP SE and its affiliated
companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and
SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP
Group products and services are those that are set forth in the express warranty statements accompanying
such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
CONTENTS
1
Introduction to SAP Contact Center infrastructure
1.1
Introduction to site landscapes and connectivity
1.2
Introduction to environmental and facility recommendations
1.3
Introduction to server hardware, operating systems and software
1.4
Introduction to gateways and SIP trunks
1.5
Introduction to data center LAN
1.6
Introduction to customer LAN
1.7
Introduction to storage systems
1.8
Introduction to telephony and data connections
1.9
Introduction to user terminals
1.10 Introduction to security
1.11 Introduction to availability and manageability
1.12 Introduction to deployment, software distribution and configuration
1.13 Introduction to sizing
5
5
7
7
8
8
10
12
12
13
13
14
15
16
2
Site landscapes and connectivity.
2.1
Modules
2.2
Communication Channels
2.3
Virtual units
2.4
Interconnecting SAP Contact Center systems
18
18
20
20
22
3
Environmental and facility recommendations
3.1
Physical security
3.2
High availability
23
23
24
4
Server hardware, operating systems and software
4.1
Servers
4.2
Operating systems
4.3
Software
26
26
32
32
5
Gateways and SIP trunks
5.1
Distributing gateways and SIP trunks
5.2
Connecting to a PBX
5.3
Miscellaneous settings
5.4
Cisco gateways
36
36
37
39
39
6
Data center LAN
6.1
Performance
6.2
Availability
6.3
Multiple Sites
40
40
42
45
7
Customer LAN
7.1
Availability
7.2
Ability to carry voice
50
50
50
8
Storage systems
8.1
RAID arrays
8.2
SAN systems
52
52
52
3
CONTENTS
9
Telephony and data connections
9.1
Telephony connections
9.2
Data connections
53
54
54
10
User terminals
10.1 CDT and Convergence
10.2 IP Desk Phones
57
57
57
11
Security
11.1 Network traffic control
11.2 Identification, authentication and authorization
11.3 Signed software modules
11.4 Encrypted network traffic
59
59
59
59
59
12
Availability and manageability
12.1 SAP Contact Center HAC
12.2 SAP Contact Center Alarm Server
12.3 SNMP
12.4 Miscellaneous
60
60
61
61
62
13
Deployment, software distribution and configuration
13.1 Software distribution
63
63
14
Sizing
64
15
Interoperability with other systems
65
16
Glossary
67
17
Appendix A: Sample SAP Contact Center Servers
17.1 Basic service provider setup using Windows Server 2008
17.2 Service provider setup with SAN using Windows Server 2008
76
76
77
4
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
1 Introduction to SAP Contact Center infrastructure
The SAP Contact Center (SAP CCtr, formerly SAP BCM) software provides a multi-channel, all-IP
communications platform for customer care operations. With SAP Contact Center organizations can deploy IP
telephony for everyone who needs it, including telemarketing experts, customer service agents, switchboard
operators, office workers, mobile experts, and their managers. SAP Contact Center is the telecommunication
technology of today. It is a single integrated system based on open IT standards and enables customers to





Manage phone calls, emails, short messages and web contacts in a single, software-based solution.
Utilize a full range of communication devices such as soft phones on PC desktops, IP desk phones and
mobile phones.
Connect mobile and globally scattered workforce.
Manage distributed know-how and utilize the right people with the right skills from front-office agents to
back-office specialists.
Smooth migration, security, reliability and scalability upon deployment.
SAP Contact Center infrastructure is everything that is needed to run the SAP Contact Center software, such
as servers, networks, gateways and terminals. An enterprise can set up a SAP Contact Center in-house system
or a service provider can offer SAP Contact Center functionality to end customers. In-house and service
provider setups are basically similar and the main differences are due to service providers striving towards
multitenant and/or multi-instance setups to achieve cost efficiency and simultaneously facing a variety of and
sometimes even contradictory end user requirements. While an in-house system does not logically differ from a
hosted service entity providing the same service, an in-house system may be considered more stable in terms
of various software and hardware updates. This puts harder requirements on operations and manageability for
service providers who, on top of this, have their own requirements on for example scalability, security and total
cost of ownership (TCO).
1.1 Introduction to site landscapes and connectivity
A SAP Contact Center system is comprised of Windows servers running Microsoft SQL, Microsoft Internet
Information Server (IIS) and SAP Contact Center. Clients are soft phones (PC) and IP desk phones. In addition,
there are gateways or SIP trunks carrying external calls to and from the SAP Contact Center system to the
public switched telephone network (PSTN) and IP networks interconnecting the servers, gateways and user
terminals.
PSTN/PLMN subscribers
PSTN
PLMN
PRI
GATEWAY
- Electrical and mechanical adaptation
-ISDN Q.931 to/from SIP or H.323
conversion (signalation)
- 64 kbit/s PCM to/from G.711
conversion (audio stream)
SIP
Trunk
Session Border Controller
- Protocol normalization
- Transcoding
- Security policies enforcement
100/1000Base-T Ethernet
IP v4
Client
SQL SAP CCtr & IIS
Server
Server
CDT terminals
SIP / IP desk
phone
Figure 1. A Basic SAP Contact Center in-house landscape.
Figure 1 shows a basic SAP Contact Center in-house landscape in which a voice over IP (VoIP-) gateway is
5
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
connected to the telephone network over a 2 Mbit/s PRI line. The gateway adapts the protocols and
characteristics on the PSTN side to those used on the local area network (LAN) side. The PRI line is provided
by a telco and a telephone number range is normally included with the subscription. The gateway and the LAN
is setup and maintained by the Enterprise. Nowadays SIP trunks and Session Border Controllers (SBC) are
often used instead of PRI lines and gateways. In this simplified landscape illustrating the principles, the SAP
Contact Center Server contains any required SAP Contact Center modules and integration interfaces whereas
the SQL Server contains operational and reporting databases. Real setups might contain separate SQL
Servers for operational and reporting purposes and SAP Contact Center components might be distributed over
two or more servers depending on performance, administrative, security etc. conditions.
PSTN/PLMN subscribers
PSTN
PLMN
SIP
Trunk
PRI
GATEWAY
100/1000Base-T
Ethernet IP v4
Inside Network
SBC
100/1000Base-T Ethernet
IP v4 Access Network
SAP CCtr
Server
SQL
Server (CEM, CD, HAC, AS, IA, ...)
SAP CCtr & IIS
Server
(CS, MRS,
SBR, ETC,
Integration Interfaces, ...)
Service link
WAN
Access link
SIP / IP/
phone
100/1000Base-T Ethernet
IP v4
Client
CDT terminals
Figure 2. A Basic SAP Contact Center service provider landscape.
Figure 2 shows a basic SAP Contact Center service provider landscape. The service provider could equally
well be an external commercial service provider or an internal corporate department providing the service to
other departments. It contains the same SAP Contact Center components as the in-house landscape.
6
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
Terminals and users reside in an enterprise network connected to a service provider network over a wide area
network (WAN) connection. Multitenant and/or multi-instance setups are key issues for a service provider to
achieve acceptable TCO. To be able to run several customers securely on a shared infrastructure, the service
provider network is compartmentalized into an inside network and an access network. Direct customer access
is restricted to SAP Contact Center components in the access network only on an as-needed basis and SAP
Contact Center components in the access network are granted access to resources in the inside network on an
as-needed basis. The multitenant and/or multi-instance architecture allows for several customers to share
common service provider equipment and resources, such as servers and networks, facilitating service provider
efficiency and competitiveness on the market.
Chapter 2, Site landscapes and connectivity covers this topic in more detail.
1.2 Introduction to environmental and facility recommendations
The nature of SAP Contact Center services, dealing with phone calls and other communications channels,
makes it business critical. Because the availability of SAP Contact Center services depends on the underlying
infrastructure, these aspects have to be taken into consideration in the infrastructure.
Some environmental and facility requirements are dictated by server and network equipment manufacturers
and are based on requirements from semiconductor and component manufacturers. Required operating
conditions such as temperature and humidity must be matched and power must be supplied for the services to
run. Available options are, for example, measures for power failures, alternate call routing and supplying power
for emergency calls.
Some requirements may arise from legislation, corporate security policies and risk management. These may
include administrative roles, passage control and site locations. Environmental and facility requirements should
only partly be considered technical IT issues because they are also business strategy issues and dealing with
them is company and service provider individual.
Chapter 3, Environmental and facility recommendations, covers this topic in more detail.
1.3 Introduction to server hardware, operating systems and
software
SAP Contact Center servers run the SAP Contact Center software and related Microsoft IIS and Microsoft SQL
Server on industry standard x86 or x64 based server hardware. Servers and desktops are engineered for
different usage. Servers are specifically designed to hold, manage, send and process data. The technologies
behind servers make them more reliable and scalable than desktop systems and help them process data faster
and more efficiently than desktop systems. One significant benefit of servers is that their configurations can be
customized to meet very specific needs, such as disk I/O and/or capacity, so servers can be designed to
provide maximum return for the investments.
Deciding the needed server setup requires investigation in and awareness of, for example, estimated capacity
demands in terms simultaneous phone calls, number of users and customers. Affecting factors may have very
different importance in different setups. Some factors might be relatively static for enterprises providing the
services internally and some might be even unforeseeable for service providers. Especially service providers
should consider their estimated growth speed, scaling strategy and intended service level agreements (SLA).
An in-house system might consist of a couple of entry-level servers whereas a service provider might run
clustered SQL databases, distribute SAP Contact Center components over several servers, provide failover
nodes for each and benefit from fault-tolerant LAN’s and fault-tolerant high performance storage area networks
(SAN).
Supported and recommended hardware, operating systems and software can be found in the infrastructure
compatibility list (ICL) in the support portal. Appendix A presents some Sample SAP Contact Center server
configurations.
Chapter 4, Server hardware, operating systems and software covers this topic in more detail.
7
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
1.4 Introduction to gateways and SIP trunks
PSTN networks are connected to IP networks through VoIP-gateways. Gateways provide electrical and
mechanical adaptation between the two networks and perform protocol and voice stream translation as figure 3
shows.
10/100 Base-T Ethernet
to IP network
DHCP, TFTP
TELNET
HTTP
SIP, H.323
G.711, G.729
........
VoIP GATEWAY
E1, T1 or J1 line
to PSTN
Q.931
Q.921
64 kbit/s PCM
56 kbit/s PCM
Figure 3. Gateways provide electrical and mechanical adaptation between PSTN and IP/Ethernet networks and
perform protocol and voice stream translation.
SAP Contact Center supported gateways are available with support for E1, T1 and J1 PRI lines to the PSTN.
E1 lines are used in Europe, T1 in America and J1 in Japan.
One E1 line may be channelized into 32 DS0 channels, one of which is used for synchronization, one as the Dchannel (signaling channel) and 30 as bearer channels for voice streams (phone calls). One T1 or J1 line may
be channelized into 24 DS0 channels, one of which is used as the D-channel.
Gateways are connected to IP networks with 10/100/1000 Base-T Ethernet links. Gateways are controlled by
SAP Contact Center using the protocols SIP or H.323. Gateways typically support at least dynamic host
configuration protocol DHCP for IP address provisioning, trivial file transfer protocol (TFTP) for configuration
provisioning and Telnet for configuration. Most gateways also provide a web interface for administration and
configuration.
Gateways may be distributed geographically, for example, over different telco areas or to different satellite sites
of a service provider or customer. This allows local calls to satellite sites and enables cost optimization by
routing calls over IP to the most profitable gateway. Distribution of gateways may thus influence telephony
costs and may also have positive impact on failure resistance and data line bandwidth demands. Gateways
may also be connected to private branch exchanges (PBX) over PRI enabling calls between legacy telephony
systems and VoIP systems. In fact, interconnecting the two systems is a commonly used method allowing for
flexible migration phases.
SIP trunks have become a popular alternative to PRI lines, especially in new setups. A SIP trunk setup reminds
topologically of a PRI setup but the PRI is replaced with an IP connection and, in most cases, the gateway is
replaced with a SBC. Some SIP trunks are supported even without a SBC in between.
Chapter 5, Gateways, covers gateways in more detail.
Chapter 9, Telephony and data connections, covers PSTN lines in more detail.
1.5 Introduction to data center LAN
Data center LAN refers to the LAN, where the SAP Contact Center Servers reside and where the SAP Contact
Center services are produced. Although emphasis here is on service provider data center LANs, this
information might give enterprises ideas when designing their in-house landscapes.
High service availability and manageability are crucial for a service provider. Among many other things, service
supply and underlying infrastructure have to be carefully designed to meet market demands. Growth strategies
8
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
have to be prepared and risk mapping must be done. Various problem scenarios are covered by building fault
tolerance and automatic or manual failover mechanisms. Nevertheless, a service provider providing numerous
customers’ with business critical communications services is encouraged to prepare for the unexpected and
narrow down the impacts of service supply failures. This can be done for example by segmenting the
production environment into more or less self-sufficient production units constricting the impacts of a failure of
one production unit from other production units. To be self-sufficient, a unit would include all layers from the
bottom of the infrastructure all the way to the service interface towards the customer. It is an ongoing task of
growth, risk and business management to decide how many production units to run, how to design them and
when to start new ones. Figure 4 shows one approach of segmenting the data center LAN.
Customer A
Customer B
Customer C
Customer D
Customer E
Customer E
Service
realization
Customer A
Service
realization
SAP CCtr IIS
SAP CCtr IIS
MGMT
SERVER
SAP CCtr IIS
SAP CCtr
SERVER(S)
SAP CCtr IIS
AD
SERVER(S)
SQL
CLUSTER
SAP CCtr
SERVER(S)
SAP CCtr IIS
SAP CCtr IIS
SAP CCtr IIS
Medium Network
SAP CCtr IIS
Access
Network
Core Network
Figure 4. A sample segmentation model of data center LAN. The middlemost area constitutes a fault-tolerant
core network all services depend on. The next orbit is a medium network for purposes of separating the core
network from the outermost access network, where the services are made available for the customers. The
green and red areas, service realizations, describe the required portion to produce a service for a customer.
The landscape conforms to the basic service provider landscape shown in figure 1, except for the missing CMC
option.
Chapter 6, Data center LAN, covers this topic in more detail.
9
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
1.6 Introduction to customer LAN
The customer LAN refers to the LAN where the SAP Contact Center service is consumed. In an in-house
installation, SAP Contact Center services are also produced locally in the customer LAN. If SAP Contact Center
services are provided by a service provider, the customer LAN is connected to the SAP Contact Center service
with an access link and optional back-up links. Multi-office customers have the options to access SAP Contact
Center services via access links to each office or via WAN/MAN links interconnecting the offices to a common
access link or via any combination of these.
Figure 5 shows a single site customer LAN connected to a
SAP Contact Center service provider. All services are
provided from the data center LAN and accessed over a
WAN connection by users in the customer LAN.
PSTN
PRI or SIP trunks
GW or SBC
Data center
SAP CCtr & IIS LAN
SQL
Service link
WAN
Access link
Customer
LAN
Client
External telephony is routed over one or more PRI
(E1/T1/J1) connections or SIP trunks to/from the PSTN.
The subscriber of the PRI connection / SIP trunk is typically
the customer but it may also be the service provider and the
same applies to the access link, which may be any link
capable of providing sufficient bandwidth and performance,
such as a point-to-point or a multi protocol label switching
(MPLS) link.
The service provider is responsible for keeping the services
up and running by performing various daily maintenance
tasks and production environment reassessment as service
demands increase and thus maintaining acceptable and
agreed service levels.
The telcos and/or ISPs are responsible for the operability
and service levels of data and telephony links. The
subscriber of the links is responsible for the suitability and
sufficiency of the subscribed links.
The most demanding requirement regarding the data link
and the LANs, besides the overall operability, is the ability
to carry real-time streams without introducing unacceptable
delays or delay variations (jitter). The customer is
responsible for maintaining the customer LAN´s capability
of carrying voice traffic with acceptable quality.
As a rule of thumb, well performing switched 100 Base-T
and 1000 Base-T networks are well fitted for IP telephony.
Figure 5. A single site customer LAN
connected to a SAP Contact Center
service provider.
10
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
Service link
Service link
WAN
WAN
Access links
Site 1
LAN
Site 1
LAN
Site 2
LAN
Client
Client
Site 2
LAN
Client
Client
Site 3
LAN
Site 3
LAN
Client
Client
Enterprise
Network
Enterprise
Network
Figure 6. A multi-site customer LAN with one
access link per site.
Figure 7. A multi-site customer LAN with one
common access link.
Figure 6 shows a landscape of a customer with three sites, each connected directly to the SAP Contact Center
service provider. External telephony is routed over the access links. Internal telephony may be routed over the
access links or links interconnecting the sites. Back-up connectivity may be provided over the links
interconnecting the sites.
Figure 7 shows a landscape of a customer with three sites sharing a common access link to the SAP Contact
Center service provider. Links interconnecting the sites must be dimensioned for carrying the telephony traffic
and back-up routes and/or access links should be considered.
Sorting out the most suitable approach for each case involves investigating the current enterprise network
topology and its fault tolerance, finding out user concentrations and estimating the bandwidth demand on
different parts of the network. Also, existing traffic profiles and regular and casual peak loads should be
considered especially on interconnecting links, which often are slower than the site LANs. Quality of service
(QoS) controls may be applied to the interconnecting links and sometimes to the site LANs as well.
In general, there are three factors deteriorating voice quality in a network point of view. They are too long oneway delay, packet loss and jitter. One way delay problems suggest network design problems and that
fundamental incompatibility exist between the current network implementation and the demand of carrying
quality voice over it. For example, it could be a too slow link over a too long distance without even theoretical
ability to achieve demanded performance.
Packet loss or extensive number of retransmissions and cyclic redundancy check (CRC) errors implies
hardware or configuration problems, such as speed or duplex mismatches, poor connectors, damaged or poorly
mounted cabling or exceeded environmental conditions. These two problem types, too long one-way delay and
packet loss, including retransmissions and CRC errors, are remedied by one time actions. Once the root cause
is identified, the problem is solvable permanently. Drops can be monitored in many ways, for example routers
and switches usually have drop counters. Too long one-way delay is immediately recognized by overlapping
speakers. Delays can be estimated from the round trip shown by ping.
Jitter is variation of one-way delay and is compensated to a limited extent by jitter buffers on gateways and
terminals. A constant stream of digitized voice data must be supplied to an AD converter in order to get
constant analog sound. If the digitized voice stream is interrupted or delayed, there will be an outage on the
analog sound deteriorating the voice quality. Jitter problems can be remedied by applying QoS controls and
revising network topologies to minimize congestions.
Chapter 7, Customer LAN, covers this topic in more detail.
11
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
1.7 Introduction to storage systems
Storage systems refer here to hard disk storage used by SAP Contact Center and underlying infrastructure for
saving operating systems, applications and data. Storage is necessary for each server, but storage capacity,
performance requirements and availability requirements may vary depending on server roles and utilization.
Storage design may also impact how servers are managed and maintained.
SAP Contact Center allows for setups with redundant servers. This means that there are preconfigured up-todate failover servers available in case of server crashes. These, kind of disposable, servers should not contain
any user data, such as recorded files, voicemails or attachments. Neither should they contain any usage data
that is not affordable to be lost in case of a server crash.
All failover events are not invisible to users and securing server storage improves reliability and eases system
maintenance. This can be done using fault-tolerant disk configurations such as
-
RAID-1
-
RAID-5
-
RAID-10
Some data must be made available for all servers sharing a common role, such as SQL servers and file
servers. For example, if a SQL Server cluster node fails, a back-up node must be able to mount the storage
and access the database. Clustered server packages with integrated disk arrays constitute one possibility to
fulfill this requirement. Another possibility is to use Storage Area Networks (SANs).
SANs provide centralized storage capacity to distributed servers in such a way that the storage seems to be
locally attached in the operating systems point of view. Servers can be booted from SANs so SANs makes it
possible to use diskless servers, in the sense that no disks are installed physically in the server.
This approach allows servers to be easily replaceable “dummy” electronics boards that are ever less
individualized or designated for any specific task, potentially giving more flexibility in production operations,
upgrades and scaling tasks. SANs provide high performance disk I/O. Servers are connected to the SANs with
Fibre Channel links or Ethernet links. In the former case the server requires a host bus adaptor (HBA).
SANs introduce a potential for regarding different life spans for servers and storage. Although a SAN system is
scalable itself and there are different classes of SANs, a SAN system is one of the biggest single investments in
a SAN-based SAP Contact Center infrastructure. Whilst being that, a longer life span should be considered for
a SAN than for a server as perfectly intact servers grow old as operating systems and applications evolve.
Chapter 8, Storage systems, covers this topic in more detail.
1.8 Introduction to telephony and data connections
Data links refer to access and service links connecting the customer LAN to the data center LAN and carrying
voice streams, signaling information and UI data to/from SAP Contact Center servers, gateways and SBCs
from/to SAP Contact Center user terminals, such as soft phones and IP desk phones.
Telephony links refer to E1/T1/J1 PRI links and SIP trunks carrying phone calls between gateways/SBCs and
the PSTN. SAP Contact Center does not directly require any special technology for data links as long as
sufficient IP performance is provided and the same applies to the PRI links as long as the gateways they are
connected to provide SIP or H.323 over IP on the network side.
SAP Contact Center supported gateways support ISDN PRI E1/T1/J1 telephony links. Telephony links are
provided by a telco/ISP and telephone number ranges are allocated to each link or group of links. Telephony
12
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
links, may be concentrated in a data center or distributed to customer premises, branch offices or other points
of presence. For availability purposes, telephony links may also be distributed over two or more telephone
exchanges or sometimes even over two or more telcos.
Access and service links are required in service provider cases only. For a service provider, it is often
reasonable to build a high-density service link to one or more ISPs and have them provide the access links to
the customers. If telephony links are centralized in the data center, all SAP Contact Center related traffic will
pass over the service and access links. If telephony links are distributed to customer locations, a relevant part
of the voice streams may exist only inside the customer LAN and thus access link bandwidth demand may
decrease.
Deciding the capacity and the customer side endpoint of the access link involves estimation of the maximum
number of simultaneous calls and call density estimations per locations in order to find the most suitable
endpoint location. Minimizing the network distance between the endpoint and the call density center allows for
maximum average call quality expectations.
Chapter 9, Telephony and data connections, covers this topic in more detail.
1.9 Introduction to user terminals
There are two types of user terminals, soft phones and IP desk phones.
Communication Desktop (CDT) is the SAP Contact Center Microsoft IE browser based soft phone including
numerous features such as directories and PRS (presence) profile management. A handset or headset is used
with CDT. The handset/headset connects to a USB port of a PC either directly or via an adaptor performing the
analog-to-digital (A/D) transformation.
Supported IP desk phones are SIP phones. IP desk phones are voice stream and signaling information
endpoints and they are quite independent units resembling legacy telephone terminals. They do not provide the
advanced features of CDT.
Chapter 10, User terminals, covers this topic in more detail.
1.10 Introduction to security
SAP Contact Center provides telephony over IP and is normally used in private networks but not in public
networks such as the Internet. SAP Contact Center includes security instruments itself, such as identification,
authentication and encryption, but it relies also on security mechanisms in the underlying infrastructure.
In general, security aspects are present in several different levels and viewpoints. The primary concern of a
service provider might be to ensure the availability and integrity of the data center, that is, their business and
the services provided to customers, whereas the concerns of the customer might be availability and
confidentiality. Although the slightly different security viewpoints affect the security issue, overall security must
be considered and both service provider and customer demands must be met.
When the service is provided by a service provider and utilized by an end user, it is obvious that security roles
and responsibilities are divided to both parts. From the network landscape it can be observed that the data
connection between the data center and the service provider poses a potential threat from the service provider
to the customer and vice versa.
Important security mechanisms are access lists, traffic filtering and virtual LAN (VLAN) segmentation. Figure 8
gives an overview of protocols used by SAP Contact Center. Signed soft phone and mobile terminal
components assure the integrity and the manufacturer of the components. Server side authentication is
achieved by certificates from trusted certificate authorities.
13
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
SIP
SIP
Data Center LAN
RTP
RTP
RTP
SIP Bridge
CDT
http(s)
Customer LAN
CDT
ODBC
WACP WEB
ODBC
WACP
SQL
RTP
WACP
CEM&CD
RTP
CDT
H.323
H.323 Bridge
SIP
H.323 Gateway
RTP
PRI
PSTN
Figure 8. An overview of protocols used by SAP Contact Center.
Chapter 11, Security, covers this topic in more detail.
1.11 Introduction to availability and manageability
High availability in this context refers to high availability of service achieved by introducing fault tolerance and
disaster recovery. The fault tolerance architecture attempts also to provide good manageability. The idea is to
have a fault tolerant architecture performing manual and/or automatic failovers but unlike probably most cases,
not to do fallbacks. Failover may occur due to failures or avoidance of down-times during maintenance tasks
and therefore a more appropriate term than failover is switchover.
Interactions and attitudes of individuals can devastate even the best systems or make the worst possible
systems appear excellent. Therefore, it is important to understand existing fault tolerance and its entities,
mutual impacts between systems and/or their components and to undertake working methods to support
aspired service levels. High availability is not reachable with technical measures alone.
Enabling switchover operations due to maintenance task and/or failures requires that the ability to produce a
service exists in two or more places. The ability to produce a service includes CPU power, storage,
configuration data and network connectivity and so on. Making this ability generally available for all services
requires good management of SAP Contact Center infrastructure, awareness of available resources,
awareness of the committed service levels, proactive approaches in developing the infrastructure, engagement
14
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
in undistorted working methods and continuous testing. The idea of using only switchovers and not fallbacks is
an important part of testing. Switchover moves the source of the service in question from one entity to another
and thus tests the entities.
Adapting the switchover mechanism to version updates can result in that live production entities are never
updated. Arranging for a group of at least three similar service entities, one being active and two being standby,
enables to apply an update and to test it with minimal downtime. The update is applied to one of the standby
entities to which cannot be switched over to during the update. The other standby entity is there in case of a
failure of the active entity during the update.
Once the update is applied, the entity can be tested, even by the customer, and when it is approved, a
switchover is performed to the updated entity. One of the remaining entities needs to be updated as well to
provide an equal version switchover entity. Eventually, the old entities and related resources are freed and
available for other updates.
The described updating and maintenance practice allows for the actual updates and maintenance tasks being
performed during normal office hours without having to adapt to maintenance windows and strict time frames.
The update experienced by the user is only a rapid switchover.
SAP Contact Center provides management tools only for the application, such as:
-
High Availability Controller (HAC)
-
Infrastructure Administrator (IA)
-
System Configurator (SC)
Management tools for the infrastructure are provided by each device manufacturer or some third party provider.
These tools include Telnet and/or browser-based device configuration and server management tools, such as
HP server management tools, simple network management protocol (SNMP) agents by hardware
manufacturers and SNMP management software.
High availability includes also ensuring quality voice in the customer LAN by implementing QoS. This protects
against voice quality impairments due to heavy network bandwidth consumption which may be caused by new
or improperly configured software or increased usage of existing software.
Chapter 12, Availability and manageability, covers this topic in more detail.
1.12 Introduction to deployment, software distribution and
configuration
SAP Contact Center deployment is a manifold task. It starts by finding out and defining the particular service to
be provided and its various parameters, such as:
-
Schedules
-
Queues
-
Prompts
-
Telephone number ranges and call volumes
When call volumes and server and agent locations are recognized, the network topology is decided. This
includes deciding the number of telephony links and their locations and when this is done, the number of
required access links and their capacities can be decided. Also high availability requirements affect the
15
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
designing phase in terms of volume, number of access and telephony lines and number of servers used. One
important decision is whether to provide full or partial capacity in a failure situation. Full capacity means that for
at least most resources, double capacity is at hand when operating normally. These are crucial steps that might
have undesired impact if they are poorly designed and/or implemented.
Deployment also includes decisions on what terminals and accessories to use, such as the type of handsets
and/or headsets to be used with CDT and deciding the type of IP desk phones and to purchase these.
Once the above steps are completed, access lists can be designed. Typically, there is a firewall, router or layer
3 switch providing access control between the users and the servers. The particular access control
configuration depends on the used IP address ranges, the terminal and gateway or SBC models and their
configurations and the used protocols.
The SAP Contact Center related client software is needed mainly by CDT. These are ActiveX components
available as msi files. The SAP Contact Center ActiveX components are signed by SAP Labs Finland to
convince the user of their trustworthiness. These components can be distributed in any way suitable, e.g. using
Microsoft systems management server (SMS) or by installing copying them manually to each workstation. All
CDT configurations are done within CDT or via SAP Contact Center Management utilities by an administrator.
IE, local firewall and so on configurations are done with the respective software.
IP desk phone configurations are done manually using the keypad or (semi)automatically using DHCP, TFTP,
Telnet and/or browser-based administration tools. The facilities vary slightly between different manufacturers.
So far the soft phone is clearly the dominating terminal and IP desk phone configurations have mostly been
made manually using the keyboard of the phone and/or using a browser.
Chapter 13, Deployment, software distribution and configuration, covers this topic in more detail.
1.13 Introduction to sizing
Sizing involves various capacity requirements of components and devices constituting an operational SAP
Contact Center system, such as telephone links, access links, customer and data center LANs, gateways and
servers.
The resource requirements of different SAP Contact Center components and the capacity they provide are
discussed here, for example a SIP bridge (SBR) can handle a maximum of 700 simultaneous SIP calls. Sizing
does not take count in capacity requirements for high availability solutions, it tells only what is required and
achieved by a single component or device. Spare and failover capacity has to be considered separately.
Scaling goes closely along with sizing and is covered as well. Especially for a service provider it is crucial to
consider scaling from the very beginning and to design the system accordingly in order to maximize cost
efficiency and prepare for future increases.
Since the current hardware development is rapid it would be easy to believe that hardware investments made in
advance are not profitable. However, over time hardware does not constitute the most expensive portion of the
business and standardizing might increase working efficiency and thus give savings in labor costs.
Designing a SAP Contact Center infrastructure that has high availability and is scalable should start with
recognizing some goals and margins, such as estimated total volumes in terms of:
-
Customers
-
End users
-
Data lines
-
Telephony lines
16
INTRODUCTION TO SAP CONTACT CENTER INFRASTRUCTURE
Particularly important is also to estimate the life cycle of the SAP Contact Center technical infrastructure, for
example a storage system may serve significantly longer than a server that might become outdated in three
years.
Sizing rules are not always so simple and unambiguous because the usage pattern may vary a lot from case to
case depending on for example the implemented integrations channels. Especially e-mail channels and
channels that are converted into e-mail channels, such as web channels, may deal with numerous attachments
of various sizes that consume storage and network capacity.
To throw some light on sizing as number of servers, there are implemented systems with one Microsoft SQL
Server (cluster) and two SAP Contact Center servers perfectly dealing with up to 660 simultaneous calls and
there are systems where additional three servers have been installed as SIP and/or H.323 bridges dealing with
2000 simultaneous calls. Factors such as higher redundancy demands and backup sites may require additional
servers to be installed.
Usually the most expensive servers are high end, SAN attached and clustered Microsoft SQL servers and SAP
Contact Center application servers are more affordable.
Chapter 13, Sizing, covers this topic in more detail.
17
SITE LANDSCAPES AND CONNECTIVITY
2 Site landscapes and connectivity.
Basic in-house and service provider landscapes are shown in section 1.1, Introduction to site landscapes
and connectivity. This chapter explains what modules are used and for what purposes, how different channels
are implemented and how virtual units (VU) are used.
The specific behavior and functionality of any SAP Contact Center system is determined by the set of modules
used and their configurations. Any specific module is responsible for a logical set of functionality, for example, if
there is a demand for sending SMS messages, the SMSServer module is needed.
Channels refer to communications channels used to communicate externally and/or internally such as
telephony, fax and email.
Virtual units are used for administrative grouping of services. In a multitenant environment, where several
customers are served by the same hardware, virtual units are assigned customer specific resources such as IPaddresses, directories and other settings.
2.1 Modules
A SAP Contact Center module is discrete product module run as a process. Modules are run in some virtual
unit’s context, which typically contains its own resources such as IP-addresses, log file directories and
configuration data.
2.1.1 Human interface modules
Human interface modules are a set of mostly web browser-based user interfaces that provide the end users to
access phone, directory and call history functionality and administrators to access administrative functions.
These modules are:

CDT (Communications desktop) is the SAP Contact Center soft phone and the primary graphical user
interface.

Convergence is an alternative soft phone suitable for the basic telephony users.

Monitoring allow contact center supervisors to monitor service metrics.

Infrastructure Administrator (IA) is for controlling and monitoring SAP Contact Center software, for
example managing services, platforms, virtual units, web sites and viewing technical logs.

System Configurator GUI is for managing call switching and stream protocols, Queues, Services and
SAP Contact Center Administrator accounts.
2.1.2 Service modules
Service modules are modules providing some specific functionality used directly by the user or indirectly by
some other module. These modules are: (see also SAP Contact Center Master Guide)

Agent Server, provides services to agents via the Connection Server.

Alarm Server (AS), receives XML and/or HTTP alarms from any applications and filters and converts
them to SMS, email and/or SNMP alarms/messages and forwards them to desired targets.

Batch Job Server

Call Dispatcher is for call routing, switching and control.

Chat Portal Server provides a Chat Portal Interface for integrating third party chat servers.

Chat Server manages chat discussions between participants.
18
SITE LANDSCAPES AND CONNECTIVITY

Configuration Database

Connection Server (CS) provides a secure TCP tunnel between clients and servers.

Contact Event Manager (CEM) is the core module of SAP Contact Center managing for example
contact requests, queues and contacts event auditing.

Data Collector collects event data from various sources and stores them along with some precalculated aggregates into various databases.

Directory Database

Directory Server

E-mail Sender

External Terminal Controller (ETC) poses IP desk phones as CDT phones towards CEM.

File Replication Service (FRS) performs file replication between local/remote directories.

H.323 Bridge, (HBR) handles initiating, receiving, and controlling calls to/from H.323 gateways. It also
contains an H.323 registrar. It performs protocol translation from H.323 to SAP Contact Center
protocols and vice versa.

High Availability Controller (HAC) is for monitoring and controlling software processes and
performing failover operations.

Integration Interfaces, (ACI, DAI, PSI, RDI, TMI)

Media Routing Server (MRS) is for handling audio and video streams to and from other modules or
components.

Message to Mail (MsgToMail) sends e-mail messages from SAP Contact Center using SMTP (simple
mail transfer protocol).

Monitoring Database stores and provides current statistics information.

Operative Database

Outbound Database, for outbound campaigns

Reporting Database stores and provides reporting information.

SAP CIC Adapter enables usage of SAP Contact Center contact center solutions as an integrated part
of the SAP myCRM solution.

SIP Bridge, (SBR) handles initiating, receiving, and controlling calls to/from SIP gateways and IP desk
phones. It also contains a SIP registrar and performs protocol translation from SIP to SAP Contact
Center protocols and vice versa.

SMS Server sends SMS messages

Standard Reports

WebClient is an IIS extension module providing a scripting language for generating HTML and XML
documents from data in databases and various HTML or XML templates.

Web Server
2.1.3 Integration interface modules

Online Interaction Interface Server provides Online Interaction Interface (OII) and Online
Monitoring Interface (OMI).

SAP phone BCM provides the interface SAP phone statistics.

WS2 server provides Administration and Configuration Interface (ACI), Directory and Availability
Interface (DAI), Presence Synchronization Interface (PSI), Reporting Data Interface (RDI) and Task
Management Interface (TMI).
19
SITE LANDSCAPES AND CONNECTIVITY
2.2 Communication Channels
The communication channels supported by SAP Contact Center are:
-
Voice (telephony)
-
E-mail
-
Chat
-
Web
-
SMS (converted to and received as e-mail by SAP Contact Center))
-
Fax (converted to and received as e-mail by SAP Contact Center)
Communications events from each channel are received and routed by SAP Contact Center according to
predefined rules, such as timetables, queues and skills.
2.3 Virtual units
Virtual units are administrative groupings of services. A virtual unit is assigned an IP-address and it produces
one or more one SAP Contact Center services (by installed software modules). A virtual unit is also a failover
domain with one active instance and one or more failover instances. If any service or part of a virtual unit fails,
the whole virtual unit fails and its services are activated in a failover instance. Failover proceedings may be
automatically triggered by a monitoring event or they may be manual based on fault detection or maintenance
requirements.
The naming convention of virtual units is free, but specially in service provider setups it is worth creating a
naming convention suitable for supporting daily operations and maintenance. Logical and consistent naming
convention eases recognition and thus decreases the risk of human errors.
A grouping of services and processes to virtual units based on their functionality and access requirements is
recommended.
Grouping based on functionality can be as follows:
-
VU_CORE for core components, such as CEM, CD and Data Collector
-
VU_CONN for connectivity components, such as CS, ETC, SIP (for ETC) and Chat Server
-
VU_BRIDGE for HBR, SBR and MRS
-
VU_COM for communications components, such as SMS Engine
-
VU_CEM_DB and VU_DPM_DB for databases.
Grouping based on access requirements can be as follows:
-
VU_IWR for internal web services accessed by the system itself
-
VU_WEB_ADMIN for administrative purposes and accessible only from the inside network
-
VU_WEB_USER_CUSTOMER1 for end-user service access from customer1’s network
-
VU_WEB_USER_CUSTOMER2 for end-user service access from customer2’s network
-
VU_INT for integration services and interfaces accessible from the outside network, possibly one-to-one
access.
20
SITE LANDSCAPES AND CONNECTIVITY
CUSTOMER NETWORK
DMZ
- VU_DMZ
Internet Chat Client
MGMT NETWORK
ACCESS NETWORK
- VU_HAC
HAC
AS
- VU_HAC
- VU_FRS_n
- VU_WEB_USER
Web Server
Web Clients
Repoting Web Clients
- VU_PSTN_n
SBR
HBR
MRS
Prompts
* or if with AS failover *
- VU_HAC
HAC
- VU_AS
AS
- VUA
- VU_WEB_ADMIN
IA
Web Server
Web Admin Tools
- VU_CONN
- SNMP
- Network Admin Tools
- VoiceEdit
UIs
- CDT
- Convergence
- Monitoring
- IP Desk Phones
VUs
MRS
SBR
- VUA
- VU_INT
Web Server
Integration Interfaces
Chat Portal Server
- VU_TERMINAL_n
CS
SBR (for ETC)
- VU_WEB_REPORTING
Web Server
Standard Reports
CORE NETWORK
- VU_HAC
- VU_CORE
CEM Server
Chat Server
ETC
- VU_INTERNAL_n
Web Server
Internal Web Services
Data_Collector
- VU_CPM_DB
CPM Database
- VU_Report_DB
Reporting Database
WWU_DB
DSAREA_DB
APO_DB
- VU_FRS_n
- PDC Server
- VU_COM
SMS Server
- VU_Prompts
Prompts
- VU_CEM_DB
CEM Database
CEM_History_DB
CEM_Reporting_DB
Figure 9. A SAP Contact Center virtual unit configuration sample.
Figure 9 shows a sample VU configuration. Capacity can be increased by configuring several VU’s for a
particular task. Such VU’s can be named ending with an increasing number “_n”, for example, PSTN_1,
PSTN_2, etc. It is recommendable to name the first virtual unit of a type as VU_1 although future virtual units
would seem unlikely, because it makes it simpler to keep the naming convention later, if more virtual units are
added after all.
The VUs in picture 9 can be further split into smaller VUs, for example, as follows:
-
VU_WEB_USER can be split into 2 VUs each containing Web Server and one of the other modules.
-
VU_PSTN can be split into 3 VUs, one for each module.
-
VU_INT can be split into 2 VUs each containing Web Server and one of the other modules.
-
VU_TERMINAL_n can be split into 2 VUs, one for each module.
21
SITE LANDSCAPES AND CONNECTIVITY
-
VU_CORE can be split into 3 VUs, one for each module.
-
VU_INTERNAL_n can be split into 2 VUs each containing Web Server and one of the other modules.
A VU in the customer network is recommended if:
-
Local (in the customer network) gateways retrieve prompts from local servers (MRS).
-
Recordings, for example voice mail messages are saved locally.
For the above setup the recommended minimum number of servers is five. Failover servers must be added to
this number. Failover servers do not have to be dedicated for a particular system, for example a pool of
production servers can target a single failover server. How many production servers a failover server serves is
based on risk analysis and is a business decision. The recommended five servers are:
-
Management server in the management network.
-
SAP Contact Center Core Server in the core network.
-
SAP Contact Center Database server in the core network.
-
SAP Contact Center Access Server in the access network
-
SAP Contact Center DMZ Server in the DMZ network.
In an in-house setup, the network structure may be reduced as much as to one network containing all VUs or to
two networks if Internet Chat Client are used. In the latter case, it is strongly advised that VU_DMZ reside in a
DMZ network.
2.4 Interconnecting SAP Contact Center systems
SAP Contact Center systems can be interconnected using SIP trunks, that is, by configuring a counterpart SIP
Bridge as a local SIP gateway in each of the systems. In versions before SAP Contact Center 7 this was done
using the Federation Bridge (FBR).
SAP Contact
Center 1
Intermediate
network
SAP Contact
Center 2
Voice
CDT
Voice
MRS
Voice /RTP
MRS
CDT
Control
Control
CEM/CD
CEM/CD
Control
Control
Control
SBR
SBR
Figure 10. Connecting together two SAP Contact Center systems.
22
ENVIRONMANTAL AND FACILITY RECOMMENDATIONS
3 Environmental and facility recommendations
Suitable facilities assist in successful service management and operation and provide means for successful
business. Facility recommendations aim to improve physical security and high availability. Facilities may be:
-
run and owned by an enterprise or a service provider
-
rented
-
outsourced
To outsource the hosting of networks and servers not only saves one from the maintenance burden but may
also significantly increase available expertise regarding the outsourced parts and enables the outsourcer to
concentrate the efforts on SAP Contact Center operations.
3.1 Physical security
The purpose of security is to protect the personnel and assets and keep the business running smoothly.
Physical security risk analysis and business impact assessment taking all possible physical threats into
count is needed to implement security efficiently. All threats should be covered but the security measures
should not be exaggerated. Below are examples of some physical security threats:
-
Emergencies
- Fire and smoke contaminants
- Building collapse or explosion
- Utility loss (electrical power, air conditioning, heating, cooling)
- Water damage (pipe breakage)
- Release of toxic material
-
Natural disasters
- Earth movement (such as earthquakes and mudslides)
- Storm damage (such as snow, ice and floods)
-
Human intervention
- Sabotage
- Vandalism
- War
- Strikes
In general the following should be implemented:
-
Walls (from the floor to the ceiling), floors, ceilings and doors have acceptable fire and strength
ratings. Windows are normally not acceptable. Doors must resist forcible entry.
-
no nearby water pipes and shutoff valve locations are known and accessible
-
passage control with audit trails
-
intrusion detection and alarm
-
fire detection, fire alarm and fire extinguishing
Emergency procedures should be implemented and practiced, such as:
23
ENVIRONMANTAL AND FACILITY RECOMMENDATIONS
-
Emergency system shut down
-
Evacuation
-
Periodic equipment and system tests
3.2 High availability
In order to offer high availability services, proper facilities providing the demanded supply and connectivity,
protection against incidents and meaningful maintenance are needed.
3.2.1 Power supply
Power supply should always pass through UPS devices. In an online UPS the primary power source is a
UPS battery. Online UPS devices provide galvanic isolation from the supplying electricity network and
prevent undesirable current loops between devices connected to different switchgears.
An online UPS is very similar to the least expensive standby UPS in that it has the same two power sources
and a transfer switch that selects between them. It is the exact opposite from the standby UPS in that there
is no transfer time in the event of a power failure and it efficiently filters off peaks and noise coming from the
wall because those affect only the battery charger and not the inverter supplying the output power.
Power failures in the power distribution network are instantly covered by UPS devices. In a power failure
situation UPS devices are able to supply power for short times only, for a couple of hours, depending on the
UPS capacity and the power consumption. Generators are needed to protect against power failures that last
longer than the UPS is able to supply power. UPS devices cover easily the time it takes for generators to
start.
3.2.2 HVAC
HVAC stands for heating, ventilation and air conditioning. HAVC is needed to keep humidity and
temperature at acceptable levels, which are important parameters for electronic equipment.
Electronic components are designed to operate at some specified temperatures at which specified
tolerances are valid. Increasing temperature usually decreases electrical resistances and specified
tolerances ceases to apply and eventually the functionality becomes undefined.
Anti-static flooring is used to prevent static electricity and high voltage static electricity shocks from breaking
electrical circuits. Increased humidity leads to increased electrical conductivity in the air and prevents static
electricity but too high humidity leads to corrosion of leads of electrical components.
HVAC should be arranged so that it is tolerant to failure of one single HVAC system.
3.2.3 Utilities
Utilities that ease management and maintenance are appropriate equipment shelves and cable routes.
Rack cabinets are excellent for installation of rack servers and network devices. Devices should be easy to
install, recognize and remove. Well-defined cable routes allow for easily adding required cabling and for
removing unnecessary cabling.
3.2.4 Connectivity
Cable routes to the data center premises should be investigated. There should be at least two totally
separate routes entering the building on different walls. The separation of routes should remain inside the
building as close to the data center as possible. Alternate routes protect against failures on one of the
routes. Such failures could be caused for example by fire or by a digger breaking the cable miles away.
24
ENVIRONMANTAL AND FACILITY RECOMMENDATIONS
3.2.5 Sites
Multiple sites provide continuity guaranties in case of major incidents such as fires and total loss of
connectivity despite of alternate routes. In some cases alternate sites are required by law.
The same recommendations are valid for each site. Distances between sites should guarantee adequate
separation and independency of common data and power supply network nodes. This should be verified
with the local power supply operator and telco. In general, the distance should be at least 15 km.
Sites should be connected to each other with dual links backing up each other. These links and cable routes
should be all the way separate from each other. Typically IP and FC (Fibre Channel) connectivity is required
between sites, FC for connecting storage systems and IP for all the remaining traffic.
IP and FC connections can be carried over a single mode fiber pair by multiplexing different wavelengths or
colors to the same fiber pair. A third inter-site connection based on different technology such as SDH
(synchronous digital hierarchy) is recommendable for cluster heartbeat control traffic. Inter-site fiber
connections are typically 1 Gbit/s and for a third heartbeat connection 2 Mbit/s should be sufficient.
Multi-site landscape enables also partial service distribution. For example a customer setup can have PSTN
gateways in more than one site which can provide PSTN connectivity to more than one telephone
exchange.
25
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
4 Server hardware, operating systems and software
SAP Contact Center servers refer to the server hardware running the SAP Contact Center components.
Basically any industry standard x86 and x64 servers are capable of running a SAP Contact Center system.
Selecting specific hardware is a result of several aspects and is decided case-by-case. This chapter aims to
give some guidelines for deciding on the appropriate hardware.
4.1 Servers
Prerequisites for the server configuration are:
-
Site and network topology
-
Capacity demands in terms of virtual units and/or modules
-
Availability demands
-
Facility demands
Site and network topology together with capacity demands prescribes the number of servers in the basic set
and their specifications. Capacity refers to the number of virtual units and/or modules required.
Availability demands add failover servers to the number of servers in the basic setup.
Facility demands states the physical shape of the servers, such as tower, rack mounted or blade servers.
4.1.1 Number of servers
The number of servers depends, in most cases on network topology, availability demands and security issues
but as the setups get bigger, also on performance issues. The SAP Contact Center system is modular and easy
to scale up with increasing load. If performance at some point of time threatens to be a problem, it can be
circumvented by adding respective virtual units on existing servers or on new servers.
It is a good idea to start designing the network layout properly and recognizing the network location of involved
SAP Contact Center components. For example, in an in-house setup or demonstration system, there might be
only one core network, the enterprise LAN, and thus all components would reside there. In such a case, the
minimum number of servers is two, one running the databases and one running the other components. This
setup is suitable only for systems with light load and low availability requirements.
Site and network topology affects the number of servers required. Different network zones, such as DMZ and/or
management network, require separate servers. Site and network topology might also place requirements for
additional network interfaces on multi homed servers.
Capacity demands affect the number of virtual units required and thus may also affect the number of servers.
Restrictions of virtual unit capacity do not necessarily correlate to available CPU or I/O power. They can be due
to the number of threads a process may create or some other operating system or software-specific features.
One server may thus run several, even similar, virtual units. Chapter 14, Sizing, covers this topic in more detail.
Availability demands determine precautions for eventual fault incidences and procedures for maintenance
tasks. Precautions for fault incidences are failover mechanisms. Failover can be configured in the following
ways:
-
Manual failover
26
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
-
Automatic failover
-
Failover to other active SAP Contact Center servers
-
Failover to inactive dedicated failover servers
Manual and automatic failover is covered in chapter 12, Availability and maintenance. This topic may affect
the number of required servers. With manual failover, an operator can choose the most suitable one of the
available failover destinations. With automatic failover, capacity must be prepared in advance at one or more
specific failover destinations.
If the set of active SAP Contact Center servers are only moderately utilized and the capacity budget allows it,
failover destinations may be configured within the set without using dedicated standby servers for failover. If
utilization increases over time, the setup can be reconfigured with one or more dedicated standby failover
servers.
When maintenance tasks can be performed outside office hours there is no 24/7 demand and there is no
demand for additional failover destinations for maintenance reasons. If it is not possible to perform maintenance
outside office hours because of a 24/7 demand, failover destinations must be available to enable uninterrupted
service during maintenance.
4.1.2 Type of servers
SAP Contact Center runs on industry standard x86 and x64 based server hardware. There are several
selection criteria for the servers and the emphasis may vary from case to case. The most essential criteria are
described below.
4.1.2.1 Storage and application servers
From a functional point of view two types of servers are used:
-
Storage servers with significant file I/O, storage capacity and backup demands
-
Application servers with performance focus on CPU and networking
Storage servers refer to SAP Contact Center (SQL) database servers and file servers. SAP Contact Center
database servers are used for storing, for example, system configuration, user accounts and call detail records
(CDR). File servers are used for storing, for example, prompts, voice mail messages, recordings and
attachments. Storage servers contain both static data (configuration and user data) and dynamic accounting
data (CDR).
The static data is crucial to the operation of SAP Contact Center and therefore attention must be paid to its
availability. It is recommended that static data is kept on clustered servers and that the data is regularly backed
up.
The dynamic data is not crucial to the ongoing operation of SAP Contact Center, but its value is often essential
because of billing, production control, service control or other business related issues and may thus be vital to
the service provider and/or to the customer. It is recommended that dynamic data is kept on clustered servers
and that the data is regularly backed up.
27
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
Application servers run various SAP Contact Center virtual units. They retrieve process and store data between
users, other virtual units and data storages. Application servers are replaceable in the sense that they do not
contain any crucial data and their assignments can therefore be overtaken by other servers.
Performance characteristics have emphasis on file I/0 and storage capacity for storage servers and network I/0
and CPU for application servers.
4.1.2.2 Server chassis and operability
It might seem that there is no, or very little, importance in what type of server chassis is selected. As noticed
earlier, this also may vary from case to case and it may have considerable importance in some cases. Server
chassis alternatives are:
-
Tower
-
Rack
-
Blade
Tower servers are suitable for in-house setups, if the existing facilities do not require any other type of servers
to be selected. Tower servers often have the space for sufficient RAID (redundant array of inexpensive disks)
disks, integrated sophisticated RAID controllers and enough slots for possible additional RAID controllers and
network interface cards. The drawbacks of tower servers compared to the others are:
-
Big space requirements.
-
Lack of built-in KVM (keyboard, video, mouse) switches/multiplexers.
-
Discrete power and network cabling.
Rack servers are designed to be mounted in a server cabinet. The advantages of using rack servers are:
-
More effective space usage
-
Better order and control of servers and cables
-
Possibility to arrange and adjust power and cooling on a per cabinet basis.
-
Some rack servers contain built-in KVM switches enabling a group of servers to be operated
from one console.
Rack servers come in different sizes or heights. The height of rack servers is measured in units (U) where one
U is the minimum height of a device that can be installed in a cabinet. A cabinet may contain for example 40 or
42 U. One U servers are usually suitable for application servers whereas, storage servers require more space
for disks and possible additional network and/or RAID boards. Rack mount kits are available for some tower
servers.
Attention should be paid to the cooling of rack mounted servers. Cooled air should flow through the cabinet, for
example from the bottom to the top.
Rack-mounted servers are a good choice for enterprises and service providers running several servers.
28
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
Blade servers are electronics boards that are installed to a blade chassis. The blade chassis is installed in a
similar cabinet as rack servers. The blade chassis provides power and required interfaces to the blade. Benefits
of blade servers are:
-
The most effective space usage
-
Integrated cabling, power, network and storage
-
In some cases, integrated LAN switches
-
Integrated KVM switches
-
Improved reliability due to the integrations
-
Possibility to configure hot standby blades
Regardless of the selected chassis type, the following features are recommended:
-
Dual power supplies for increased availability
-
Dual fans for increased availability
-
Management, such as HP ILO and/or SNMP for retrieving notifications of possible failures or
arising problems.
-
Separate physical network interfaces for each network (core, access, management) the server
connects to.
29
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
4.1.2.3 Server specifications
SAP CCtr
Storage
Server, File
Server
SAP CCtr
Storage
Server,
SQL
SAP CCtr
Application
server
Feature
SAP CCtr
light
Application
server
These server specifications are indicative. The recommended specifications are based on experiences from
existing installations in service provider and in-house setups. Below are the minimum and recommended server
specifications.
MIN
REC
MIN
REC
MIN
REC
MIN
REC
1 GHz
> 1 GHz
1 GHz
>= 2 GHz
2 GHz
> 2 GHz
1 GHz
>= 2
GHz
1
2
2
2-4
1
2-4
1
>=2
1 GB
2 - 4 GB
1 GB
2 - 8 GB
4 GB
4 – 32
GB
1 GB
>= 2 GB
100
Base-T
1000
Base-T
100
Base-T
1000
Base-T
100
Base-T
1000
Base-T
100
Base-T
1000
Base-T
1
1
1
1-2
1
1-3
1
1-3
Operating system
on local disks
Yes
Yes
Yes
-
Yes
Yes
Yes
Yes
Data on local disks
Yes
Yes
Yes
-
Yes
No
Yes
No
Operating system
on SAN
-
-
-
Yes
-
No
-
No
Data on SAN
-
-
-
Yes
-
Yes
-
Yes
CPU speed
Number of CPUs &
cores together
RAM
Network interface
Number of network
interfaces
A SAP Contact Center light application server is running only few SAP Contact Center components or is very
lightly utilized, for example, a demo system.
The design aspects of the entirety may lead to standardizing application server configurations and to thus make
the hardware interchangeable, so that, for example, any SAP Contact Center light application server can be
assigned the tasks of any other SAP Contact Center light application server without any need to upgrade the
hardware. An arrangement including some minor additional investments in hardware, such as RAM, might be
required. Those investments facilitate smoother maintenance practices and are quickly paid back.
From a dimensioning perspective, it is recommended to allocate one dedicated CPU for the OS on servers that
are expected to have high utilization even if the CPU control mechanisms are not available. CPU cores
available to SQL Server instances can be configured and it is recommended to configure each SQL server with
at least one dedicated CPU core.
SQL Servers benefit from all available RAM. In a multi-instance installation, the amount of RAM available for
each instance can be configured. Especially in reporting and analysis, but not limited to these, the performance
is improved by increasing available RAM.
30
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
The number of network interfaces depends on several things:
-
Network topology: Dual-hosted servers require at least two network interfaces. A server can
be connected, for example, to an access network and to a management network or to an
access network and to a core network.
-
High availability: Network teaming (a dual connection providing fault tolerance) requires at
least two network interfaces.
-
Clustering: It is recommended that at least three network connections are made available for
cluster control and heartbeat traffic and that at least one of them is dedicated for this purpose.
The best location of the operating system and the data, which would be either local or SAN disks, is affected by
the intended maintenance procedures:
-
Using servers, especially blade servers, retrieving the operating system from SAN and storing
data to SAN and not having any local disks, makes the servers “dummy” electronics boards
with no identity. This enables fast and easy reassignments of servers to different tasks and can
be useful, for example, during version updates and when applying patches.
-
All servers should have at least a mirrored (RAID-1) disk configuration. In some cases, for
example, with DMZ servers, it might be more reasonable to use local disks.
-
Cluster servers should always have local disks for the operating system and SAN disks for
data to ensure proper cluster control and data availability at all times.
The hyphen “-“ in the table indicates a neutral attitude. The decision is usually made based on existing
possibilities and on design aspects of the entirety.
See appendix A for sample SAP Contact Center Servers.
31
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
4.2 Operating systems
Windows 2008 x64
Standard edition
Windows 2008 x64
Enterprise edition
Windows 2012
Standard edition
Supported operating Systems for SAP Contact Center servers are English versions of Windows Server 2008,
Windows Server 2008 R2 (both referred to as Windows 2008 in this context, if not explicitly mentioned
otherwise) and Windows Server 2012, all with the latest service packs. Supported editions are Standard and
Enterprise. Below are the most significant features of the editions and the differences between them in relation
to SAP Contact Center.
Max memory
32 GB
2 TB
4 TB
x64 sockets
4
8
64
Cluster service
No
Yes
Yes
Feature
Standard editions are recommended for SAP Contact Center application servers. Enterprise edition is
recommended for SAP Contact Center storage servers because of the larger amount of maximum memory and
the clustering capability. If clustering is not required for file servers, standard edition can be used. It is
recommended to always apply the latest services packs provided by Microsoft.
4.3 Software
Software refers to third party software required by SAP Contact Center, such as SQL Server. Essential
software and/or operating system services for SAP Contact Center are:
-
Windows Server Active Directory
-
Microsoft Internet Information Server
-
Microsoft SQL Server
-
Microsoft Certificate Services (optional)
-
Windows DCHP Server (optional)
-
A TFTP Server (optional)
-
A syslog server (optional)
SAP Contact Center servers are usually added to a Windows domain. Some exceptions exist, for example, a
SAP Contact Center CS Server installed in a DMZ zone does not typically belong to any domain. Windows
Server Active Directory is used for maintaining Windows user and computer accounts in that domain. Windows
user accounts are created for SAP Contact Center administrators, operators and services.
32
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
Microsoft Internet Information Server is used for running SAP Contact Center web services, such as the CDT
and Administrator interfaces.
Microsoft SQL Server is the database system used by SAP Contact Center. See section 4.3.1, Microsoft SQL
Server, for more information about Microsoft SQL Server.
Microsoft Certificate Services (CA) can be used to create self-granted server certificates for encrypted SSL
connections. Parties (such as hosts and services) connecting to services using self-granted certificates must
recognize the issuing CA as a trusted root.
Windows DHCP Server can be used to provide gateways, IP desk phones and other equipment residing in the
server network with IP-addresses and additional information, such as boot files, configuration files and
configuration information.
A TFTP server (any available) can be configured in the DHCP information as a destination where IP Desk
Phones can find additional configuration information. Configuration information can also be stored from a
device to a TFTP server for example as a backup.
A syslog server can be used to log messages from devices such as IP Desk Phones and gateways. Most
devices provide alternative log levels to avoid storing uninteresting information. A syslog server with the ability
to filter syslog events and forward selected ones via e-mail and/or notifying of essential events via SNMP
(simple network management protocol) is recommended.
33
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
4.3.1 Microsoft SQL Server
Microsoft SQL Server comes in different editions of which SQL Server 2008 Standard and Enterprise editions
and SQL Server 2012 Standard editions and 64-bit systems are supported.
SQL Server 2008
R2 Standard
edition
SQL Server 2008
R2 Enterprise
edition
SQL Server 2012
Standard edition
Below are the most important features of the editions and differences between them in relation to SAP Contact
Center.
Max number of CPUs
4
8
¤lesser of 4
sockets or
16 cores
Max RAM
64 GB
2 TB
64 GB
Database size
524 PB
524 PB
524 PB
Database mirroring
Yes
(single
thread)
Yes
Yes
Failover clustering
Yes
Yes
Yes
Feature
SQL Servers running the reporting databases should have the SQL Server options Analysis Services and
Reporting Services installed.
4.3.2 Microsoft Internet Information Server
Microsoft Internet Information Server (IIS) is used by SAP Contact Center to provide user interfaces to CDT and
to administrative tools. IIS is included with the Windows Server but not installed by default and is an option that
needs to be selected manually.
If e-mail notifications are needed, for example, from voice mails and SMS messages, SMTP (simple mail
transfer protocol) needs to be installed. SMTP is included with IIS, but not installed by default and is an option
that needs to be selected manually.
One IIS server can contain several web sites, one per each installed virtual unit, for example, VU_WEB_USER.
Each web site and thus virtual unit can and preferably should be assigned a unique IP address. Backup
instances of each web site should share that same unique IP address.
4.3.3 Certificates
SAP Contact Center uses SSL server certificates to authenticate SAP Contact Center servers and to encrypt
traffic between servers and clients. Servers refer to SAP Contact Center components listening to connection
attempts. Clients refer to SAP Contact Center components initiating connections. Both servers and clients can
be SAP Contact Center service components. Authentication succeeds when all of the following are true:
34
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
-
The URL connected to matches the name the certificate is issued to.
-
The certificate date is valid.
-
The issuer of the certificate is trusted by the client.
Certificates can be obtained from any certification authority (CA) trusted by the client. Windows Server
contains by default several trusted certification authority (trusted roots) certificates. Trusted CAs can be added
by adding their certificates among the trusted certification authorities.
For internal usage, for example, for authentication and encryption inside the core or access network, the
certification authority services included with Windows Server can be used. They are not installed by default and
need to be selected manually. For self-granted certificates, the certificate of the issuer needs to be distributed
to the clients, usually manually.
For other usage certificates issued by public certificate authorities are recommended to avoid massive
distribution of CA certificates to numerous clients. Public certificate authorities are, for example, VeriSign and
Thawte.
35
GATEWAYS AND SIP TRUNKS
5 Gateways and SIP trunks
Gateways connect PRI-lines from PSTN networks to IP networks and enable calls to pass from one to the
other. SIP trunks do the same except for that they are already IP so no conversion is needed on network level.
However, some conversion on SIP protocol level might be needed to make the two SIP implementations work
together. This is done by a Session Border Controller that usually also provides security features and
sometimes even codec translation (transcoding).
In in-house cases gateways are installed in the customer LAN. In service provider cases, they are typically
installed in the service provider network but they can also be distributed over the customer LAN or over the
service provider network and customer LAN. The same applies to SIP trunks.
SAP Contact Center uses primarily SIP as the control protocol toward gateways and SIP trunks. The H.323
protocol is also supported but no new features are implemented upon that protocol in SAP Contact Center.
SIP Bridges and H.323 Bridges are call control components interfacing towards gateways and SIP trunks in
SAP Contact Center.
Finding suitable locations for gateways and SIP trunks is an important step in designing each SAP Contact
Center landscape. Affecting factors are:
-
Cost of PRI-lines, gateways, SIP trunks and SBCs
-
Cost of sufficient bandwidth from gateways and SBCs to voice endpoints (LAN & WAN)
-
Preferred telephone numbering, regional or nationwide (e.g. area codes)
Because of the real-time requirement of voice streams, the networks ability to carry them is considered in
landscape design. To be able to optimize the network’s ability to carry voice, it is essential to understand the
possible voice stream paths and to recognize the possible endpoints. Gateways and SBCs are voice stream
endpoints in external calls. The other voice stream endpoint is either an immediate endpoint such as:
-
IP desk phone
-
CDT
-
IVR
-
Voice Mail
-
In some special cases, another gateway
Or, it can be an intermediate endpoint, such as the SAP Contact Center MRS (media routing server)
component, which forwards the voice stream to a next endpoint.
MRS may also be an immediate voice stream endpoint depending on its function. MRS is used to:
-
Play prompts (immediate)
-
Record voice streams (immediate)
-
Relay voice streams (intermediate)
-
NAT fixup (intermediate)
-
Encryption endpoint (immediate or intermediate)
5.1 Distributing gateways and SIP trunks
Distributing gateways and SIP trunks over headquarters and branch offices may provide local telephone
numbering and may also significantly reduce the required WAN bandwidth between the sites and the service
provider network.
36
GATEWAYS AND SIP TRUNKS
Distributing gateways may at the same time increase the number of required gateway capacity or SIP trunks.
For example a company has two offices and a
demand for a maximum of 30 simultaneous
calls. If nationwide telephone numbering is used,
the company can manage with one gateway and
one E1 line in the service center network. Less
than a 2 Mbit/s data link is required but smaller
data links with sufficient capacity are often not
available.
If regional telephone numbering is used at both
offices, two gateways and two E1 lines are required.
The narrower data links are sufficient for Control
Protocols and UI traffic (CDT). If prompts are played
often 1 Mbit/s links should be used instead, or MRS at
each site should be available to provide prompts
locally.
PSTN
PSTN
E1
Service
Provider
E1
2 Mbit/s
Service
Provider
Site 1
LAN
512 kbit/s
512 kbit/s
2 Mbit/s
Site 1
LAN
Site 2
LAN
Client
E1
Enterprise
Network
Site 2
LAN
Client
Client
Figure 11. Gateway located in service provider
network
Enterprise
Network
Client
Figure 12. Gateways distributed to each customer
office.
.
Back-up capacity is often wanted, which also comes in multiples of E1/T1/J1 lines and gateways. Fault
tolerance might be easier to arrange using SIP trunks because SIP trunks are often provided from clusters. Still,
the fault tolerance is probably sold as an additional service and fault tolerant underlying connections may also
be needed.
Combining nationwide telephone numbering with gateways and SIP trunks distributed to both offices can
provide back-up capacity for one PSTN link if sufficient IP bandwidth is available for carrying voice between the
offices.
Another level of back-up capacity can be arranged by locating both gateways in the service provider network
and by ordering the E1/T1/J1 lines to different telephone exchanges in the PSTN. This presumes that the PSTN
cabling routes are sufficiently separated all the way to the gateways in order to eliminate single points of failure.
This also usually presumes that nationwide numbering or the same regional numbering is used.
5.2 Connecting to a PBX
Gateways can also be used to interconnect SAP Contact Center systems with existing private branch
exchanges (PBX) or PBX networks to enable calls to pass from one to the other. This can be done, for
example, to implement the SAP Contact Center deployment in phases. Technical connections must be done,
telephone number ranges must be matched and routing rules configured on both sides.
For example the company A has a telephone number range of 250 1300 – 250 1799. The SAP Contact Center
migration is not yet completed and 300 subscriptions are created in SAP Contact Center while 200 still exist on
the traditional PBX.
SAP Contact Center subscriptions are assigned the numbers 250 1300 – 250 1599 and the numbers 250 1600
– 250 1799 are still in the PBX.
To enable calls between all employees, a gateway is installed to connect the SAP Contact Center system to the
PBX. The E1/T1/J1 port of the gateway is used to connect to the PBX and as normally, the Ethernet port is
37
GATEWAYS AND SIP TRUNKS
used to connect to the SAP Contact Center system.
The PBX is configured to route all, except the numbers 250 1600 – 250 1799, to the port where the gateway is
connected.
The gateway is configured to route the numbers 250 1600 – 250 1799 to the port where the PBX is connected.
PSTN
All but
250 1600
250 1799
All but
250 1300
250 1799
PBX
250 1300
250 1799
250 1600
250 1799
SAP CCtr System
Figure 13. Connecting a gateway to a PBX.
Another way to do the interconnection is showed in figure 14, where the gateway is connected between the
PSTN and the PBX. This setup requires the gateway that has at least two E1/T1/J1 ports and the capability to
route configured number ranges as showed in figure 14. Usually this setup is reasonable when only one
E1/T1/J1 connection is needed to connect to the PSTN.
PSTN
250 1300
250 1599
All but
250 1300
250 1799
SAP CCtr System
250 1600
250 1799
All but
250 1600
250 1799
PBX
Figure 14. Connecting a gateway between the PSTN and a PBX.
38
GATEWAYS AND SIP TRUNKS
5.3 Miscellaneous settings
Gateways are usually configured by default to retrieve the synchronization clock signal from the PSTN network.
Gateways are typically configured as slaves and the telephone exchange, to which the gateway is connected, is
configured as a master. Connecting to a PBX involves explicitly setting either the PBX or the gateway as a
master and the other as a slave. Master is also referred to as NT (network terminal) and slave as TE (terminal
equipment).
ISDN is sometimes referred to as DSS1 (digital signaling system 1). The protocol used on the PSTN side
should be ISDN S2. R2 is not supported.
Voice codecs supported by SAP Contact Center are G.711 and G.729. The cloud edition supports only G.711.
ISDN protocols refers to N-ISDN including Q.931 and Q.921.
5.4 Cisco gateways
SAP Contact Center supports Cisco multiservice Modular Access routers configured to VoIP gateways using
High Density Voice Network Modules. These gateways differ essentially from the other supported gateways in
the way they are built and in that they simultaneously serve as routers. Other supported gateways include also
modular models but they are less complex.
Such a Cisco gateway is comprised by:
-
A multiservice Modular Access Router
-
One or more High Density Voice (HDV) Network Modules (NM)
-
One or more Voice/WAN Interface Cards (VWIC)
-
One or more Packet Voice DSP Modules (PDVM)
Each HDV Network module has one VWIC slot. The VWIC provides the interface to the PSTN, E1, T1 or J1.
VWICs are available with one or two T1/E1/J1 ports.
Up to 5 PDVMs can be installed on each HDV Network Module. The amount of required PDVMs depends on
the amount of simultaneous calls and codec being used.
For more information, see www.cisco.com.
Supported and recommended hardware, operating systems and software can be found in the infrastructure
compatibility list (ICL) in the support portal.
39
DATA CENTER LAN
6 Data center LAN
Data center LAN refers to the LAN, where the SAP Contact Center Servers reside and where the SAP Contact
Center services are produced by a service provider or by an in house operator. The LAN consists basically of
Ethernet Switches connecting servers and network devices together over LAN cables, such as CAT5/6, and IP
routers connecting the LAN to the outside world over WAN links. Recommended networks are 1000 Base-T
switched networks.
SAP Contact Center service availability is extremely important to the customers and to the users. It appears far
more critical than traditional IT systems like e-mail and World Wide Web. The most important features of the
data center LAN are:
-
Performance
-
Availability
The data center LAN is crucial to the SAP Contact Center service availability as the SAP Contact Center
service availability cannot exceed the data center LAN availability. The performance of the data center LAN is
vital to the SAP Contact Center service availability because only minor and occasional voice distortions are
tolerated, if any.
6.1 Performance
Different traffic shapes apply to different network boundaries. Between a management network and a core
network, there is management traffic, such as SNMP traffic and traffic related to configuration tasks. Between a
core network and an access network there are mainly database queries and SAP Contact Center Control
Traffic. Unlike voice streams, these do not have real time demands.
Voice streams are typically carried from voice endpoints in the access networks over service and access links
to voice endpoints in the customer LAN. Voice endpoints are any immediate or intermediate devices or services
transmitting or receiving voice, such as CDTs, IP desk phones, VoIP gateways, routers and MRSs.
It is recommended to keep the network layout as straight-forward as possible by minimizing the network
distance between endpoints. Doing this provides more robustness against voice distortions due to increasing
delay caused by increasing overall utilization. This also minimizes the number of devices a particular service
depends on and minimizes the points of failure. Increased overall utilization can be caused, for example, by
new end users and customers, but also by poor configuration allowing or generating unnecessary traffic.
The above can be applied the other way around too. In a data center access network serving several
customers, minimizing the network distance between service endpoints may decrease the number of services
that depend on any particular device and can therefore be considered as a kind of segmentation into smaller
failure domains.
6.1.1 Minimizing network distances
In a network based on hubs directing all traffic to every port and thus all over the LAN, the maximum nominal
capacity equals the maximum peak performance, for example, in a 100 Base-T network the aggregate
momentary throughput cannot exceed 100 Mbit/s.
However, switched networks allow for traffic isolation between parties and traffic is not unnecessarily
propagated all over the network. Therefore in a switched network with the nominal capacity of 100 Mbit/s, two
or more simultaneous fully utilized 100 Mbit/s connections may exist.
Switched networks are strongly recommended for SAP Contact Center data center networks as well as
customer LANs. Small SOHO (small office home office) sites with only a few hosts and modestly utilized
networks are an exception with less strict recommendations.
The maximum aggregate performance of a switched network depends on the network topology and on the
performance of the network devices themselves. The absolute maximum capacity of any link and switch port is
40
DATA CENTER LAN
its nominal speed. Two switches connected together over a 100 Mbit/s link cannot carry more than 100 Mbit/s
data between them although the total demand from other ports would exceed this as depicted below.
A
B
C
Switch 2
D
E
100 Mbit/s
/s
bit
0 M ON
2
1
I
nd ST
ma NGE
e
D CO
F
G
H
40 Mbit/s
H
40 Mbit/s
G
40 Mbit/s
F
40 Mbit/s
Switch 1
D
E
C
40 Mbit/s
B
40 Mbit/s
A
Figure 15. Network congestion/overload on interconnecting link between switches.
Devices contributing to one and the same service should be located close by in the network to minimize the
network distances and thus to optimize the network performance as figure 16 shows..
A
100 Mbit/s
it/s
Mb ION
0
8
T
nd ES
ma ONG
e
D
C
NO
B
C
Switch 2
D
E
F
G
H
40 Mbit/s
H
40 Mbit/s
G
40 Mbit/s
F
40 Mbit/s
Switch 1
D
E
C
40 Mbit/s
B
40 Mbit/s
A
Figure 16. Network distance between related services is minimized to optimize performance. The host or
segment connected to switch 1, port F, has been moved to switch 2, port H.
One solution is to use 1000 Base-T links between switches, but it is still recommended to minimize the network
distance between related devices and services. Every additional hop introduces a potential delay and a
potential point of failure.
Based on this, it seems that in a switched network the aggregate capacity is a multiplier n times the nominal
network capacity, where the multiplier n depends on the network topology and the capability and speed of the
switches to queue and forward traffic. However, queuing traffic introduces delivery delays eventually distorting
the voice quality.
Service segmentation provides some certainty of service availability and service infrastructure should be
divided into self-sufficient parts independent on incidents in other parts. Therefore it is recommended to have
another access network in advance before the previous is utilized to its reasonable extents.
6.1.2 LAN capacity
For data center LANs, 1000 Base-T (1 Gbit/s) is recommended for core networks. A core network can serve
more than one access network, either physical or logical. The capacity demands of the access networks relates
to the aggregated capacity of the service links or access links. (See chapter 1, Introduction for a description of
41
DATA CENTER LAN
core networks, access networks, service links and access links).
Assuming that, in a pure SAP Contact Center environment:
an average Ethernet network utilization of 40% is a reasonable maximum limit
80% of the traffic would be destined over access links and 20% to and from the core network
It would occur that a 100 Base-T access network would be capable of serving approximately
100 Mbit/s x 0,4 x 0,8 = 32 Mbit/s access and service links.
In a switched, well-structured network this might apply to each one switch in the network. The network
utilization varies over time as the number of simultaneous calls and directory queries varies. Unlike traditional
IT systems like e-mail, where it is possible to wait some seconds in a congestion situation, a SAP Contact
Center system must be designed to carry-real time voice at any moment as dimensioned. Average loads do not
count and dimensioning must apply to peak loads.
6.1.3 VLAN
Virtual LANs (VLANs) provide broadcast filtering, security, address summarization and traffic flow management.
VLANs can be used to provide the segmentation services traditionally provided by routers in LAN
configurations, for example, to split a large access network into segments and by doing this, increasing
manageability and security. By definition, switches may not bridge IP traffic between VLANs because it would
violate the integrity of the VLAN broadcast domain.
VLANs have the same attributes as physical LANs but they allow for end stations to be grouped together even
if they are not on the same LAN segment. In a legacy network, end stations are assigned to networks based on
geographical location. Using VLANs, networks can be logically grouped without physical LAN topology
restrictions.
Two kinds of VLANs exist. One is based on the protocol IEEE 802.1Q, where Ethernet frames are tagged with
VLAN information allowing for VLAN multiplexing over trunk lines. These VLANs are suitable for reaching
logical core, management and access networks over multiple sites. Each VLAN appears as one and the same
network regardless of its physical location.
The other kind of VLANs are port-based VLANs. With port-based VLANs two or more switch ports are assigned
a VLAN identifier which groups the ports together to a port-based VLAN. Traffic cannot flow between ports
belonging to different VLANs without passing through a VLAN router. Multi-VLAN ports may be configured to,
for example, provide management or database services from a single VLAN to multiple other VLANs.
6.2 Availability
The data center LAN availability focuses on keeping the network serve its purpose by avoiding unnecessary or
unwarranted traffic and by preparing for failures. Together with diligent network management, operation and
monitoring, access control and fault tolerance are central elements of high availability. Prioritizing may also be
considered a protection mechanism with similarities to access control.
6.2.1 Access control
Access control is an enforcement method allowing only relevant traffic. Unwarranted traffic is rejected at outer
network boundaries by firewalls but there might be unnecessary traffic inside generated by servers and network
devices. Switches with ACL (access list) capabilities can be used to constrain the inside distribution of
unnecessary traffic in the network.
See chapter 11, Security, for access control at outer network boundaries as protection against external threats.
In this context, access control is considered as an enabler for network robustness which is done with access
42
DATA CENTER LAN
lists on switches. Access control can be based on, for example, any of the following:
-
Source IP address or address range
-
Destination IP address or address range
-
Source port number or port number range
-
Destination port number or port number range
-
Protocol
-
Connection direction for TCP protocols
The data center LAN may be segmented into different networks to obtain more granular control over it and the
network traffic in it. Such segments may be, for example, core, access and management networks where
boundary controls are implemented and/or virtual LANs (VLAN) assigned to a customer or a group of
customers.
Access controls inside a segment, or even inside a data center LAN, can be implemented with switches but on
the outside boundary towards a customer or another organization, more sophisticated firewalls are
recommended.
Access control contributes to availability and high quality of service. It may constrain the distribution of
unnecessary or even malicious traffic caused by:
-
Accidental improper configuration
-
Improper functionality caused by, for example, software bugs
-
DoS (denial of service) attacks, malicious and other
-
Faulty devices
Access control should be carefully planned and clear benefits and objectives should be recognized, such as,
allowing specified traffic shapes or protecting organization limits. Good options are allowing only voice streams
and control protocols to voice endpoints or allowing only traffic to and from a specific organization. Access
control should be kept as simple as possible and well documented.
6.2.2 Prioritizing
Prioritizing involves categorizing traffic into different traffic classes and to assign priorities to those classes.
Categorization of traffic can mainly be based on the same factors as access control and it can also be based on
a type of service identifier (ToS or ToS bit). Traffic with higher priority is passed through network devices, such
as switches and routers, before traffic with lower priority. ToS bits are usually set by endpoint but it is also
possible in some cases to set ToS bits on network devices on the transmission path.
In opposite to access control, which strictly allows or rejects traffic, prioritizing does not initially reject traffic but
instead allows higher prioritized traffic pass before lower prioritized traffic. With increased utilization and
congestion, prioritizing will eventually cause low priority traffic to be dropped and thus allow higher priority traffic
to be carried over the network.
Prioritizing is a mechanism providing control over bandwidth usage. It does not provide means to counteract
low bandwidth. Prioritizing may provide higher availability in the same cases as access control and it could also
be seen as a performance factor.
6.2.3 Fault tolerance
Fault tolerance protects the service production against physical device and network failures by routing the traffic
over an alternative path in case of failure of a link or network device. The fault tolerance degree of the network
43
DATA CENTER LAN
may vary. It may include the whole data center LAN, only the most critical parts of it or something in between.
The fault tolerance of the data center LAN is a part of the overall SAP Contact Center service fault tolerance
and it relates to fault tolerance implemented by network topology designs, network hardware and network
protocols.
6.2.3.1 Deciding on the fault tolerance degree
The fault tolerance degree is a business decision based on risk analyses and liabilities of service availability.
Moreover, it is also associated with the reputation the of service provider wanting to provide outstanding
services.
The following questions can be used when deciding on the degree of the fault tolerance:
-
Are total (all services/customers) service downtimes allowable?
If not, then the following can be used:
- Independent service pools are required to constrain the service breaks.
- Partially independent service pools sharing common clustered service pools are required
- The service pools must contain comprehensive failover mechanisms.
-
Is a couple of minutes of downtime allowed during a failover?
If not, then the failover probability must be minimized by adding robustness to each component
Each step costs additionally and each incidence has its price, probability and estimated recurrence. However,
the reasoning described below is difficult and laborious to use when drilling into a variety of details and
equipment. Another thing is that the cost of an incidence is easily underestimated.
An incidence may involve:
-
Interrupting ongoing tasks and thus delaying new business
-
Working overtime
-
Requiring third party services outside business hours
-
Penalties to customers
-
Reputation damage
To keep the reasoning simple, think if a particular incidence is allowed even once. If not, then counteract it.
Otherwise follow-up the recurrence and reconsider the situation if needed.
In general, it is recommended that all simple fault tolerance measures are implemented, such as:
-
Dual power supplies
-
Dual cooling fans
The final outcome of the reasoning should be a fault tolerance plan or a risk chart showing the critical spots and
outlining the steps of precaution.
6.2.3.2 Teaming
Teaming is a technique using two or more network cards to connect a server to the network. The team or the
group of network cards appears as one logical network card in the operating system. The remaining network
cards assume the traffic of the failed card, if one network card in the group fails. The virtual network card has
44
DATA CENTER LAN
one MAC address and one or more IP addresses just as real network cards do. Teamed network cards also
share the network load increasing the available network bandwidth and providing load balancing.
6.3 Multiple Sites
SAP Contact Center services may be available from more than one real-time failover site. This is typically the
case when the business grows to and it becomes too risky to rely on only one site, or when there are legislative
demands of guaranteeing service availability from more than one site. Arranging with two sites provides for
disaster tolerance and disaster recovery.
Basically, providing the SAP Contact Center services from two or more alternative sites requires:
-
Alternative premises with far enough distance between them. The distance depends on the
disaster prepared for. For protection against fire emergencies, collapsed buildings, power
outages and data link outages, a suitable distance could be about 20 km or more. Power and
data network structures should be discussed with respective providers before deciding
alternative locations.
-
Partially or fully duplicated production equipment, such as servers and gateways. It is possible
to run only selected services with standby failover on remote sites.
-
Connections to the PSTN from each site.
-
Service links to each site.
-
Duplicated connections between the sites.
-
Common data storage, preferably a real-time mirrored SAN between the sites.
Obviously providing real time failover services from alternative sites is costly. However, the actual case might
be that only a fragment of the customers demand this high availability and disaster tolerance. Establishing
alternative production sites provides also more production capacity and preparing for alternative sites might be
a good growth strategy from the very beginning. This reduces the risk of having too much of the service
provider business on one site and reduces the initial costs by keeping premises and facilities a little bit smaller
at the beginning.
The majority of multi-site concerns are exactly the same as with single sites because multi-sites are run with,
for example, identical servers and data links. The points to focus on are:
-
Common broadcast domain in all failover sites.
-
Connecting sites together
-
Data connectivity and routing
-
Distributed real-time mirrored SAN
-
Incoming call routing
-
Arranging for cluster and HAC nodes in each site
6.3.1 Common broadcast domain
The Ethernet broadcast domain is the area or group of devices receiving Ethernet broadcast messages. The
Ethernet addressing is based on MAC addresses, also known as hardware addresses. The address is a
hexadecimal number unique to each network interface card.
Since MAC addresses are not divided into network and host portions, a host cannot determine from the MAC
45
DATA CENTER LAN
address of another host if that is on the same network or not.
To be able to address hosts on other networks, IP addresses are used. IP addresses contain a host portion and
a network portion. Another host is in the same network if the senders and receivers network portion of the IP
address are the same. Otherwise it is on a different network and will be addressed via a router.
Hosts and services are configured with IP addresses. For example, an IP desk phone is configured to find its
registrar at the IP address 10.10.0.5.
The IP desk phone uses ARP (address resolution protocol) to determine the MAC address of the registrar by
sending an ARP request containing the IP address 10.10.0.5 and the MAC address of the sender. ARP
requests are sent with Ethernet broadcast addresses and received by every other host in that network. The
host configured with the IP address 10.10.0.5 replies with an ARP reply containing its MAC address. This way,
MAC addresses are changed between hosts and the rest of the communication continues using these MAC
addresses. Hosts store MAC addresses in their ARP tables until they expire. Then they are requested for again
when needed.
The SAP Contact Center high availability concept includes virtual IP addresses assigned to SAP Contact
Center services. The virtual IP address hides the actual server or site from the user.
The SAP Contact Center high availability concept is based on virtual units having more than one instance
sharing the same IP address and of which only one instance is active at a time. However, each instance has its
own network interfaces and its own MAC addresses that must be resolvable by the router connecting to the
customer.
Therefore, sites must be in the same broadcast domain and there must not be a routed connection between
them.
6.3.2 Connecting sites together
IP and Fibre Channel links can be used to connect two sites together. Fibre Channel is a gigabit-speed network
technology primarily used for storage networking. Here it is used to connect the SANs of the two sites together.
IP is used for all the remaining traffic.
Single mode (SM) optical fibers are recommended as the physical link media between sites, because of their
excellent ability to carry information over long distances without any repetition or other electronic intermediate
devices constituting points of failure. One fiber link consists of two fiber strains or a fiber pair. For fault
tolerance, two separately routed fiber pairs are used.
CWDM (coarse wavelength division multiplexing) is used to deploy different services such as IP and FC over a
single fiber pair. CWDM is an optical technology for transmitting several channels, each in a separate
wavelength or color, over the same fiber strand. Unlike DWDM (dense wavelength division multiplexing) which
can transmit 32 or more channels on the same fiber, CWDM uses a more loose spacing between channels and
is less expensive than DWDM. The International Telecommunication Union (ITU) has standardized a 20 nm
channel spacing grid for use with CWDM with the wavelengths between 1310 nm and 1610 nm.
Site 1
Site 2
Gray
Violet
Blue
Green
Yellow
Orange
Red
Brown
Gray
Violet
Blue
Green
SM Fiber pair
(receiving &
transmitting)
Yellow
Orange
Red
Brown
46
DATA CENTER LAN
Figure 17. Multiplexing several channels over an optical fiber pair (CWDM).
Figure 17 shows two eight channel CWDM multiplexers connected over a SM fiber pair. Each channel can be
used to interconnect a 1000 Base-T Ethernet network, VLAN or Fibre Channel network between the sites.
Figure 18 shows an Ethernet network or a VLAN connection between two sites. The four edge switches are
connected together in a ring. The spanning tree protocol is used to determine active path between the sites.
Site 1
Spanning Tree
Site 2
Figure 18. Two fiber links routed physically apart are used to interconnect the sites.
47
DATA CENTER LAN
6.3.3 Data connectivity and routing
For customers to be able to benefit from the services from a failover site, data connectivity must be arranged to
the failover site as well. The same dimensioning is valid as for the primary site, but there must be a way to
automatically reroute the traffic.
With SAP Contact Center, the
service is reached at the failover
site (site 2) with the same IP
address as it was at the primary
site (site 1).
A virtual router cluster running
HSRP (hot standby router protocol),
in close association with a rapidconverging routing protocol such as
OSPF (open shortest path first), is
used to do the rerouting.
Two or more routers running HSRP
in, for example, the service provider
network appears as one virtual
router. HSRP is used between the
routers in the HSRP group to
decide the active router.
Service
Provider
Network
Site 1
Site 2
Common
Broadcast
Domain
Ethernet
Ethernet
HSRP
Group
Virtually one router
Serial
Serial
OSPF
WAN
Serial
Another similar pair is used in the
customer LAN.
The routers of the HSRP group in
the service provider network are
connected over data links to routers
in the HSRP group in the customer
LAN.
Each group has only one active
router at a time.
The active router becomes inactive,
if the Ethernet port of that router
goes down or if the serial port
connected to the WAN goes down.
In this case, another router in that
HSRP group becomes active and
continues routing the traffic.
Serial
HSRP
Group
Virtually one router
Ethernet
Ethernet
Customer
Network
Figure 17. HSRP and a rapid converging routing protocol is used to
connect failover sites to the customer.
HSRP does not inform the other HSRP group of an event where the active router changes. If the Ethernet port
of an active router goes down and the active router in that group is changed, traffic from the other group is still
destined over the WAN to the previously active router. Therefore, a routing protocol is needed to cover the
return path.
48
DATA CENTER LAN
6.3.4 Distributed real-time mirrored SAN
For data to be available at the failover site, a distributed real-time mirrored SAN (storage area network) system
is recommended. SAN systems have the ability to hide physical disk structures from hosts and maintain
mirrored and distributed copies over several disks even in separate locations.
Such disks appear to the hosts as single logical disks and are mounted, for example, by SQL clusters at
failover.
6.3.5 Incoming call routing
In multi-site landscapes, gateways an SIP trunks are usually also distributed over the sites. The telephone
network considers the E1/T1/J1 line alive practically as long as the gateway is powered on and the line is
connected and intact regardless of the data connectivity between the service provider network and the
customer network or between the service provider sites.
For occasions when gateways on either site are not able to respond reasonably to incoming calls, for example,
no answer is sent from the gateway to the PSTN, an alternative destination is required the incoming calls. The
primary alternative destination would be respective gateways on the other site, but overflows could be defined
to any PSTN destination.
SIP OPTIONS PING can be used to determine if a particular SIP trunk is alive.
6.3.6 Arranging cluster and HAC nodes in each site
Running multi-site services requires configuring SAP Contact Center virtual unit instances to each site for
failover purposes. The configuration of a SAP Contact Center virtual unit is aware of only the IP addresses, not
the locations and thus, multi-site setups are equal to single-site setups in regard to the configuration of the SAP
Contact Center software.
Running multi-site services requires also for databases and file sharing services to be available at both sites.
This is achieved using Microsoft cluster services, SQL clusters and distributed real-time mirrored SANs.
49
CUSTOMER LAN
7 Customer LAN
The customer LAN refers to the LAN where the SAP Contact Center service is used. Different site topologies
are already covered in the section 1.6, Introduction to customer LAN. 100 Base-T and/or 1000 Base T
switched networks are recommended. There are two concerns related to the customer LAN:
-
Availability
-
Ability to carry quality voice
7.1 Availability
For the customer LAN availability, valid techniques are explained in:
-
Minimizing network distances is a network hygiene matter and is explained in
the section 6.1.1, Minimizing network distances
-
Ring topologies can be used to interconnect departments, floors and sites as explained in
the section 6.3.2, Connecting sites together
-
For sites in different subnets, HSRP in combination with a rapid-converging routing protocol
can be used as explained in
the section 6.3.3, Data connectivity and routing
7.2 Ability to carry voice
The ability of a 100 Base-T or 1000 Base-T switched LAN to carry quality voice depends on the path the voice
has to traverse on the LAN and the utilization and health of the LAN along that path. Utilization can be
measured using network analyzers and reviewing switch statistics.
If there is heavy utilization and especially if there are heavy load peaks, it is advisable to find out the cause of
the heavy utilization and/or the heavy peaks to verify that they are permissible and rational. When it is
confirmed and possibly counter-measured that there is no dispensable traffic, a utilization baseline has been
found. This baseline is used to recognize the available capacity for voice.
It should be observed that average utilization is not the whole truth about the ability to carry voice. A LAN with
very modest average utilization but frequent high load peaks may show totally unworthy of carrying voice. The
high load peaks may cause significant distortion to voice. A LAN carrying most of the calls perfectly well but at
the same time disrupting the voice a few times a day is not acceptable.
Prioritizing traffic is an efficient method to attach heavy load peaks in a LAN where the average utilization is
moderate.
7.2.1 Prioritizing traffic
Voice can be prioritized over other traffic in many ways. Common to all of these is that:
-
There are some means to identify and categorize traffic
-
Prioritization is done on queuing devices, such as switches
Voice traffic can be identified by the ToS bit set by SAP Contact Center or by constructing access lists on
routers or switches filtering traffic into categories based on, for example, sender and/or receiver IP address or
protocol. For configuration details see the documentation of the network device.
50
CUSTOMER LAN
Categorization
High Priority
High priority
queues are
emtied first
Port 1
input buffer
Eth
Port 2
input buffer
Medium Priority
Port x
output buffer
Eth
Low Priority
Port n
input buffer
Figure 18. Frame queuing.
Figure 18 shows the principal of queuing and prioritizing traffic. A received Ethernet frame is buffered in the
input buffer. The frame is analyzed to determine the category of it and moved to the buffer with respective
priority. Frames in higher priority buffers are transmitted before frames (depending on the prioritization
algorithm) in lower priority buffers. Frames in each buffer have no mutual priority, they are sent on a first-in firstout basis.
7.2.2 Verifying the LAN health
Switch statistics can be easily, and often very efficiently, used to verify the LAN health. Switch statistics usually
show:
-
Information about the utilization:
The number of bits and packets received and sent per each port.
-
Buffer overflows:
May indicate too heavy utilization, bad network topology or malfunctioning hardware.
-
Suspected speed and/or duplex mismatches:
Indicates configuration problems. Auto settings might not work properly or manual settings do
not match.
-
The number of collisions and late collisions:
May indicate too heavy utilization, malfunctioning hardware or bad network topology.
For details, see the documentation of the switch.
51
STORAGE SYSTEMS
8 Storage systems
Storage systems refer to the disks, disk arrays and SAN systems used for storing data. SAN systems use disk
arrays internally. Disk arrays provide better availability and sometimes also faster performance than single
disks. Faster performance is achieved especially in reading operations by reading several disks in parallel. SAN
systems are mostly based on high speed optical fiber connections providing better throughput than traditional
connections.
8.1 RAID arrays
RAID stands for redundant array of inexpensive disks and is a technology that employs simultaneous use of
two or more hard disk drives that appear as one logical drive in the operating system. There are various RAID
designs that all involve increased data availability or faster performance. Key RAID concepts are:
-
Mirroring
Mirroring involves copying data to more than one disk.
-
Striping
Striping involves splitting of data across more than one disk.
-
Error correction.
Error correction involves storing redundant data such as parity to enable problem detection
and possibly problem fixing.
The most interesting RAID designs or levels are:
-
RAID 1
All data is written to two identical disks, which allows for loss of one disk without data-loss.
-
RAID 5
Striped set with distributed parity allowing for loss of one disk without data-loss.
-
RAID 1+0 (or RAID 10).
Two or more mirrored sets are striped to provide a bigger disk allowing for loss of several disks
as long as no mirror set loses its both disks.
RAID 5
Logical
disks
A,B&C
RAID 1
Logical disk
Disk 1
A1
B1
C1
A2
B2
Cp
A3
Bp
C2
Ap
B3
C3
Disk 2
Disk 1 Disk 2 Disk 3 Disk 4
Figure 19. RAID 1
Figure 20. RAID 5 with 3 logical disks.
RAID 1 arrays are recommended to be used in SAP Contact Center application servers with local disks and for
the operating system in SQL clusters. RAID 5 arrays or RAID 1+0 arrays are recommended to be used as
database storage.
8.2 SAN systems
Storage area network (SAN) is an architecture for attaching remote computer storage devices such as disk
52
STORAGE SYSTEMS
arrays and tape libraries to servers in a way that they appear as local disks to the operating system. SAN usage
usually simplifies storage administration and adds flexibility since storage devices do not have to be physically
moved to move storage from one server to another. SAN also allows for booting from the storage devices.
It is recommended that SAP Contact Center application servers boot from SAN but that cluster servers, such as
Microsoft SQL clusters, have local disks for the operating system and that the databases are on the SAN.
SANs usually utilize a Fibre Channel fabric topology made up of Fibre Channel switches, where devices are
connected to each other through one or more Fibre Channel switches. Host bus adapters (HBA) are used
connect servers to Fiber Channel switches. Each server and storage is connected to two switches for fault
tolerance.
SAN
attached
servers
Fiber Channel
Switches
Storage 1
Storage 2
Figure 21. Fibre Channel switched fabric topology
Figure 21 shows storages 1 and 2 that reside at different sites. The figure contains cascaded switches for
illustration purposes. The shown topology could be run with two Fibre Channel switches.
Using manufacturer-specific SAN options, logical disks can be mirrored to different storages making data
available in real-time at different locations.
Snapshots can be used to preserve a copy of the data at the given moment. Benefits of snapshots are, for
example, separated partitions that can be analyzed without influencing the production environment and
establishing truly identical test environments.
9 Telephony and data connections
Data and telephony connections are used to connect the service center to the outside world. Data connections
are connected to the customers and telephony connections are connected to the PSTN. Both are covered
earlier in this document:
53
TELEPHONY AND DATA CONNECTIONS
-
Telephony connections are covered as follows:
1.4
Introduction to gateways and SIP trunks
1.8
Introduction to telephony and data connections
5
Gateways and SIP trunks
-
Overall topology and service and access links are covered as follows:
1.1
Introduction to site landscapes and connectivity
1.6
Introduction to customer LAN
6.6.3 Data connectivity and routing
9.1 Telephony connections
Public network and PBX interfaces, ITU-T G.703 RJ48 (120 ohm), are provided by the gateways. These
interfaces are connected to E1/T1/J1 lines or spans provided by an operator. These lines are Time Division
Multiplexed (TDM), for example an E1 line is divided into 32 channels of which channels 1 – 15 and 17 – 31 are
used for voice and 0 and 16 are used for synchronization and signaling. The signaling used is S ISDN.
Every 3.91 microseconds 8 bits from one channel is sent down the line followed by 8 bits from the next channel
during the next 3.91 microseconds, and so on, in a round-robin fashion throughout all the channels and thus, 32
channels are used once every 125 microseconds.
Service providers may consider preparing for coming demands by obtaining, for example, E3 or bigger trunks to
their sites in advance and having the telco splitting them into E1 lines at the site. One E3 trunk contains 16 E1
lines. The suggested arrangement helps maintaining the technical sanity and might speed up new deployments
as only configuration remains to be done when taking more lines in use.
Lines are taken in use by subscribing them. It is recommended that subscriptions are made by the customers
and that they are invoiced for the telephone traffic by the telco directly.
Subscriptions include a telephone number range. In most cases only numbers from this number range can be
shown as A numbers or calling party numbers.
1
2
3
1
2
3
1
2
3
15
15
15
17
17
17
31
31
31
0
1
2
3
15
16
17
31
0
1
2
3
15
16
17
31
1
2
3
1
2
3
1
2
3
15
15
15
17
17
17
31
31
31
Figure 22. E1 Time Division Multiplexing. Each timeslot is 3,91 microseconds.
Telco provided SIP trunks carry both the control protocol (SIP) and the audio (RTP). SIP trunks are nowadays
preferred over ISDN trunks in many cases.
9.2 Data connections
Data connections refer to service and access links. Service links are high bandwidth connections from a telco’s
network to the site(s) of a service provider. Service links provide similar preparedness on the data network side
as using E3 trunks does on the telephone network side. Similarly, service links provide better technical sanity,
cost efficiency and expedited deployment times because the access links only need to be physically installed.
Dimensioning of service links is straight-forward as the required bandwidth is the sum of the bandwidth of the
access links. Dimensioning of access links relies on:
54
TELEPHONY AND DATA CONNECTIONS
-
Maximum number of simultaneous calls
-
The codec G.711 or G.729
-
The packet periods, 10, 20, 30, 40 ms, and so on.
-
Estimated usage profile
The maximum number of simultaneous calls equals the number of (assuming all gateways are at the service
provider):
-
E1 lines x 30 or
-
T1 or J1 lines x 23
The codec G.711 creates a 64 kbit/s stream for a signal sampled at 8 kHz and G.729 creates an 8 kbit/s stream
correspondingly. This stream is the payload to be carried over the IP network. The stream is sliced into packets
of, for example, 20 ms of the stream. To be able deliver these packets, they are wrapped into RTP, UDP and IP
headers and finally, also in transport medium dependent headers. The choice of packet length is a trade-off
between latency and packet overhead.
20 ms of a G.711 stream is 64000 kbit/s x 0.02 s = 1280 bits -> 1280 bits / 8 = 160 octets.
20 ms of a G.729 stream is 8000 kbit/s x 0.02 s = 160 bits -> 160 bits / 8 = 20 octets.
It should be noticed that some gateways and/or IP desk phones accept only multiplies of 20 ms and therefore,
20 ms is a good default value.
As figure 23 shows, carrying RTP voice over Ethernet involves 78 octets overhead, Ethernet 38 octets and
IP/UDP/RTP 40 octets. The 38 octets are transmission-media dependent and apply to Ethernet only. HDLC
(High-Level Data link Control) and PPP (point-to-point protocol) are typically used, for example, on 2 Mbit/s
access links based on the SDH network. HDLCs overhead is 6 to 7 octets and PPPs overhead is 7 to 9 octets.
Ethernet Preample (8)
Ethernet Inter-Frame Gap (12)
Ethernet Header (14)
Ethernet CRC (4)
20 ms G.711 Payload (160)
IP, UDP & RTP Header (40)
Figure 23. Ethernet frame carrying G.711 over IP
The IP/UDP/RTP header can generally be thought of as a fixed overhead of 40 octets per packet, though on
point-to-point links RTP header compression can reduce this to 2 to 4 octets (RFC 2508).
Sending 20 ms voice in each Ethernet frame means that 50 frames are send each second. This gives total
bandwidth demand of:
-
50 times per second x (78 octets + 160 octets) x 8 = 95.2 kbit/s for G.711 over Ethernet
-
50 times per second x (78 octets + 20 octets) x 8 = 39.2 kbit/s for G.729 over Ethernet
-
50 times per second x (7 octets + 160 octets) x 8 = 66.8 kbit/s for G.711 over HDLC
-
50 times per second x (7 octets + 20 octets) x 8 = 10.8 kbit/s for G.729 over HDLC
-
50 times per second x (9 octets + 160 octets) x 8 = 67.6 kbit/s for G.711 over PPP
55
TELEPHONY AND DATA CONNECTIONS
-
50 times per second x (9 octets + 20 octets) x 8 = 11.6 kbit/s for G.729 over PPP
Certain codecs support silence suppression. Voice Activity Detection (VAD) suppresses the transmission of
data during silence periods. As only one person normally speaks at a time, this can reduce the demand for
bandwidth by as much as 50 percent. The receiving codec will normally generate comfort noise during the
silence periods.
The bandwidth requirement is full duplex.
As a conclusion, based on earlier experiences a good rule of thumb is that G.711 requires 80 kbit/s and G.729
requires 40 kbit/s per simultaneous call on a HDL or PPP link. This includes the voice stream, signaling
information and CDT user interface. This rule may not be applicable in inbound and outbound call center cases,
where calls are interleaved very little or not at all.
Capacity demands for other channels, such as e-mail, are estimated based on information received from the
customer, for example, average sizes and e-mail frequencies. This capacity is added on top of the capacity
calculated for telephony.
56
USER TERMINALS
10 User terminals
The SAP Contact Center user terminals are CDT, Convergence (SAP Contact Center soft phones) and IP desk
phones. CDT provides the broadest scale of functionality and is the primary user interface. IP desk phones are
usually used in negotiation rooms and other places where PCs are not available.
10.1 CDT and Convergence
CDT is a browser based phone including sophisticated functionality for call center agents. CDT requires
Microsoft Internet Explorer (IE). For required IE settings, refer to the user documentation of SAP Contact
Center. Convergence is a soft phone with more basic functionality. It is an alternative for users that don’t need
the full feature set of CDT.
USB handsets and headsets are used with CDT and Convergence. Headsets are also available as wireless.
Handsets may include keypads for dialing, volume control, mute, on-hook and off-hook functions. Headsets are
either monaural or binaural, that is, they come with one earpiece or with two earpieces.
USB devices are powered either via the USB bus or they have external power supplies. In cases where many
USB devices are used and/or high power USB devices are used, consider using external USB HUBs with
external power supplies. The current supplied by the USB bus is limited to maximum of 500 mA.
Supported and recommended hardware, operating systems and software can be found in the infrastructure
compatibility list (ICL) in the support portal.
10.2 IP Desk Phones
IP desk phones in SAP Contact Center are stand-alone phone devices connected to a SAP Contact Center
system over the Ethernet LAN. These phones run SIP and are configured to register to the SAP Contact Center
SIP Bridge.
The IP desk phone settings may be done manually using the keypad. The phones usually contain a web server
for administration and additional configurations can be done using a browser once mandatory IP settings are
effective, which are:
-
IP address
-
Subnet mask
-
Default router (in some cases)
Other important settings for IP desk phones are:
-
SIP registrar and proxy IP addresses
-
Subscription number
-
NTP (network time server) IP address
IP desk phones include usually configurable speed dial functions and downloadable telephone number
directories.
IP desk phones can also be configured automatically using DHCP (Dynamic Host Configuration Protocol) and
TFP (Trivial File Transfer Protocol).
57
USER TERMINALS
DHCP servers are assigned a pool of IP addresses from which they lease IP-addresses to hosts in reply to their
DHCP requests. The DHCP reply typically contains at least the following information:
-
IP address
-
Subnet mask
-
Default router
-
DNS (Domain Name System) IP address
The DHCP may be configured to provide, for example, the following additional information as well:
-
NTP server IP address
-
TFTP server IP address
Some IP desk phones are capable of retrieving and storing detailed configuration information from and to TFTP
servers. If configured to do so, an IP desk phone does the following when it boots:
-
Sends DHCP request (layer 2 broadcast)
-
Receives a DHCP reply
-
Activates the received mandatory IP settings
-
Requests for its configuration file (recognized by the MAC address) from the TFTP server
-
Configures itself according to the received settings
The behavior is manufacturer dependent in case the DHCP and/or TFTP requests fail. In some cases it is to
use to the previously active settings.
TFTP servers are also useful for making configuration backups even if the initial configuration is done in some
other way.
IP desk phones can be, in most cases, powered by external power supplies or by PoE (Power over Ethernet).
PoE requires the connected switch to support it or to arrange a separate PoE adapter between the switch and
the IP desk phone. PoE utilizes otherwise unused wires in CAT 5/6 LAN cables.
To power
supply
Unpowered
LAN cable
PoE
Adapter
Powered
LAN cable
Figure 24. Powering IP desk phones over Ethernet.
Supported and recommended hardware, operating systems and software can be found in the infrastructure
compatibility list (ICL) in the support portal.
58
SECURITY
11 Security
SAP Contact Center security relies on infrastructure security described earlier as follows:
-
1.5 Introduction to data center LAN introduces a layered network structure
-
1.10 Introduction to security introduces some security viewpoints
-
3.1 Physical security covers aspects of physical security
-
4.3.3 Certificates covers certificates
-
6.2.1 Access control covers the benefits of access control
11.1 Network traffic control
Network traffic control plays a crucial role in SAP Contact Center security. The layered network structure of a
data center forms three security zones. The layered structure is designed to allow only necessary traffic at each
level and to facilitate connections from higher security levels to lower security levels only between known
endpoints.
In the access network layer, where the customer is considered as a known endpoint, more granular
segmentation is advised by constructing VLANs for different customers. Routing between customers is not
recommended. If there is a demand to pass VoIP calls from a customer to another, it should be done via MRS.
Network traffic control is implemented with firewalls and access-lists on switches and routers and using VLANs.
For information needed to configure access lists, see the documentation of the SAP Contact Center ports and
protocols.
11.2 Identification, authentication and authorization
SAP Contact Center administrators and users are identified and authenticated with user IDs and passwords.
Connection servers are identified and authenticated with server certificates.
Partially authorized SAP Contact Center administrators are authorized by fully authorized SAP Contact Center
administrators.
SAP Contact Center users are authorized by SAP Contact Center administrators
11.3 Signed software modules
The essential SAP Contact Center software modules are signed with publisher ID certificates to indicate the
origin and the integrity of the modules.
11.4 Encrypted network traffic
The most vulnerable network connections can be encrypted.
59
AVAILABILITY AND MANAGEABILITY
12 Availability and manageability
The primary availability concept is implementing overall fault tolerance. Fault tolerance is achieved as follows:
-
Spanning tree, introduced in 6.3.2 Connecting sites together. This is applicable for in LANs
in general
-
NIC teaming, introduced in 6.2.3.2 Teaming
-
HSRP, introduced in 6.3.3 Data connectivity and routing
-
Multiple sites, introduced in 6.3 Multiple sites
-
Facility recommendations, introduced in 3 Environmental and facility recommendations
-
SQL and File server clusters, introduced in 4.3.1 Microsoft SQL Server
-
Server and hardware fault tolerance, introduced in 4.1.2.2 Server chassis and operability
-
SAP Contact Center HAC (high availability controller), explained below
12.1 SAP Contact Center HAC
HAC is the SAP Contact Center high availability controller installed on every SAP Contact Center server, also
referred to as a HAC node. HAC monitors the health of local services, typically each virtual unit, and
communicates it with other HAC nodes with a kind of a heart-beat protocol over the network.
For example, SAP Contact Center components for a particular service are installed on two or more HAC nodes
and configured with identical settings. One of these is active at any given time and referred to as the active
node or the active instance. The standby (spare) nodes remain inactive as long as they receive OK status
information from the active node. Failover nodes are prioritized primarily by the name of the instance element
and secondarily by the ID of the instance element. The failover entity is one or more virtual units.
HAC Node 2
HAC Node 3
VU_HAC
VU_HAC
VU_HAC
VU_CORE
VU_CORE
VU_CORE
Regular st
atus
notificatio
ns
HAC Node 1
s
tatu
ar s ons
l
u
Reg tificati
no
Figure 25. HAC nodes. The node 1 is active and the nodes 2 and 3 are prepared failover destinations.
HAC failover can also be initiated manually, for example, for the duration of maintenance tasks. HAC can also
be configured to notify the SAP Contact Center Alarm Server about its statuses.
60
AVAILABILITY AND MANAGEABILITY
12.2 SAP Contact Center Alarm Server
The Alarm Server retrieves status information from HAC nodes. The Alarm Server can be configured to forward
these alarms to configured destinations as:
-
E-mail messages
-
SMS messages
-
SNMP (simple network management protocol) traps
12.3 SNMP
SNMP (simple network management protocol) is part of the Internet Protocol Suite as defined by Internet
Engineering Task Force (IETF). SNMP is used in network management systems to monitor network attached
devices for conditions that warrant administrative attention.
Several SNMP management systems exist on the market and there is no particular preference of any of them.
Basically SNMP defines the following message types:
-
SNMP GET REQUEST
-
SNMP SET REQUEST
-
SNMP TRAP
SAP Contact Center sends only SNMP traps. SNMP GET and SET messages can be used for managing other
SAP Contact Center infrastructure devices supporting SNMP.
SNMP management systems typically include sophisticated functions, such as ability to:
-
Filter the most relevant messages
-
Send e-mail and SMS alerts initiated by events in the monitored system.
-
Log events for further investigation.
-
Export event data to files, sheets or syslog servers for reporting purposes.
61
AVAILABILITY AND MANAGEABILITY
Figure 26. SNMP network view.
Figure 27. SNMP SAP Contact Center servers view.
12.4 Miscellaneous
SAP Contact Center operators should consider stopping unnecessary Windows services to minimize server
and network utilization and vulnerability. Furthermore SAP Contact Center operators should consider stopping
the optimization of SQL Server performance. For more information see the documentation of Windows Server
and SQL Server.
SAP Contact Center Infrastructure Administrator (IA) an System Configurator (SC) are used to install and
configure SAP Contact Center components. For more information see the documentation of SAP Contact
Center.
62
DEPLOYMENT, SOFTWARE DISTRIBUTION AND CONFIGURATION
13 Deployment, software distribution and configuration
Deployment issues were introduced in 1.12 Deployment, software distribution and configuration and they
have also been discussed through this document. Deployment may be seen of as a twofold project. On the one
hand, it deals with SAP Contact Center functionality and parameter definitions, such as queues, prompts and
telephone numbering, but on the other hand, deals with technical infrastructure definitions and preparations.
Service providers may consider running different SAP Contact Center infrastructures with different service level
characteristics, such as 24/7 and 24/5. The implementation of each service agreement would be possible in a
SAP Contact Center infrastructure where the service level characteristics match or exceed the requirements in
the corresponding service level agreement.
This arrangement may clarify the urgency of administrative and operative alternation in case of incidents. This
arrangement also adds flexibility for maintenance windows during which routine maintenance tasks are
performed without explicit notifications.
13.1 Software distribution
Software components required by CDT are available as Windows Installer files and distributed and installed to
the client workstations either manually or by means of Microsoft SMS or Microsoft AD group policies. The firsttime installation requires authorization for installing software and is typically done with administrative user
rights. Subsequent updates can be performed automatically by SAP Contact Center and do not require
administrative intervention.
Figure 28. Windows Installer view of SAP Contact Center Terminal Setup.
The terminal.msi file contains all client-side software components but they are also available as separate
installation files. For example, added and/or updated support for headsets and handsets are provided as
terminal_HS_device.msi files, where device is the name of the device or its manufacturer.
63
SIZING
14 Sizing
Sizing is covered in this document as follows:
-
1.13 Introduction to sizing
-
2.3 Virtual units
-
4.1.1 The number of servers
-
4.1.2.3 Server specifications
-
4.2 Operating systems
-
4.3.1 Microsoft SQL Server
-
5 Gateways and SIP trunks (the sizing information is available in appendix A)
-
6 Data center LAN
-
6.1.2 LAN capacity
-
6.3 Multiple sites
-
7 Customer LAN
-
9 Telephony and data connections
-
Appendix A Sample SAP Contact Center servers
The basic principle is that SAP Contact Center is a modular system that scales up by adding components. that
is, components with high utilization can be multiplied to increase total capacity and to share the load between
several units.
Database server performance is increased by scaling up the hardware, such as disks, memory and CPU.
One CEM server is capable of handling at least 100000 calls per hour.
For other components, the following maximum limits are recommended:
-
HBR 1000 simultaneous calls
-
SBR 2000 simultaneous calls
-
MRS 800 simultaneous prompts or recordings or 1000 simultaneous NAT calls or SRTP calls
-
CS 500 simultaneous connections
64
INTEROPERABILITY WITH OTHER SYSTEMS
15 Interoperability with other systems
Interoperability with other systems, such as, Cisco Call Manager (CM) or Microsoft Lync is achieved at basic
call level by sharing gateway(s) between the systems and configuring respective call routing on the gateway(s)
similar to the configuration in chapter “Connecting to a PBX”.
LAN
Extensions
100 - 199
SAP CCtr
xxx100 –
xxx199
Extensions
200 - 299
Outgoing
calls
xxx100 –
xxx199
Microsoft
Lync
xxx200 xxx299
xxx200 xxx299
PSTN
Figure 29. SAP Contact Center and Microsoft Lync are using a common gateway.
Incoming calls are routed based on the dialed number to either SAP Contact Center or Microsoft Lync. A dial
peer is configured on the gateway (Cisco in this sample) for both SAP Contact Center and Microsoft Lync. Both
dial peers define a session target (the SAP Contact Center and Microsoft Lync SIP counterparts) with which the
control protocol is negotiated and a destination pattern that matches the dialed telephone numbers with either
of the systems. Outbound calls are routed on both systems to the gateway and by the gateway to the PSTN.
Extensions
100 - 199
SAP CCtr
100 - 199
LAN
200 - 299
Extensions
200 - 299
Microsoft
Lync
100 - 199
Figure 30. Calls between SAP Contact Center and Microsoft Lync routed via common gateway capacity.
Calls between SAP Contact Center and Microsoft Lync can be routed via the gateway. The drawback of this
configuration is that internal calls consume gateway capacity.
65
INTEROPERABILITY WITH OTHER SYSTEMS
An alternative way to route calls between SAP Contact Center and Microsoft Lync is to configure a SIP trunk
between them. The same is true for Cisco Call Manager.
Extensions
100 - 199
SAP CCtr
xxx100 –
xxx199
LAN
Extensions
200 - 299
100 - 199
200 - 299
Outgoing
calls
xxx100 –
xxx199
Microsoft
Lync
xxx200 xxx299
xxx200 xxx299
PSTN
Figure 31. Optimizing call paths.
66
GLOSSARY
16 Glossary
ABBREVIATION (TERM)
10Base-T
100Base-TX
1000Base-T
3G (third generation)
A number
Absence
ACD (automatic call distributor)
A/D, A/D conversion
ActiveX
Agent
AS (alarm server)
ASP (application service provider)
ATL, ATLTERMINAL
Attended transfer
Auto-allocation mode
Availability information
DESCRIPTION OR SYNONYM
Standards for Ethernet over twisted pair or copperbased computer networking physical connectivity
methods. The currently most widely used of these are
10BASE-T, 100BASE-TX, and 1000BASE-T running
at 10 Mbit/s, 100 Mbit/s and 1000 Mbit/s (1 Gbit/s)
respectively.
The level of development related to wireless
technologies. The preceding levels were 1G (included
analog standards such as FDMA and NMT), 2G
(included digital standards such as CDMA and GSM),
and 2.5G (included the packet-based GPRS
standard). The 3G standards include UMTS (based on
GSM) and WCDMA (based on CDMA).
The number where the call or message comes from
(i.e. the caller’s number or the source number).
A user is away or not available and cannot be
reached.
A module which manages inbound calls by using the
destination number.
Analog to digital conversion and vice versa
ActiveX is a component object model (COM)
developed by Microsoft for Windows platforms.
Software based on ActiveX technology is prevalent in
the form of Internet Explorer plugins and, more
commonly, in ActiveX controls, ActiveX based
applications launched from web pages
A user who handles queue calls and interacts with
customers. Usually related to contact centers.
A server receiving alarms from a HAC node and
distributing those alarms according to its rule sets.
An enterprise that provides other enterprises or
individuals remote access to application programs and
services over the Internet.
The core module required for the phone functions in
the Communication Desktop (CDT) application. This
ActiveX component is installed on a client workstation.
An active call is not transferred to another number
until you see whether it is answered or not. The call is
put on hold automatically, and you can release and
continue it if the other party does not answer.
Compare to the blind transfer method.
The call queue mode where you get automatically the
next inbound call from the queues you are currently
logged into (i.e. serving as an agent). Each call is
offered separately to the agents who are logged into
the queue. Compare to hunt group mode.
Indicates whether a user is absent or present. Related
to PRS profiles in the Communication Desktop (CDT)
application.
67
GLOSSARY
ABBREVIATION (TERM)
B number
Blind transfer
Bridge (H.323 or SIP)
C number
Campaign
CD (Call Dispatcher)
CDT (Communication Desktop)
CEM (Communication Event Manager)
CEM database
CD (call dispatcher)
Chat, chatting
ClientCom
Codec (coder/decoder)
Company
Contact
Contractor
CPM Administrator
CPM database
CS (connection server)
CTI (computer-telephony integration)
Customer
Customizer, customizing file
DB, db (database)
DHCP (dynamic host configuration protocol)
DESCRIPTION OR SYNONYM
The target of the call or message (i.e. the destination
number).
An active call is transferred to another number without
knowing whether the call is answered or not. Compare
to the attended transfer method.
A core module for connecting the registered terminal
devices and the gateways to the CD core module.
The target of the call which is forwarded from the B
number.
Defines the contents of the outbound call set (such as
the customers, scripts and special rules) in the
Outbound (OB) application.
The core module for low-level call handling.
An end user application related to enterprise
telephony systems and contact center operations.
The core module for top-level call handling.
The system database for call handling.
The core module for low-level call handling.
Real-time communication between users by using
computing devices.
The communication interface between the client-level
applications.
A module which combines analog-to-digital and digitalto-analog conversion.
An external customer or an internal employer in the
CPM database. Contacts are always linked to one or
more companies.
An external customer or an internal employee in the
CPM database. When internal user accounts are
transferred from the CEM database to the CPM
database, they are interpreted as contacts. Contacts
are always linked to one or more companies.
The party that uses the services of an outbound call
center to run its outbound campaigns. Used in the
Outbound (OB) application.
An administration application related to the CPM
database and predefined outbound call campaigns.
(Contact Process Manager)The system database for
managing customer information and activities (such as
tasks).
A SAP Contact Center module connecting terminals to
other SAP Contact Center components.
The use of computers for managing and making
telephone calls.
An external company or contact in the CPM database.
A text file in the CEM server which contains dedicated
customer-specific values.
A collection of information which is organized by using
predefined rules.
Dynamic Host Configuration Protocol (DHCP) is a
protocol used by networked devices (clients) to obtain
68
GLOSSARY
ABBREVIATION (TERM)
Dialer
Directory
DMZ (demilitarized area)
DTMF (dual tone multi-frequency)
DU (Data Universe)
E1, E1 line
EDGE (Enhanced Data rates for Global Evolution)
E-mail channel
ETC (external terminal controller)
External agent
G.711
G.729
GK (gatekeeper) (H.323 or SIP)
GMT/UTC (Greenwich Mean Time/Coordinated
Universal Time)
DESCRIPTION OR SYNONYM
various parameters necessary for the clients to
operate in an Internet Protocol (IP) network.
A module (such as the third-party Sytel Softdial dialer)
which controls the outbound call sequence, timing and
agent assignment in the Outbound (OB) application.
Either a CEM directory defined in the System
Administrator application, or a segment which is
displayed as a directory in the Communication
Desktop (CDT) application.
In computer security, a demilitarized zone, a
demarcation zone or perimeter network, is a physical
or logical subnetwork that contains and exposes an
organization's external services to a larger, untrusted
network, usually the Internet. The purpose of a DMZ is
to add an additional layer of security to an
organization's Local Area Network (LAN); an external
attacker only has access to equipment in the DMZ,
rather than the whole of the network.
The signals you generate by pressing the keypad of a
traditional phone.
The data warehouse and reporting software.
A single physical wire in telecommunications that can
be used to carry many simultaneous voice
conversations. It is widely used in almost all countries
outside USA, Canada and Japan. The line data rate
for E1 is 2.048 Mbit/s (full duplex) which is split into 32
time slots and can carry 30 simultaneous voice
conversions.
Also known as EGPRS. A packet switched radio
network for data transmission by mobile devices. A
successor of GPRS. Also considered a 2 or 2.5 G
(second generation) network.
The queue type which is used for receiving and
handling e-mail messages in the Task Manager (TM)
application.
ETC converts IP desk phone functionality by imitating
BCM soft phones and thus standardizes IP desk
phone features towards CEM.
A user who is logged into the software from an
external number (mobile or fixed). External agents
serve in queues remotely.
G.711 is an ITU-T standard for audio companding. It is
primarily used in telephony.
G.729 is an audio data compression algorithm for voice
that compresses voice audio in chunks of 10
milliseconds. G.729 is mostly used in Voice over IP
(VoIP) applications for its low bandwidth requirement.
Standard G.729 operates at 8 kbit/s.
A core module for registering the terminal devices to
the CD core module. A SIP gatekeeper is also called
registrar.
The standard time system used in the software. Times
in different time zones are calculated in relation to the
69
GLOSSARY
ABBREVIATION (TERM)
GPRS (General Packet Radio Service)
GUI (graphical user interface)
GW (gateway) (H.323 or SIP)
H.323, H323
HA (high availability)
HAC (High-Availability Controller)
HBA (host bus adapter)
HBR (H.323 bridge)
Hunt group mode
IA (Infrastructure Administrator)
ICL (infrastructure compatibility list)
IE ( internet explorer)
IIS (Internet Information Server)
iLO (integrated lights-out)
IM (instant message)
Inbound
IP (Internet Protocol)
IP phone
IP v4
ISDN Q.921
ISDN Q.931
DESCRIPTION OR SYNONYM
GMT time.
A packet switched radio network used for data
transmission by mobile devices. GPRS is a 2G
(second generation) network.
The graphical interface for human-computer
interaction (HCI). GUIs make it easier to use the
software applications, especially when compared to
command-based interfaces.
An external module for connecting the system to an
external network (usually to the PSTN network).
A standard protocol for audio, video, data, internet
phone, and VoIP transmissions.
A system or module which is operational for a required
time without uncontrolled interruptions.
An administration application related to the system
infrastructure.
Used in San systems to connect servers to storages.
The H.323 trunk interface in SAP Contact Center.
The call queue mode where you can select any
inbound call from the queues you are currently logged
into (i.e. serving as an agent). Each call is offered
simultaneously to all agents who are logged into the
queue. Compare to auto-allocation mode.
An administration application related to the system
infrastructure.
List of SAP Contact Center compatible devices
Windows Internet Explorer (formerly Microsoft Internet
Explorer abbreviated MSIE), commonly abbreviated to
IE, is a series of graphical web browsers developed by
Microsoft and included as part of the Microsoft
Windows line of operating systems starting in 1995.
A Microsoft server product which is used for various
web-related tasks, such as managing services and
sharing information.
Integrated Lights-Out (iLO) Standard combines basic
management functions and diagnostics with essential
Lights-Out functionality as standard components of the
server. Used by HP.
Short messages sent and delivered by using the
Communication Desktop (CDT) application.
Incoming (communication events).
The method and technology for sending data between
computers on the Internet.
A telephone based on IP technology.
Internet Protocol version 4 (IPv4) is the fourth iteration
of the Internet Protocol (IP) and it is the first version of
the protocol to be widely deployed.
ITU-T Recommendation Q.921, is the second layer
protocol on the ISDN protocol stack in the D channel.
ITU-T Recommendation Q.931 is ISDN's connection
control protocol. Q.931 is a layer 3 protocol, mainly
used for the ISDN call establishment, maintenance,
70
GLOSSARY
ABBREVIATION (TERM)
ISP
IVR (Interactive Voice Response)
J1, J1 line
LAN (local area network)
MAGENT
MCB (Mobile Connection Bridge)
MCTABUFF
MMS (multimedia messaging service)
Mobile phone
MPLS (multi protocol label switching)
MRS (Media Routing Server)
MsgCleaner
MsgToMail
MsgToSMS
MSI
MTD (Multi-terminal Desktop)
NAT (Network Address Translation)
DESCRIPTION OR SYNONYM
and release of network connections.
An Internet service provider is a company or business
that provides access to the Internet and related
services.
A system which supports interaction between the
caller and the system. For example, the caller may
hear a prerecorded prompt which instructs to enter
data with the phone keypad.
A single physical wire in telecommunications that can
be used to carry many simultaneous voice
conversations. It is used in Japan. A J1 line can carry
23 simultaneous voice conversions.
A group of computing devices which are used over a
shared data line within a limited geographical area.
The core module required for the messaging functions
in the Communication Desktop (CDT) application. This
ActiveX component is installed on a client workstation.
The core module for connecting the SPS terminal
devices and the server modules securely.
The core module required for ClientCom integrations
and the task management integration. This ActiveX
component is installed on a client workstation.
A method for delivering multimedia data to mobile
phones and other devices.
A cellular telephone, cell phone, or portable hand
phone.
In computer networking and telecommunications, Multi
Protocol Label Switching (MPLS) is a data-carrying
mechanism that belongs to the family of packetswitched networks.
The core module for playing prompt files. It also
converts the RTP stream into a WAV file when a caller
leaves a voicemail message.
The module cleaning old messages.
The module converting messages to e-mails.
The module converting messages to SMS messages.
The file format for Microsoft Windows Installer
packages. Usually data in installation packages is
compressed to decrease the size. The packages
make it easier to install software applications and
modules and to configure some initial settings during
the installation.
Functions for defining multiple terminal devices for
receiving inbound calls, and for selecting which one of
the devices is used when making outbound calls.
Used in the Communication Desktop (CDT)
application.
An IP address used in one network (the inside
network) is translated to a different IP address known
in another network (the outside network). Often
involves address mapping and firewall configuration to
71
GLOSSARY
ABBREVIATION (TERM)
OB (Outbound)
Operator
Outbound
PBX (private branch exchange)
PCM, 64 kbit/s PCM (pulse-code modulation)
PDA (personal digital assistant)
PDC (Predictive Dialing Controller)
Person
Phone for MS Office Outlook
PLMN (public land mobile net)
POP (point-of-presence)
Presence
Prompt
PRI (Primary rate interface)
PRS (Personal Reachability Services)
PRS profile
PSTN (public switched telephone network)
QoS (quality of service)
DESCRIPTION OR SYNONYM
improve security.
An end user application related to predefined
outbound call campaigns.
A user who acts as a switchboard operator.
Outgoing (communication events).
A traditional corporate telephone system which usually
includes switchboard hardware.
Pulse-code modulation (PCM) is a digital
representation of an analog signal where the
magnitude of the signal is sampled regularly at
uniform intervals, then quantized to a series of
symbols in a digital (usually binary) code. PCM has
been used in digital telephone systems and is also the
standard form for digital audio in computers.
A hand-held device for mobile computing.
A CEM module which runs the outbound campaigns in
the technical sense. Used in the Outbound (OB)
application.
An external individual in the CPM database. Persons
are not connected to companies and are usually
private persons.
An extension application which makes it possible to
use some phone and availability functions in the MS
Office Outlook application.
In telecommunication, a public land mobile network
(PLMN) is a network providing land mobile
telecommunications services to the public.
Access to PLMN services is achieved by means of an
air interface involving radio communications between
mobile phones or other wireless enabled user equipment
and land based radio transmitters or radio base stations
An internet access point which has a unique IP
address and provides an access to the rest of the
Internet.
A user is free and can be reached.
An audio message file in the WAV format.
The primary rate interface (PRI) is a
telecommunications standard for carrying multiple
DS0 voice and data transmissions between two
physical locations.
Functions related to profiles and availability
information. Used in the Communication Desktop
(CDT) application and Smartphone Suite (SPS)
application.
An absence, presence or conference profile which
defines how inbound calls are handled depending on
your availability.
The collection of interconnected public telephone
networks and systems.
In the field of computer networking and other packetswitched telecommunication networks, the traffic
engineering term quality of service (QoS) refers to
72
GLOSSARY
ABBREVIATION (TERM)
Queue routing
R number
RTP (Real-time Transport Protocol)
SAM (Service Availability Monitor)
SAN (storage area network)
SBR (SIP Bridge)
SBR (skill-based routing)
Segment
SIP (Session Initiation Protocol)
SMS (systems management server)
SMS (short message service)
SNMP (simple network management protocol)
SOAP (Simple Object Access Protocol)
SPS (Smartphone Suite)
DESCRIPTION OR SYNONYM
resource reservation control mechanisms.
The rules for offering calls to the agents who are
serving in the queues in the auto-allocation mode.
The term used for the original external source number
(the A number) in the following special case: the
system is configured to display the original number
even when the call has been forwarded within the
system before it is finally forwarded to another
external number. Normally the system displays the
personal extension number or the queue number as
the source number.
A standard protocol for audio, video, data, internet
phone, and VoIP transmissions.
A core module which monitors the state and
responsiveness of systems by simulating phone calls
and HTTP requests.
A Storage Area Network is an architecture to attach
remote computer storage devices such as disc arrays
to servers in such a way that, to the operating system,
the devices appear as locally attached.
A SAP Contact Center component acting as SIP
registrar towards SIP devices and performing protocol
translation from SIP to proprietary protocols towards
other SAP Contact Center components and vice
versa.
A queue routing method in the software. The software
offers calls to the agents who are most suitable to take
the call.
A target group which is created in the CPM database
and displayed as a directory in the Communication
Desktop (CDT) application. It contains persons,
contacts, and companies. Segments may be
company-wide (created in the CPM Administrator
application) or personal (created in the Task Manager
(TM) application).
A standard protocol for audio, video, data, internet
phone, and VoIP transmissions.
Microsoft Systems Management Server is a software
product for managing Windows computer systems
providing remote control, patch management, software
distribution, and hardware and software inventory.
A method for delivering short messages to mobile
phones.
SNMP protocol forms part of the internet protocol suite
as defined by the Internet Engineering Task Force
(IETF) and is used in network management systems
to monitor network-attached devices for conditions
that warrant administrative attention.
The method which allows to exchange data between
applications running on different platforms.
An end user application related to mobile usage.
73
GLOSSARY
ABBREVIATION (TERM)
SQL (Structured Query Language)
Superior-assistant
Switchboard
System Administrator
T1, T1 line
TAPI (Telephony Application Programming Interface)
Task Manager Extension for MS Office Outlook
TCP/IP (Transmission Control Protocol/Internet
Protocol)
Telco
TFTP (trivial file transfer protocol)
TM (Task Manager)
User Administrator
VLAN (virtual LAN)
Voicemail
VoIP (Voice over IP)
VPN (virtual private network)
VU (virtual unit)
VUA (virtual unit administrator)
VUMU (Virtual Unit Management Utility)
WC (WebClient)
WLAN (wireless local area network)
DESCRIPTION OR SYNONYM
A programming language used for database queries
and updates. May also refer to a database server or
program.
Roles related to special queue functions (previously
called boss-secretary).
Traditionally hardware (a telephone routing table) for
routing calls and connecting calls to other users.
An administration application related to the system
data and configuration.
A single physical wire in telecommunications that can
be used to carry many simultaneous voice
conversations. It is widely used in USA and Canada.
The line data rate for T1 is 1.544 Mbit/s which is split
into time slots so a T1 line can carry 23 simultaneous
voice conversions.
A programming interface which allows to make
telephone and video calls by using computers.
An extension application which makes it possible to
create tasks manually from e-mail messages.
A method and language for sending data between
computers on the Internet.
Telco is a generic term for telephone companies
Trivial File Transfer Protocol (TFTP) is a very simple
file transfer protocol, with the functionality of a very
basic form of FTP
An end user application related to task management.
It is also used for creating and maintaining customer
data and your personal segments.
An administration application related to the user
accounts.
Virtual LAN, commonly known as a VLAN, is a group
of hosts with a common set of requirements that
communicate as if they were attached to the same
wire, regardless of their physical location.
Traditionally a telephone answering service where
callers can leave messages into a voicemail box. Also
an application and functions in the Communication
Desktop (CDT) application.
A method and technology for transferring voice by
using an IP-based data network.
A method for offering remote users secure access to a
network.
A group of technical services that are managed as a
single unit. Related to the system infrastructure.
Tool for installing, upgrading and removing BCM
software.
An administration application related to the system
infrastructure.
A software object acting as an interface between an
user interface and a database.
A group of computing devices which are used over a
74
GLOSSARY
ABBREVIATION (TERM)
WVP
DESCRIPTION OR SYNONYM
wireless link within a limited geographical area.
The core module required for the video call function in
the Communication Desktop (CDT) application. This
ActiveX component is installed on a client workstation.
75
APPENDIX A: SAMPLE SAP CONTACT CENTER SERVERS
17 Appendix A: Sample SAP Contact Center Servers
17.1 Basic service provider setup using Windows Server 2008
The setup contains the following servers:
- 1 SQL Server Cluster
-
2 SAP CCtr Application servers (+ 1 as Connection Server in DMZ if CMC is used)
-
1 SAP CCtr Reporting Server
SQL Server:
-
x86 cluster server with 1 or more CPUs
-
16 GB or more RAM
-
2 or more 100/1000 Base-T Ethernet ports per node
-
Redundant (e.g. RAID 1 (2x15K drives)) 73 GB or more disk space for op.sys and
applications per node
-
Redundant (e.g. RAID 5 or 1+0 (15K hot pluggable drives)) 1 TB or more disk space for
databases
-
Redundant Power Supply
-
Redundant ventilators
-
Windows Server 2008 64-bit Enterprise edition (English recommended)
-
SQL Server 2008 Standard 64-bit (English)
SAP Contact Center Reporting (SQL) server:
x86 server with 1 or more CPUs
-
8 GB or more RAM
-
1 or more 100/1000 Base-T Ethernet ports per node
-
Redundant (e.g. RAID 1 (2x15K drives)) 73 GB or more disk space for op.sys and
applications
-
Redundant (e.g. RAID 5 or 1+0 (15K hot pluggable drives)) 146 GB or more disk space for
databases
-
Redundant Power Supply
-
Windows Server 2008 64-bit Standard edition (English recommended)
-
SQL Server 2008 Standard 64-bit (English)
SAP Contact Center Application servers:
x86 server with 1 or more CPUs
-
4 GB or more RAM
-
2 100/1000 Base-T Ethernet ports per node
-
Redundant (e.g. RAID 1 (2x15K drives)) 73 GB or more disk space
-
Redundant Power Supply
-
Windows
Server
2008
64-bit
Standard
edition
(English
recommended)
76
APPENDIX A: SAMPLE SAP CONTACT CENTER SERVERS
17.2 Service provider setup with SAN using Windows Server 2008
The setup contains the following servers:
- 1 SQL Server Cluster (Can serve several SAP CCtr systems)
-
2 or more SAP CCtr Application servers (1 in core and 1 in access NW)
2 or more SAP CCtr failover Application servers (1 per NW, each can backup several
application servers but usually only 1 at a time)
-
1 SAP CCtr Reporting Server
-
1 SAP CCtr Application server as Connection Server in the DMZ, if CMC is used (optional)
-
1 SAP CCtr Application server as Management server. (Can serve several SAP CCtr systems)
SQL Server: (SQL cluster is made of two or more of these)
x86 server with 1 or more CPUs
-
16 GB or more RAM
-
2 or more 100/1000 Base-T Ethernet ports per node
-
Redundant (e.g. RAID 1 (2x15K drives)) 73 GB or more disk space for op.sys and
applications per node
-
1 or more HBA (host bus adapter) for SAN connection and database storage
-
Redundant Power Supply
-
Redundant ventilators
-
Windows Server 2008 64-bit Enterprise edition (English recommended)
-
SQL Server 2008 Standard 64-bit (English)
SAP Contact Center Reporting (SQL) server:
x86 server with 1 or more CPUs
-
8 GB or more RAM
-
1 or more 100/1000 Base-T Ethernet ports per node
-
Redundant (e.g. RAID 1 (2x15K drives)) 73 GB or more disk space for op.sys and
applications
-
1 or more HBA (host bus adapter) for SAN connection and database storage
-
Redundant Power Supply
-
Windows Server 2008 64-bit Standard edition (English recommended)
-
SQL Server 2008 Standard 64-bit (English)
SAP Contact Center Application servers:
x86 server with 1 or more CPUs
-
4 GB or more RAM
-
2 100/1000 Base-T Ethernet ports per node
-
Redundant (e.g. RAID 1 (2x15K drives)) 73 GB or more disk space
-
Redundant Power Supply
-
Windows Server 2008 64-bit Standard edition (English recommended)
77