Overview
The Connects for SAP integrates the SAP CRM application with Cisco Unified Contact Center Enterprise (CCE) or Cisco Unified Contact Center Hosted (CCH) and provides several media channels like voice, action item and chat.
Connects for SAP is the umbrella term of the SAP CRM to CCE/CCH interoperability solution. It consists of the four following components:
b+s CRM Connector for SAP (CRMConnectorSAP)
CRMConnectorSAP is a software component which connects CCE/CCH with the SAP CRM server through the SAP ICI.
b+s MediaManager (MediaManager)
MediaManager is a software component which allows CRMConnectorSAP to connect to the CCE/CCH media routing interfaces ARM and MRI.
b+s ChatConnector (ChatConnector)
ChatConnector is a software component which connects the MediaManager component to a Jabber server using the eXtensible Messaging and Presence Protocol (XMPP).
b+s DataStore (DataStore)
DataStore is a software component which allows the CRMConnectorSAP to temporarily store large amounts of attached data that do not fit into CCE/CCH call variables.
b+s CRM Connector Outbound for SAP (CRMConnectorOutboundSAP)
CRMConnectorOutboundSAP is a software component which enables the transmission of call lists from SAP CRM to CCE/CCH trough the SAPphone (RFC) interface for automatic dialing.
Architecture
The CRMConnectorSAP connects to the ctisvr process on the CCE/CCH Peripheral Gateway (PG) using the CTI Protocol and to the SAP server using the ICI interface.
The ICI interface is based on SOAP as modern, web service oriented interface technology and it is designed to support the integration of SAP components with non-SAP single communication type products (e.g. CTI products) as well as multiple communication type products (e.g. CTI, messaging and chat). In particular, the ICI interface is designed to support the integration of multichannel management systems (“Contact Centers”) with the SAP CRM Interaction Center WebClient (ICWC). The version of the ICI interface supported by a SAP system depends on the release of the SAP Web-Application Server (WAS) and its patch level. Please note that for every customer the ICI interface version must be verified with the SAP consultant during the pre-sales phase.
The action item channel requires the CRMConnectorSAP to connect to the MediaManager service. This is a b+s application used in multimedia integration projects to connect the CCE/CCH media routing interfaces ARM and MRI. The ARM connection is terminated on the same CTI Server that is already connected by the CRMConnectorSAP for the voice channel. The MRI connection from the MediaManager application to the CCE/CCH platform is terminated on the Media Routing Peripheral Gateway (MR PG).
The chat channel also requires the CRMConnectorSAP to connect the MediaManager service. For chat integrations an additional ChatConnector service is required to connect the MediaManager application to the 3rd party Jabber server using the XMPP protocol.
In case of transfer or conference calls between agents which are located on different peripherals, SAP call attached data will be synchronized between the involved agents. If such transfers between separate peripherals are needed, a central DataStore pair must be installed.
For transmitting a list of planned calls from the SAP system to CCE/CCH, the Connects for SAP component CRMConnectorOutboundSAP must be deployed. It registers itself on the SAP system by using the SAPphone (RFC) interface, receives call lists from the SAP system and exports them into CSV files. The Cisco Outbound Option imports these call lists and uses them for outbound call campaigns.
In a single CCE/CCH peripheral deployment all SAP agents are configured on the same CCE/CCH peripheral. One CRMConnectorSAP is installed and connects CCE/CCH PG A/B. A second CRMConnectorSAP must be installed on a second server for redundancy between the CRMConnectorSAP and the CCE/CCH PG, but SAP does not support automated failover to a second CRMConnectorSAP. This means, that if the connection between SAP and the active CRMConnectorSAP fails, the switchover to the other CRMConnectorSAP has to be executed manually on the SAP system. For automatic failover a web proxy must be placed between the SAP system and two CRMConnectorSAP instances.
Deployment Models
The modular architecture of the Connects for SAP solution offers a wide variety of deployment models. Each deployment model has its pros and cons regarding redundancy, complexity, management, costs etc. In theory, all components of the Connects for SAP can be installed on one single host or each component can have its own separate host.
This chapter describes the deployment models of the Connects for SAP solution recommended by Bucher + Suter AG.
Service State Definitions
ACTIVE means that the particular service is started and ACTIVE (i.e. the application is processing requests)
INACTIVE means that the particular service is started and its overall state is ACTIVE but…
- … as SAP communicates with one single CRMConnectorSAP service at a time, the second CRMConnectorSAP service is started but INACTIVE. Refer to the chapter SAP ICI Redundancy for more information
- …even if two CRMConnectorOutboundSAP services are deployed and both have an active RFC-connection to SAP ,it is up to the administrator of an outbound campaign to select the desired dialer-entry for transferring the call-list to one of the two CRMConnectorOutboundSAP services. Refer to the chapter SAP ICI Redundancy for more information
IDLE means that the particular service is started but IDLE. If the ACTIVE service fails (in this case the CCE/CCH PG A), the IDLE service takes over and becomes ACTIVE
STOPPED means that the particular service is stopped
Single Peripheral Gateway (PG)
The CRMConnectorSAP instances are installed standalone on separate hosts. If media channels are configured, MediaManager and ChatConnector can be installed on the same hosts as the two CRMConnectorSAP instances or on its own hosts. Once multiple CRMConnectorSAPs are deployed, a central DataStore pair is required to buffer SAP attached data. The DataStores can be deployed separately or together with the other Connects for SAP components. Two CRMConnectorOutboundSAP instances can be deployed on separate hosts if automated outbound dialing is conducted.
Multiple Peripheral Gateways (PG)
The CRMConnectorSAP instances are installed standalone on separate hosts. If media channels are configured, MediaManager and ChatConnector can be installed on the same hosts as the two CRMConnectorSAP instances or on its own hosts. Once multiple CRMConnectorSAPs are deployed, a central DataStore pair is required to buffer SAP attached data. The DataStores can be deployed separately or together with the other Connects for SAP components. For multi-PG deployments it is assumed that two separate MR PGs and CCE/CCH PGs are deployed. Two CRMConnectorOutboundSAP instances can be deployed per PG if automated outbound dialing is conducted.
Multiple SAP CRM
With the Connects for SAP integration, multiple SAP CRM instances can be connected simultaneously. The following graphic illustrates an architectural overview with the Connects for SAP connector with two separate SAP CRM instances.
Limitation may apply. Among other configuration, all agents must be registered on the same Protocol Independent Multicast (PIM). Additionally, if SetAttachedData are being send from one SAP CRM instance to the other SAP CRM instance via the Connects for SAP connector, both SAP CRM instances have to be capable to handle those AttachedData identically.
Host System Requirements
The Connects for SAP can be deployed on an operating system that runs either directly on the server hardware or on a bare-metal virtualization solution.
General Host System Classification
b+s classifies host systems for its software solutions regardless of whether they are deployed on a virtualized or non-virtualized operating system as followed:
| Host System Class | CPU Sockets | CPU Cores | RAM | Disk Space |
|---|---|---|---|---|
| Small | 1 | 2 | 4GB | 40GB System Partition, 80GB Data Partition |
| Medium | 1 | 4 | 4GB | 40GB System Partition, 80GB Data Partition |
| Large | 2 | 4 | 8GB | 40GB System Partition, 80GB Data Partition |
General Virtualization Requirements
b+s provides predefined OVA-Templates for all host system classes listed in the table above. The templates contain essential hardware specifications which are required for a quick deployment of a virtualized host system (e.g. number of CPU sockets, number of CPU cores, memory size etc.). Be aware that additional configuration options like network adapter settings will still have to be configured manually by a system administrator. The same applies for the installation and configuration of the host system’s operating system.
If b+s software is deployed on a virtualized Windows Server operating system, the following restrictions apply:
Only VMware ESXi bare-metal virtualization (type 1 hypervisor) software is supported
For co-residency of b+s software components with Cisco Unified Communications (UC) software refer to the official Cisco co-residency policy which is accessible from: Virtualization for Unified Contact Center Enterprise or Virtualization for Packaged Contact Center Enterprise
General Cisco UC virtualization guidelines which can be accessed through: Collaboration Virtualization Sizing
In case of a non-co-resident deployment of Cisco UC and b+s software, it is permissible to deploy 3rd party software on a separate VMware instance on the same server (blade server or normal rack server) as long as the VMware instance where b+s software is installed receives the required hardware resources from the host system at all times.
3rd Party Host System Requirements
For third-party host system requirements for all involved Cisco components as well as information regarding hard- and software requirements of CCE/CCH, refer to the Compatibility Information from Cisco.
Capacity and Redundancy
CRMConnectorSAP
The CRMConnectorSAP component can be deployed on two servers to achieve warm- standby redundancy. However, the SAP system currently supports the configuration of a single CRMConnectorSAP only. Even if multiple CRMConnectorSAPs are available, there is no automated mechanism that will try to connect another CRMConnectorSAP if the active one fails or if a connection attempt fails. For automatic failover behavior a web proxy can be placed between the SAP system and the CRMConnectorSAP. This web proxy has to handle the failover from one CRMConnectorSAP to the other. Refer to the chapter SAP ICI Redundancy for more information.
MediaManager
The MediaManager component can be deployed on two servers to achieve hot-standby redundancy. One MediaManager is started and active, the second is started and idle. On the MR PG, both MediaManagers are configured. If the active MediaManager fails, the idle MediaManager takes over automatically.
ChatConnector
The ChatConnector component can be deployed on two servers to achieve cold- standby redundancy. One ChatConnector is started and active, the second is stopped and inactive. Both ChatConnectors have the same configuration (connection to one MediaManager and one Jabber server). If the active ChatConnector fails, the inactive ChatConnector has to be pointed to the correct MediaManager and Jabber server (check configuration) and started manually.
DataStore
The DataStore component can be deployed on two servers to achieve hot-standby redundancy. The CRMConnectorSAP (or multiple if deployed) connects to both DataStores, A and B. If one DataStore fails, the second takes over immediately.
CRMConnectorOutboundSAP
The CRMConnectorOutboundSAP component can be deployed on two servers to achieve warm-standby redundancy respectively to distribute the call-lists from SAP to two independent CRMConnectorOutboundSAP services. In such a deployment, each CRMConnectorOutboundSAP has its own RFC-connection to SAP. It is up to the administrator of an outbound campaign to select the desired dialer-entry for transferring the call-list to one of the two CRMConnectorOutboundSAP services.
There is no automated mechanism in SAP that will try to connect another CRMConnectorOutboundSAP service if the connected one fails or if a connection attempt fails. For each deployed CRMConnectorOutboundSAP service a separate Import Rule must be configured in CCE Outbound Option.
Further Redundancy and Recovery Considerations
At startup or after a CTI Server failover the CRMConnectorSAP and the MediaManager try to connect to the side A ctisvr process. If that connection fails they will try side B instead. If both sides cannot be connected, they will keep retrying alternatively between both sides. In case of a CTI Server failover the active CRMConnectorSAP and MediaManager will lose their connection and try to re-establish it again. The agent and call states are recovered from the re-connected CTI Server side. The MR PG connects to the MediaManager application from side A at startup. If side A cannot connect to the MediaManager then side B is activated. If that fails too then both sides alternately try to establish a connection until one is successful.
Queued action item route requests will be recovered if a restart or failover of the CRMConnectorSAP occurs. However, there may appear restart or failover situations where single pending route requests might not be fully recovered. If multiple CRMConnectorSAP are deployed and a restart of the active CRMConnectorSAP occurs, pending route requests are recovered when the CRMConnectorSAP service starts up again. The starting CRMConnectorSAP recovers the pending route requests from its recovery files and forwards the requests to the MediaManager. The starting CRMConnectorSAP notifies MediaManager about all recovered route requests before he goes into inactive state (inactive means that the CRMConnectorSAP service is started and its overall state is active. However, as SAP communicates with one single CRMConnectorSAP service at a time, the other CRMConnectorSAP service is actually started but inactive). The CRMConnectorSAP service which took over when the previous active CRMConnectorSAP restarted will be notified by the MediaManager about the recovered route requests and forward them to the selected agents. Be aware that for an automatic recovery of route requests in a deployment where multiple CRMConnectorSAP are deployed a pair of central DataStores is required. With such a deployment there is no need to copy recovery files manually from one CRMConnectorSAP to another.
Queued action item route requests will be recovered if a restart of the MediaManager occurs. However, there may appear restart or failover situations where single pending route requests might not be fully recovered.
In case of a MediaManager restart, a broken ChatConnector connection or MR PG failover, all chat sessions currently in CCE/CCH queues are de-queued and cannot be recovered. All active chat sessions to SAP agents are terminated and the SAP ICWC is notified.
In case of a CRMConnectorSAP restart, failover or a broken connection to the SAP Server, all agents will be logged off and will have to log back in manually. Chat sessions currently in the CCE/CCH queue are not affected. Any active chat sessions with any SAP agent involved are rerouted by MediaManager to the CCE/CCH routing script and queued until an SAP agent is available again.
SAP RFC Redundancy
As mentioned earlier two CRMConnectorOutboundSAP services can be deployed to distribute the call-list from SAP to the Connects for SAP based on the dialer-entry selected by the administrator of a campaign using independent RFC-connections.
After receiving a call-list from SAP each of the CRMConnectorOutboundSAP services exports the call-list entries into a CSV-file and stores it in the configured directory. From there, the Import Rule of the CCE/CCH Outbound Option imports the call list and stores it into the Outbound Option database. Redundancy can be achieved by creating an Import Rule for each CRMConnectorOutboundSAP service and assigning it via a Query Rule to the same Outbound Campaign as the following schema depicts.
SAP ICI Redundancy
Since SAP supports the configuration of a single Communication Management Software (CMS) destination only, it is necessary to place a web proxy between the SAP CRM system and multiple CRMConnectorSAP services for an automated failover of the ICI interface communication. The deployment of a web proxy eliminates the need for a manual configuration change of the CMS destination by a system administrator.
Because SAP ICI is designed as a web service, there is no persistent client-server-connection between the SAP system and the CRMConnectorSAP service. For each request a new connection is established, and each request has to be routed to the same CRMConnectorSAP service as the previous one.
The web proxy solution which is installed between the SAP system and the CRMConnectorSAP services has to meet the following requirements:
- The status of the CRMConnectorSAP services has to be monitored so that the proxy is able to determine which CRMConnectorSAP service should receive a request from the SAP system and which not. This can be accomplished by either detecting connection failures or by using periodical heartbeats. A heartbeat solution is preferred because it ensures a prompt detection of a connection loss. For this purpose the health check page of the CRMConnectorSAP service can be queried with a HTTP GET request (refer to Troubleshooting instructions for more information about the CRMConnectorSAP health check page).
- A sticky session mechanism is required which ensures that all requests for all agents are routed to the same CRMConnectorSAP service. In fact, the web proxy must not switch back to a failed CRMConnectorSAP service if it becomes available again. This is necessary because only one CRMConnectorSAP at a time knows the status of a monitored agent.
- The web proxy solution must not be installed on the same server as the Connects for SAP components (CRMConnectorSAP, MediaManager, DataStore, ChatConnector, CRMConnectorOutboundSAP).
Agents always have to re-login if a failover of a CRMConnectorSAP service occurred. Refer to the Proxy-Guide for more detailed information.
Product Deployment and Scalability Considerations
The following tables shows which host system class is suited for which deployment of the Connects for SAP:
| Host System Class | Max Number of Concurrent Agents | Comments |
|---|---|---|
| Voice | ||
| Medium | 1000 | For normal productive deployments (30 Calls/Agent/Hour) |
| Action Item | ||
| Medium | 1000 | For normal productive deployments (30 Action-Items/Agent/Hour) |
| Voice and Action Item | ||
| Medium | 750 | For normal productive deployments (15 Calls/Agent/Hour, 10 Action-Items/Agent/Hour) |
| Voice and Action Item (SAP ICI SSL) | ||
| Medium | 400 | For normal productive deployments (15 Calls/Agent/Hour, 10 Action-Items/Agent/Hour) |
| Voice and Chat | ||
| Medium | 500 | For normal productive deployments (15 Calls/Agent/Hour, 10 Chats/Agent/Hour) |
| Voice, Action Item and Chat | ||
| Medium | 500 | For normal productive deployments (15 Calls/Agent/Hour, 5 Action-Items/Agent/Hour, 10 Chats/Agent/Hour) |
The host system class Small” can only be used to deploy Connects for SAP in a non-production environment. The numbers above only apply if Connects for SAP is deployed with CCE/CCH.
For scalability limitations specific to Cisco Packaged Contact Center Enterprise (PCCE) please refer to PCCE specifics
The dimensioning guidelines above were tested in a lab testing environment that included a test SAP CRM system setup and an equivalent SAP CRM simulator. Actual quality of service (delays, responsiveness, etc.) experienced by the agents might vary from the above dimensioning guidelines. These variations include structure and size of the SAP CRM database, overall level of the SAP CRM tuning, chat message payload, transferred SAP attached data, intensity of the contact processing workflow(s), as well as other SAP CRM configuration and topology variables outside of the scope of the Connects for SAP. Bucher +Suter highly recommends an in-house load test to make sure that the total quality of service under load is satisfactory.
Mobile Agent Capacity
Use the following calculations to determine mobile agent capacity:
Each mobile agent for a nailed connection (nailed-up configuration) equals 1.73 local agents.
Each mobile agent for a call-by-call basis equals 2.4 local agents.
Presence
SAP Agent Presence enables the reporting of an agent’s presence status in SAP ICWC. With this functionality an agent can easily check the availability of another agent to see if he is free to receive a call, busy or logged out. Using this feature can negatively affect the Connects for SAP’s performance.
The Connects for SAP can process a maximum of 5 presence request simultaneously. A presence request happens when SAP requests agent state information from the Connects for SAP. These requests can be triggered when an agent checks the status of other agents or SAP requests this data automatically based on a variety of events. Presence requests sent from SAP to Connects for SAP are typically answered within milliseconds, however the response time depends on the complexity of the requested presence information and the number of logged in agents. Actual quality of service (delays, responsiveness etc.) experienced by the agents depends on performance factors that vary from contact center to contact center. Bucher + Suter highly recommends that contact center providers perform a load test to ensure that the SAP Agent Presence feature’s quality of service is satisfactory.
Refer to the latest Connects for SAP Installation and Configuration Guide [2] for more information.
Network Requirements
Bandwidth
SAP ICI – Voice Only
Assumptions for Voice:
200 agents
30 calls/agent/hour
2 presence-requests/agent/hour
2kB average SAP attached data
Call mixture: 85% straight calls, 10% consultation transfer calls, 5% call conferences
200 agents x 30 calls = 6000 calls/hour (5100 straight calls, 600 consultation transfer calls, 300 conference calls)
200 agents x 2 presence requests = 400 presence-requests/hour
Calculation:
200 agent logins: 200 x 30kB = 6MB
5100 straight calls: 5100 x 5kB = 25.5MB
600 consultation transfer calls: 600 x 45kB = 27MB
300 conference calls: 300 x 45kB = 13.5MB
400 presence requests: 400 x 200kB = 80MB
Average data transfer/hour= 152MB
Average data transfer/sec = 42.2kB/s (without safety coefficient)
Safety coefficient = 2
Average data transfer/sec = 84.4kB/sec = 675.6kbits/sec
Average required bandwidth/agent = 0.4kB/sec = 3.4kbits/sec
Based on the calculation example above, the Connects for SAP, or more precisely the CRMConnectorSAP service, requires a minimum bandwidth of 3.4kbits/agent/sec for voice only.
SAP ICI – Voice and Action Item
Assumptions for Voice and Action Item:
200 agents
15 calls/agent/hour
10 action-items/agent/hour
2 presence-requests/agent/hour
2kB average SAP attached data
Call mixture: 85% straight calls, 10% consultation transfer calls, 5% call conferences
No action item transfers
200 agents x 15 calls = 3000 calls/hour (2550 straight calls, 300 consultation transfer calls, 150 conference calls)
200 agents x 10 action items = 2000 action-items/hour
200 agents x 2 presence requests = 400 presence-requests/hour
Calculation:
200 agent logins: 200 x 30kB = 6MB
2550 straight calls: 2550 x 5kB = 12.75MB
300 consultation transfer calls: 300 x 45kB = 13.5MB
150 conference calls: 150 x 45kB = 6.75MB
2000 action items: 2000 x 5kB = 10MB
400 presence requests: 400 x 200kB = 80MB
Average data transfer/hour= 129MB
Average data transfer/sec = 35.8kB/s (without safety coefficient)
Safety coefficient = 2
Average data transfer/sec = 71.7kB/sec = 573.3kbits/sec
Average required bandwidth/agent = 0.36kB/sec = 2.89kbits/sec
Based on the calculation example above, the Connects for SAP, or more precisely the CRMConnectorSAP-service, requires a minimum bandwidth of 2.89kbits/agent/sec for voice and action item.
SAP ICI - Chat
The chat channel differs from the voice and action item channel since in addition to the SOAP-messages the payload of the media is also passed between SAP and the CRMConnectorSAP.
As the required bandwidth of the chat channel depends heavily on the size and quantity of transmitted chat messages, it is not feasible to specify a precise bandwidth consumption calculation without having more detailed information from the environment where the Connects for SAP is deployed.
Important Considerations
Actual bandwidth requirements might vary from the above dimensioning guidelines. These variations include:
Number of concurrent agents
Quantity of consultation transfer and conference calls (85% straight calls, 10% consultation transfer calls, 5% conference calls reflects a common contact center environment)
Quantity of routed action items
Quantity and size of chat messages
Size of transferred SAP attached data
Intensity of the contact processing workflows
Intensity of SAP Agent Presence use
Bucher +Suter highly recommends an in-house load test to make sure that the total quality of service under load is satisfactory.
The calculated bandwidth listed above reflects the requirements for the communication between the SAP system and the CRMConnectorSAP-service only (SOAP-messaging). It does not consider possible bandwidth consumption for the voice stream, action item (e-mails, faxes, tickets etc.) payload or for SAP agent front-end activities.
Latency
SAP CRM – CRMConnectorSAP (ICI)
Since ICI is designed as a web service (SOAP over HTTP) there is no persistent connection between the SAP system and the CRMConnectorSAP-service. For each request a new connection is established.
Events signaled from the SAP system to the CRMConnectorSAP-service are normally answered within a few milliseconds. Contact your SAP consult for detailed information about the different timeouts that are active in the SAP system.
Events sent from the CRMConnectorSAP-service to the SAP system are normally also answered within milliseconds. However, the maximum Round Trip Time (RTT) for such events should not exceed 30 seconds. After this time has elapsed the CRMConnectorSAP-service will consider the request as failed and initiate appropriate actions.
Remember that HTTP-messages can get delayed by the network if, for example, a firewall or a proxy is placed between the SAP system and the CRMConnectorSAP.
Maximum Round Trip Time: 30 seconds
CRMConnectorSAP – Cisco CTI Server (CTI Server Protocol)
Latency across the link between the CRMConnectorSAP-services and the Cisco CTI Server pair must not exceed 100ms one way (200ms RTT), 50ms (100ms RTT) is preferred.
Maximum Round Trip Time: 200 milliseconds
DataStore – CRMConnectorSAP (DS104)
In a multiple peripheral deployment, SAP call attached data can only be transferred for call transfers and conferences if at least one central DataStore is installed and properly configured. The CRMConnectorSAP-to-DataStore network carries call data traffic between the CRMConnectorSAP instances and the DataStore pair. This traffic consists primarily of SAP call attached data and control messages.
When deployed over a WAN, this network connection is critical to the process of passing SAP call attached data from one agent to another in case of a call transfer. It must meet aggressive latency requirements and, therefore, either IP-based priority queuing or Quality-of-Service (QoS) must be used on the network links. The CRMConnectorSAP-to-DataStore network has a maximum one-way latency of 200ms (500ms RTT).
Maximum Round Trip Time: 500 milliseconds
Port Utilization
This chapter describes the default ports used by CRMConnectorSAP, MediaManager, ChatConnector, CRMConnectorOutboundSAP and DataStore.
The information provided is based on default configuration settings. In most cases, it is possible to adjust these setting during installation or configuration. Therefore, the following listings might not show the actual ports in use on your system.
Ports used by CRMConnectorSAP
| Server Protocol & Port | Notes |
|---|---|
| TCP 8080 | Local port for the CRMConnectorSAP SAP ICI web service |
| TCP 42027 | Remote port of CTI Server A |
| TCP 43027 | Remote port of CTI Server B |
| TCP 42029 | Remote port of DataStore Host A and B |
| TCP 7050 | Remote port of MediaManager A and B |
| TCP 42031 | Local port for remote console of CRMConnectorSAP |
Ports used by MediaManager
| Server Protocol & Port | Notes |
|---|---|
| TCP 7010 | Local port for remote console of MediaManager |
| TCP 7021 | Local port for connection from MR PG |
| TCP 7050 | Local port for connection from MCIL clients (CRMConnectorSAP, MCILChat) |
| TCP 42027 | Remote port of CTI Server A |
| TCP 43037 | Remote port of CTI Server B |
Ports used by ChatConnector
| Server Protocol & Port | Notes |
|---|---|
| TCP 5222 | Remote port of the chat server |
| TCP 7050 | Remote port of MediaManager |
| TCP 9010 | Local port for remote console of ChatConnector |
| TCP 9080 | Local port for HTTP connections, used to display ChatConnector status page |
Ports used by DataStore
| Server Protocol & Port | Notes |
|---|---|
| TCP 42029 | Local port for connection from CRMConnectorSAP |
| TCP 42030 | Local port for remote console of DataStore |
| TCP 42028 | Local port of web browser of DataStore |
Ports used by CRMConnectorOutboundSAP
| Server Protocol & Port | Notes |
|---|---|
| TCP 9015 | Local port for remote console of CRMConnectorOutboundSAP |