Overview
Bucher + Suter’s (b+s) b+s Connects for Oracle Service Cloud is a pre-packaged integration of Oracle Service Cloud and Cisco's Unified Contact Center Enterprise (CCE) or Cisco Unified Contact Center Express (CCX). It is a set of processes, managing the real time flow of interactions between the Oracle Service Cloud user interface and Cisco's CCE/CCX. CCE/CCX utilizes b+s Connects for Oracle Service Cloud to route phone calls and chats to the most skilled agents, who can accept and manage those interactions using the Oracle Customer Experience Graphical User Interface (GUI).
Architecture
b+s Connects for Oracle Service Cloud is the umbrella term of the Oracle Service Cloud to Cisco CCE/CCX integration solution. It consists of the following components:
Harmony MediaBar
The Harmony MediaBar (also known as Harmony Client) is an Oracle Service Cloud Add-In component that is deployed with the cloud delivered Oracle Service Cloud client. Since the Harmony MediaBar is an integral part of the Oracle Service Cloud application, it provides agents a unified desktop to manage customer interactions. The Harmony MediaBar allows contact center agents to take calls, emails, and chats, post their status, conference in other agents, work on multiple interactions, receive customer and interaction detail information, along with many other workflows, all within their Oracle Service Cloud client.
Harmony Configuration Server
Harmony Configuration Server provides a web-based interface to configure the Harmony MediaBar and the Harmony Integration Server. The Harmony Configuration Server allows administrators a centralized configuring and mapping of contact center agents’ based settings.
Harmony Integration Server
Harmony Integration Server (HIS) provides communication services to the Harmony AgentAdapter and acts as an agent desktop broker for all client interactions. HIS maintains a set of SCXML documents that describe desktop state transitions in a business process format. It delivers all Oracle Service Cloud agent state information to CCE/CCX, HIS enables unified reporting from the CCE/CCX platform.
Harmony AgentAdapter
The Harmony AgentAdapter represents the connection between the Cisco CCE/CCX environment and the Harmony Integration Server (HIS). It forwards requests coming from HIS to Cisco Finesse. The Harmony AgentAdapter also pushes events that are coming from the Cisco CCE/CCX to HIS (e.g. agent state changes or call events).
Harmony RoutingAdapter
The Harmony RoutingAdapter is a standalone service that offers an interface to be called by the MediaRoutingPlugin in order to route chats and emails, and offers an interface to the CCE media routing interface MRI
MediaRoutingPlugin
MediaRoutingPlugin is used by the Harmony QueueAdapter to connect to the Harmony RoutingAdapter and to route chats and emails.
Harmony OpenMethods QueueAdapter
Harmony QueueAdapter polls the Oracle Service Cloud queues for new email route requests and receives push notifications of new chat route requests. It then forwards these route requests to the Harmony RoutingAdapter via the Harmony MediaRoutingPlugin to initiate the routing process of CCE. Harmony QueueAdapters are specific to Oracle Service Cloud instances.
The diagram below is a high level diagram of the b+s Connects for Oracle Service Cloud components and their key connections to the Cisco Contact Center and Oracle CX platforms.
Deployment Models
The modular architecture of b+s Connects for Oracle Service Cloud 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 b+s Connects for Oracle Service Cloud can be installed on one single host or each component can have its own separate host. In this chapter, the b+s Connects for Oracle Service Cloud deployment models recommended by b+s are described.
! Be aware that if you intend to operate b+s Connects for Oracle Service Cloud in both a production and in a testing environment, none of the b+s Connects for Oracle Service Cloud components can be shared! That means that two completely separated installations of the b+s Connects for Oracle Service Cloud components are required. b+s recommends that test and production environments are maintained on separate host systems (i.e. virtual machines) to ensure the possibility of troubleshooting and validating new releases and hotfixes in the test environment prior to deployment to production. Furthermore, non-redundant deployments are only supported for non-production (i.e. lab/testing) environments.
Harmony Duo Cluster Fundamentals
The Harmony MediaBar and the so called Harmony Duo - which consists of the Harmony Integration Server and Harmony AgentAdapter - operate in a cluster resilience model. A cluster of Harmony Duos is set up based on the business need for maximum interaction capacity, with some margin for peaks, and adding cluster nodes to handle worst-case outage of Harmony Duo components for failure or maintenance reasons. The capacity of a Harmony Duo is documented in chapter 5 Capacity & Redundancy.
General Harmony Duo Cluster Characteristics
· Load balancing across Harmony Duos is accomplished at agent login by the Harmony Integration Server selection process selecting the Harmony Integration Server with the least load. Harmony MediaBars are intelligent enough to select the Harmony Integration Server instance with the least load at the time of connection. A Harmony MediaBar will continue communicating with that instance of Harmony Integration Server until either its session ends with a normal logout, or if connectivity fails. In that way, the agent load is spread evenly across all operational Harmony Duos as all active Harmony Duos in a cluster can actively handling interactions.
· Failover is accomplished by behaviors in both the Harmony MediaBar and the Harmony Duo components, caused by a failure and the subsequent re-login process. In the case of a failed connection between the Harmony MediaBar and the Harmony Integration Server, or the outage of one of the Harmony Duo’s components, the Harmony MediaBar will logout all affected agents. A re-login to another Harmony Duo, allowing login and resync to the current state of agent channels and the interactions in progress, is performed automatically by MediaBar. When a Harmony Duo fails, the media stream in progress (voice call or chat session) is not affected.
Harmony Duo Clustering in a Nutshell
· The Harmony Duo does not use a hot or cold standby strategy for achieving a high availability (HA) deployment. All Harmony Duos are active in a HA configuration.
· Harmony MediaBars are intelligent enough to select the Harmony Integration Server instance with the least load at the time of connection. It will continue communicating with that instance until either its session ends or connectivity fails.
· The agent load is spread evenly across all operational Harmony Duos.
· In the case of a failed connection, the affected Harmony MediaBars will fail-over to another instance and initiate the re-login of the agent automatically.
Voice Only Deployments
As already mentioned, there are various different deployment models. In the following chapters, the recommended voice-only deployment models are outlined.
Single PG in one location
For a single PG deployment in one location, b+s recommends one host per Harmony Duo. Depending on the number of concurrent agents, the number of required Harmony Duo Hosts varies (for information regarding concurrent agents, please consult chapter 5.1 Capacity and Scalability Considerations.
Multi-PG in one or more location
b+s recommends the same model for Multi-PG deployment in one or multiple location as for the single PG deployments. Per PG pair, at least two hosts with a dedicated Harmony Duo each are required.
Multichannel Deployments (CCE only)
Single PG one location
If only two Harmony Duos are required, the media routing components (Queue Adapter and Routing Adapter) can be deployed on the same hosts. Please consult chapter 5 Capacity & Redundancy to expand the number of required Harmony Duo servers.
If additional Harmony Duo hosts are required, b+s recommends deploying the media routing components on a separate host as shown in Figure 7: Single PG Voice and Media Channel Deployment.
Multi-PG at one or more locations
In multi-PG deployment at one or more locations, it is recommended always to deploy the media components on dedicated hosts.
Host System Requirements
The b+s Connects for Oracle Service Cloud components 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 Cores | RAM | Disk Space* |
|---|---|---|---|
| Small | 2 | 4GB | 40GB |
| Medium | 4 | 4GB | 40GB |
| Large | 4 | 8GB | 40GB |
*Refers to the disk space required for b+s applications, does not include disk space required for the operating system.
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 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 ESX or 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:
· Cisco - Virtualization for Unified CCE https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-unified-contact-center-enterprise.html
Cisco - Virtualization for Packaged CCE https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-packaged-contact-center-enterprise.html
Cisco - Virtualization for Unified CCX https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unified-contact-center-express.html
and the general Cisco UC virtualization guidelines which can be accessed through:
· Unified Communications Virtualization Sizing Guidelines https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-sizing.html
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/CCX, refer to the Cisco Solution Design Guide for Cisco Unified Contact Center Enterprise which [2] is accessible from:
the Cisco Solution Design Guide for Cisco Unified Contact Center Express [3] which is accessible from:
Capacity & Redundancy
Capacity and Scalability Considerations
To determine the required capacity for production deployments of b+s Connects for Oracle Service Cloud, b+s suggest considering the following information.
· Concurrent Agent Count
· Tolerance factor due to maintenance and b+s application outage
· Maximum number of concurrent agents per Harmony Duo
Follow the calculation example below by specifying the number of concurrent agents, a tolerance factor, the current Harmony Duo concurrent agent maximum (see chapter 5.1.1 Harmony Duo Capacity). This will calculate the minimum number of required Harmony Duo servers. To provide enough reserve server capacity, an additional Server is required.
Required Harmony Duo Servers =
Concurrent agents / max agents Harmony Duo + Tolerance factor
b+s recommends using one of the following tolerance factor: high failure tolerance (+2 Duos) and low failure tolerance (+1 Duo). The following table determines how many Harmony Duos are required for a particular deployment.
| Concurrent Agents | Required Harmony Duo | |
|---|---|---|
| High failure tolerance | Low failure tolerance | |
| 10-500 | 3 | 2 |
| 501-1000 | 4 | 3 |
| 1001-1500 | 5 | 4 |
| 1501-2000 | 6 | 5 |
Harmony Duo Capacity
The following table shows which host system class is suited for the host system where the b+s Connects for Oracle Service Cloud components are deployed (i.e. the b+s application server).
| Host System Class | Maximum number of concurrent agents | Comments |
|---|---|---|
| Small | 1 - 10 | For labs/testing environments |
| Large | 11 - 500 | For production environments |
The supported maximum number of concurrent agents listed in the table above is based on the following conditions:
· Relevant to one b+s application server
· All b+s Connects for Oracle Service Cloud components are deployed on the b+s application server (Harmony Integration Server, Harmony AgentAdapter, Harmony QueueAdapter, Harmony RoutingAdapter).
· All 3rd party applications that b+s Connects for Oracle Service Cloud components connect to (e.g. Cisco Contact Center components) are deployed on (a) separate host(s).
· The dimensioning guidelines above originate from a lab testing environment. Actual quality of service (delays, responsiveness, etc.) experienced by the agents might vary. These variations include structure and size of the CRM database, overall level of the CRM tuning, message payload, transferred attached data, intensity of the contact processing workflow(s), as well as other CRM configuration and topology variables outside the scope of the b+s Connects for Oracle Service Cloud. b+s highly recommends an in-house load-test to ensure that total quality of service under load is satisfactory.
·
! Please note that if the previously mentioned supported maximum number of concurrent agent is reached, Harmony AgentAdapter will no longer accept agent login requests from the Harmony MediaBar and from Harmony Integration Server, respectively. Affected agents will see an error message displayed on the Harmony MediaBar.
Redundancy Considerations
Harmony MediaBar & the Harmony Duo Components
The Harmony MediaBar and the so-called “Harmony Duo components” operate in a cluster resilience model (see chapter 3.1 Harmony Duo Cluster Fundamentals). Failover is accomplished by behaviors in both the Harmony MediaBar and the Harmony Duo components, during logout, caused by a failure and the subsequent re-login process. In the case of a failed connection between the Harmony MediaBar and the Harmony Integration Server, or an outage of one of the Harmony Duo’s components, the Harmony MediaBar will logout all affected agents. A manual re-login to another Harmony Duo—allowing login and resync to the current state of the interaction which is in progress—must be performed by each agent individually. When a Harmony Duo fails, the media stream in progress (voice call or chat session) is not affected.
During login, the Harmony MediaBar polls the available Harmony Integration Servers which have been configured. The Harmony MediaBar uses the Harmony Integration Servers responses (or lack of response) to determine which Harmony Integration Server will be connected. The connection will be made to the Harmony Integration Server, which reports its availability and which has the least number of active agents connected. Harmony Integration Servers, which do not respond within a configurable timeout period are ignored by the Harmony MediaBar.
Harmony QueueAdapter and MediaRoutingPlugin
The Harmony QueueAdapter must be deployed on two hosts to achieve cold-standby redundancy. One Harmony QueueAdapter is started an active, the second is stopped. Both Harmony QueueAdapters have the same configuration. If the active Harmony QueueAdapter fails, all chats that are currently queued in Cisco CCE are lost. Active chat sessions are not affected by such an outage. The second Harmony QueueAdapter must be started manually to re-enable the routing process.
Harmony RoutingAdapter
The Harmony RoutingAdapter must be deployed on two hosts to achieve Hot-standby redundancy. When one Harmony RoutingAdapter is started and active, the second is idle. Both Harmony RoutingAdapters have the same configuration. If the active Harmony RoutingAdapter fails, all chats that are currently queued in Cisco CCE are lost. Active chat sessions are not affected by such an outage.
Failover Behavior
CCE Deployments
Figure 10 shows a redundant installation of b+s Connects for Oracle Service Cloud with two separate Harmony Duos (Harmony Integration Server, Harmony AgentAdapter), and a redundant Cisco CCE environment (Finesse, CCE Agent PG, CCE MR PG). For simplicity, not all Oracle and Cisco components are shown on this figure (e.g. Cisco CCE Central Controller, Cisco UCM are missing).
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 it does not process any message until a failure of its pair service occurs
· IDLE means that the particular service is started but IDLE. If the ACTIVE service fails the IDLE service takes over and becomes ACTIVE
· STOPPED means that the particular service is stopped and must be started manually to become ACTIVE
The following table shows the failover behavior in case of an outage of one of the Harmony Duo components or Harmony QueueAdapter / Harmony RoutingAdapter
| Component Outage | Fallback | Comments |
|---|---|---|
| Harmony Integration Server A | Harmony Integration Server B | If Harmony Integration Server A fails… …affected agents are logged out from the Harmony MediaBar …affected agents are automatically re-logged into the Harmony MediaBar ...active voice calls are not interrupted ...active chat sessions are not interrupted ...active mail sessions are not interrupted |
| Harmony AgentAdapter A | Harmony AgentAdapter B | If Harmony AgentAdapter A fails… …affected agents are logged out from the Harmony MediaBar …affected agents are not logged out from the voice channel in CCE …affected agents are automatically re-logged into the Harmony MediaBar. ...active voice call are not interrupted ...active mail sessions are not interrupted ...active chat sessions are not interrupted |
| Harmony QueueAdapter A | Harmony QueueAdapter B | If Harmony QueueAdapter A fails... ...new chats cannot be routed anymore until Harmony QueueAdapter B has been started (manual startup required) and can connect to either Harmony RoutingAdapter A or B ...all chats that are currently queued in CCE are lost ...active chat sessions are not affected by such an outage …all emails that are currently queued in CCE are removed and resubmitted …active email sessions are not affected by such an outage |
| Harmony RoutingAdapter A | Harmony RoutingAdapter B | If Harmony RoutingAdapter A fails... ...all chats that are currently queued in CCE are lost ...active chat sessions are not affected by such an outage …all emails that are currently queued in CCE are removed and resubmitted …active email sessions are not affected by such an outage |
CCX Deployments
Figure 11 shows a redundant installation of b+s Connects for Oracle Service Cloud with two separate Harmony Duos (Harmony Integration Server, Harmony AgentAdapter), and a redundant Cisco CCX environment (Finesse, CCX). For simplicity, not all Oracle and Cisco components are shown on this figure (e.g. Cisco UCM is missing).
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 it does not process any message until a failure of its pair service occurs
· IDLE means that the particular service is started but IDLE. If the ACTIVE service fails the IDLE service takes over and becomes ACTIVE
· STOPPED means that the particular service is stopped and must be started manually to become ACTIVE
The following table shows the failover behavior in case of an outage of one of the Harmony Duo components.
| Component Outage | Fallback | Comments |
|---|---|---|
| Harmony Integration Server A | Harmony Integration Server B | If Harmony Integration Server A fails… …affected agents are logged out from the Harmony MediaBar and CCX …affected agents are automatically re-logged into the Harmony MediaBar ...active voice calls are not interrupted |
| Harmony AgentAdapter A | Harmony AgentAdapter B | If Harmony AgentAdapter A fails… …affected agents are logged out from the Harmony MediaBar …affected agents are automatically re-logged into the Harmony MediaBar ...active voice calls are not interrupted |
Deployment Requirements
Agent Workstation Environmental Requirements
Connectivity and Oracle Service Cloud Client
A minimum of three (3) agent workstations to be designated for use during deployment testing are required. These workstations will require network connectivity that supports TCP/IP communication to the Harmony Integration Server and to the Oracle Service Cloud. Proper network credentials should be provided to allow each agent to login to the workstation and gain the above described network connectivity. The Oracle Service Cloud client should be installed on each agent workstation. Please refer to the chapter 6.2 Oracle Service Cloud Requirements for additional details.
Phones
Each workstation used for testing should also have an associated phone that can be configured to receive incoming test calls as described in chapter 6.3 Cisco Contact Center Requirements**. These phones can be hard or soft phones. b+s recommends using soft phones with appropriate network connectivity to support the remote installation and operation of the soft phone application. This allows b+s to conduct testing from their internal lab environment without depending upon the customer for testing
Oracle Service Cloud Requirements
| Purpose | Required Information |
|---|---|
| For installation and testing purposes, b+s requires the Oracle Service Cloud Installation URL. | Oracle Service Cloud Client Download URL |
| To upload and configure the Harmony MediaBar client Add-In, administrative staff account credentials are required. | Administrative Staff Account Login ID, password |
| To test the functionality of the Harmony MediaBar client Add-In, agent staff account credentials are required. | Agent 1 Staff Account Login ID , password Agent 2 Staff Account Login ID , password Agent 3 Staff Account Login ID , password |
Cisco Contact Center Requirements
To support placing test calls into a test or production environment, and to have those calls routed to any of the available test agents, the following items are required from a Cisco Contact Center perspective:
· One (1) routing script and skill group dedicated to this project for testing only (not shared with anyone else)
· One (1) dialed number to map to the routing script / skill group mentioned above
· Three (3) agents
· Two (2) configured as regular agents
· One (1) configured as supervisor for the above agents
· The agents must be skilled to the above-mentioned testing skill group
· Three (3) phone extensions to be used during testing
· These extensions can be soft or hard phones (see chapter Phones).
· Configuration information for the provided extensions
These above-mentioned items must be configured in a way that allows the test agents to use one of the phone extensions to login to the Cisco Contact Center environment and receive calls placed through the dialed number into the test skill group.
Connectivity Requirements
Remote Connectivity
For installing and configuring the different components on the b+s Connects for Oracle Service Cloud application servers or for post-installation testing, b+s representatives require remote connectivity to the servers. b+s prefers to have dedicated (multiple) virtual private network (VPN) accounts for each technician, if possible.
· Typically, (3) to five (5) VPN accounts are sufficient to allow for multiple tasks to be completed simultaneously.
· After the b+s Connects for Oracle Service components are installed, b+s representatives will conduct testing of agent phone operation and interaction control via the Harmony MediaBar. To conduct this testing, VPN connectivity is required to support the agent hard phone/soft phone used for testing.
· The customer can choose the method used to provide voice connectivity (i.e. hard phone/soft phone).
· b+s recommends using soft phones with appropriate network connectivity to support the remote installation and operation of the soft phone application. This allows b+s to conduct testing from their internal lab environmen\bschwbnft01\BSDownloads_Drehscheibet without requiring the customer’s assistance.
Network Requirements
Network Latency
Harmony AgentAdapter – Cisco Finesse Server (HTTP REST and XMPP protocol)
Latency across the link between the Harmony AgentAdapter and the Cisco Finesse Server pair must not exceed 200ms one way (400ms RTT). 100ms (100ms RTT) is preferred.
Maximum Round Trip Time: 400 milliseconds
Harmony RoutingAdapter – Cisco MediaRouting PG (MRI protocol)
Latency across the link between the MediaManager-services and the Cisco CCE MR PG pair must not exceed 100ms one way (200ms RTT). 50ms (100ms RTT) is preferred.
Maximum Round Trip Time: 200 milliseconds
Network Bandwidth
Harmony AgentAdapter – Cisco Finesse Server (HTTP REST and XMPP protocol)
There are many factors to consider for traffic and bandwidth requirements between Harmony AgentAdapters and Cisco Finesse Servers.
Most bandwidth is used during agent login and especially in case of a failover when all agents at the same time need to be re-logged in on other Finesse Server.
To calculate the required bandwidth for this connection, see Cisco Finesse Bandwidth Calculator at http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html.
Since we are using the Finesse API only and not the HTML Desktop, we can use the values with caching.
The following calculation are estimations
Sample calculation for one Harmony AgentAdapter, with the maximal supported number of 500 concurrent agents per Harmony Duo:
· 500 Agents (non-SSO)
· 0 Supervisors
· 500 Multi-Channel agents
· 2 MRD channels (chat+mail)
· 5 minutes Maximum Login Time (on failover)
· 15000 Busy Hour Call Attempts (BHCA) calls/hour (= 30 calls per hour per agent)
· 30 seconds wrapup time
· 300 seconds Average Task Duration
Results:
· On Login/Failover within 5 min.: Voice 33’156 kbps + Media 110 kbps = 33'156 kpbs
· Post-Login: 4'819 kbps
Harmony RoutingAdapter – Cisco MediaRouting PG (MRI protocol)
The bandwidth used to send route requests from Harmony RoutingAdapter to Cisco CCE MR PG depends on the payload per route request and the amount of route requests.
When this connection was lost and is reconnected, all queued tasks need to be resent again. Therefore, the highest bandwidth is required during reconnect/failover of one of the MediaRouting components.
Since the request send rate is limited by Cisco, the Harmony AgentAdapter also limits a maximal request send rate with a default of 5 tasks per second. This limits the used bandwidth in failover situations, but also increases the time until all the tasks are re-queued again.
Bandwidth calculation for routing tasks with 5 tasks/second:
· Assuming ~2kB of attached data (Peripheral Variables + ECC variables)
· 1x RouteRequest + 1x RouteSelect = 4 kB per task
· 5 tasks/second * 4 kB = 20 kB/s = 160 kbps
Port Utilization
This chapter describes the default ports used by Harmony Configuration Server, Harmony MediaBar, Harmony Integration Server, Harmony QueueAdapter, Harmony AgentAdapter, and Harmony RoutingAdapter.
! 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.
Service Ports
· Harmony Configuration Server default Service Ports
| Server Protocol & Port | Notes |
|---|---|
| HTTP 9088 or HTTPS 9443 | Local service port for web interface |
| HTTP 7088 or HTTPS 7443 | Local port for admin web service access |
· Harmony Integration Server default Service Ports
| Server Protocol & Port | Notes |
|---|---|
| HTTP 8088 or HTTPS 8443 | Local service port for connection from Harmony MediaBar |
| TCP 61616 | Local service port for connection from Harmony AgentAdapter (only from local host) |
· Harmony QueueAdapter default Service Ports
| Server Protocol & Port | Notes |
|---|---|
| HTTP 5000 or HTTPS 5001 | Local service port for connection from Harmony MediaBar |
· Harmony AgentAdapter default Service Ports
| Server Protocol & Port | Notes |
|---|---|
| TCP (telnet) 9010 | Local service port for the command-line interface (Default only locally accessible from localhost) |
| HTTP 9080 | Local service port for web status page (Default only locally accessible from localhost) |
· Harmony RoutingAdapter default Service Ports
| Server Protocol & Port | Notes |
|---|---|
| TCP (telnet) 9012 | Local service port for the command-line interface (Default only locally accessible from localhost) |
| HTTP 9082 | Local service port for web status page (Default only locally accessible from localhost) |
| TCP (WCF net.tcp) 8092 | Local service port used for connection from MediaRoutingPlugin in Harmony QueueAdapter |
| TCP (MRI) 7021 | Local service port for Cisco Media Routing PG |
| HTTP(S) REST 8095 | Local service port for reroute requests (RONA and Reject) from Harmony AgentAdapter |
Client ports (remote server port on outgoing connections)
· Harmony MediaBar used Client Ports
| Client Protocol & Port | Notes |
|---|---|
| HTTP 9088 or HTTPS 9443 | Remote port to Harmony Configuration Server |
| HTTP 7088 or HTTPS 7443 | Remote admin port to Harmony Configuration Server |
| HTTP 8088 or HTTPS 8443 | Remote port to Harmony Integration Server |
| HTTP 5000 or HTTPS 5001 | Remote port to Harmony QueueAdapter |
· Harmony Integration Server used Client Ports
| Client Protocol & Port | Notes |
|---|---|
| TCP 9088 or 9443 | Remote port to Harmony Configuration Server |
· Harmony QueueAdapter (incl. MediaRoutingPlugin) used Client Ports
| Client Protocol & Port | Notes |
|---|---|
| HTTPS 443 | Remote port to Oracle Service Cloud (.rightnowtech.com, .custhelp.com) |
| TCP (WCF net.tcp) 8092 | Remote port to Harmony RoutingAdapter (from MediaRoutingPlugin) |
· Harmony AgentAdapter used Client Ports
| Client Protocol & Port | Notes |
|---|---|
| HTTP REST 80 or HTTP REST 8082 or HTTPS REST 8445 | Remote port to Cisco Finesse REST interface · 80: not encrypted, UCCE · 8082: not encrypted, UCCX 8445: encrypted, UCCE and UCCX |
| XMPP 5222 or 5223 | Remote port to Cisco Finesse XMPP interface · 5222: not encrypted · 5223: encrypted |
| HTTP(S) 8095 | Remote port to Harmony Routing Adapter for reroute requests (RONA and Reject) |
| TCP 61616 | Remote port to Harmony Integration Server (only to local host) |