Before you begin
Find out what to do before deploying WebRTC.
Limitations and assumptions
Download the Helm charts
Download the Helm charts from the webrtc folder in the JFrog repository. See Helm charts and containers for WebRTC for the Helm chart version you must download for your release.
For information about how to download the Helm charts in Jfrog Edge, see the suite-level documentation: Downloading your Genesys Multicloud CX containers
WebRTC contains the following containers:
|Artifact||Type||Functionality||JFrog Containers and Helm charts|
|webrtc||webrtc gateway container||Handles agents’ sessions, signalling, and media traffic. It also performs media transcoding.||https://<jfrog artifactory>/<docker location>/webrtc/webrtc/|
|coturn||coturn container||Utilizes TURN functionality||https://<jfrog artifactory>/<docker location>/webrtc/coturn/|
|webrtc-service||Helm chart||https://<jfrog artifactory>/<helm location>/ webrtc-service-<version_number>.tgz|
For information about setting up your Genesys Multicloud CX private edition platform, see Software requirements.
The following are the third-party prerequisites for WebRTC:
|Keda||2.0||Custom metrics for scaling. Use of Keda or HPA is configurable through Helm charts.||KEDA can be enabled or disabled for WebRTC. But, WebRTC cannot be configured to use HPA instead of KEDA.
|Load balancer||VPC ingress. For NGINX Ingress Controller, a single regional Google external network LB with a static IP and wildcard DNS entry will pass HTTPS traffic to NGINX Ingress Controller which will terminate SSL traffic and will be setup as part of the platform setup.|
|A container image registry and Helm chart repository||Used for downloading Genesys containers and Helm charts into the customer's repository to support a CI/CD pipeline. You can use any Docker OCI compliant registry.|
|Command Line Interface||The command line interface tools to log in and work with the Kubernetes clusters.|
WebRTC does not require persistent storage for any purposes except Gateway and CoTurn logs. The following table describes the storage requirements:
|Persistent Volume||Size||Type||IOPS||Functionality||Container||Critical||Backup needed|
|webrtc-gateway-log-volume||50Gi||RW||medium||storing gateway log files||webrtc||Y||Y|
|webrtc-coturn-log-volume||50Gi||RW||medium||storing coturn log files||coturn||N||Y|
Persistent Volume and Persistent Volume Claim will be created if they are configured. The size for them optional and should be adjusted according to log rate described below:
idle: 0.5 MB/hour per agent
active call: around 0.2MB per call per agent.
Example: For 24 full hours of work, where each agent call rate is constant and is around 7 to 10 calls per hour, we will require around ~500GB for 1000 agents, with around ~20GB being consumed per hour.
For 1000 connected agents, the load rate is approximately 3.6 GB/hour which scales linearly and increases or decreases with the number of agents and stays constant whether calls are performed or not.
WebRTC requires the following Ingress requirements:
- Persistent session stickiness based on cookie is mandatory. Stickiness cookie should contain the following attributes:
- No specific headers requirements
- Whitelisting (optional)
- TLS is mandatory
WebRTC supports three types of secrets: CSI driver, Kubernetes secrets, and environment variables.
grant_type=authorization_code grant_type=urn:ietf:params:oauth:grant-type:token-exchange grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer grant_type=client_credentials
For GWS secrets, CSI or Kubernetes secret should contain gwsClient and gwsSecret key-values.
GWS secret for WebRTC must be created in the WebRTC namespace using the following specification as an example:
apiVersion: v1 kind: Secret type: Opaque metadata: name: webrtc-gws-secret namespace: webrtc data: client_id: XXXXX client_secret: YYYYY
The following Web Application Firewall (WAF) rules should be disabled for WebRTC:
|WAF Rule||Number of rules|
Pod Security Policy
WebRTC and CoTurn auto-scaling is performed by KEDA operator. The auto-scaling feature requires Prometheus metrics. To know more about KEDA, visit https://keda.sh/docs/2.0/concepts/.
Use the following option in YAML values file to enable the deployment of auto-scaling objects:
deployment: keda: true
You can configure the Polling interval and maximum number of replicas separately for Gateway pods and CoTurn pods using the following options:
gateway: scaling: pollingInterval: 30 maxReplicaCount: 100 coturn: scaling: pollingInterval: 30 maxReplicaCount: 100
- Gateway Pod Scaling
gateway: scaling: pollingInterval: 30 maxReplicaCount: 100 prometheusAddress: <nowiki>http://monitoring-prometheus-prometheus.monitoring:9090</nowiki> thresholdSignins: 25
- CPU based scaling
WebRTC auto-scaling is also performed based on the CPU and memory usage. The following YAML shows how CPU and memory limits should be configured for Gateway pods in YAML values file:
gateway: scaling: prometheusAddress: <nowiki>http://monitoring-prometheus-prometheus.monitoring:9090</nowiki> pollingInterval: 30 maxReplicaCount: 100 thresholdSignins: 25 thresholdCpu: 60 thresholdMemory: 60
- CoTurn Pod scaling
Auto-scaling of CoTurn is performed based on CPU and memory usage only. The following YAML shows how CPU and memory limits should be configured for CoTurn pods in YAML values file:
coturn: scaling: pollingInterval: 30 maxReplicaCount: 100 thresholdCpu: 60 thresholdMemory: 60
|Firefox||Current release or one version previous||Genesys also supports the current ESR release. Genesys supports the transitional ESR release only during the time period in which the new ESR release is tested and certified. For more information, see Firefox ESR release cycle. Firefox updates itself automatically. Versions of Firefox are only an issue if your IT department restricts automatic updates.|
|Chrome||Current release or one version previous||Chrome updates itself automatically. Versions of Chrome are only an issue if your IT department restricts automatic updates.|
|Microsoft Edge Chromium||Current release|
WebRTC has dependencies on several other Genesys services and it is recommended that the provisioning and configuration of WebRTC be done after these services have been set up.
|GWS||Used for environment and tenants configuration reading|
|GAuth||Used for WebRTC service and Agents authentication|
|GVP||Used for voice calls - conferences, recording, and so on|
|Voice microservice||Used to handle voice calls|
|Tenant microservice||Used to store tenant configuration|
For detailed information about the correct order of services deployment, see Order of services deployment.