Before you begin
Contents
Find out what to do before deploying the Voicemail Service.
Limitations and assumptions
Voice Voicemail Service integration with Workspace Web Edition and Web Services and Applications is in progress. The integration brings an appearance of actionable voice mailbox information in the Workspace Web Edition UI, presenting users with Message Waiting Indicator(s) for each voice mailbox assigned to them either directly as a personal mailbox or as a group mailbox via membership in a group(s) having a mailbox provisioned. Users still have access to voicemail from Workspace Web Edition by dialing directly to a voicemail access number, which is 5555.
Download the Helm charts
For information about how to download the Helm charts, see Downloading your Genesys Multicloud CX containers.
The following table identifies the Helm chart version associated with the Voicemail service.
Service name | Helm chart version |
---|---|
voice-voicemail | voice-voicemail-9.0.xx.tgz |
Third-party prerequisites
See the Third-party prerequisites for the Voice Services.
Storage requirements
Choosing Voicemail storage
To store mailbox metadata and messages, consider the following supported options for storage in the Private Edition deployment:
- Persistent Volumes & Persistent Volume Claims
- Azure Blob Storage
See the following sections to learn how to use these storage options and to find information about their limitations.
Persistent Volume & Claim
- Persistent Volume (PV) is a piece of storage that can be mounted to a Voicemail Service deployment inside the Kubernetes cluster.
- PVs in OpenShift can be created with different plugins
- Plugin Reference: Kubernetes Persistent Volumes, Claims, Storage Classes, and More
- Voicemail Service requires a separate storage class and PV to be created for a Voicemail storage.
- If the customer wants to extend the deployment to more than one Kubernetes cluster, Voicemail Service requires to mount the same PV for all the Kubernetes cluster for that customer.
- Create the Persistent Volume Claim (PVC) from the Voicemail PV.
- The access mode for the PVC must be ReadWriteMany, since the Voicemail Service will edit the existing data while updating the mailbox settings or the message state.
- Use the sizing doc, which you can find on the (Genesys SIP Feature Server landing page, to calculate the required storage space.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: voice-voicemail-pvc
namespace: voice
labels:
servicename: voice-voicemail
spec:
storageClassName: voice-voicemail
volumeMode: Filesystem
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi
Limitations
- Replication strategies are not available for the data.
- Retention limit: Admins can't configure the auto-expiration for a Voicemail message.
- When a customer has more than one Kubernetes cluster deployed, the PV for all the Kubernetes clusters must be created from a single storage drive, so that the data from one Kubernetes cluster is shared among other Kubernetes clusters.
Azure blob
- Unlike PV, the Azure Blob Storage provides options to replicate and configure Time to live for the files and can be accessed from any Kubernetes cluster by using the storage access keys.
- Create the Azure Storage with the blob storage.
- The access keys for the blob storage must be securely mounted to the Voicemail pod. You can do one of the following:
- Store access keys in Azure Key Vault and mount it via a Container Storage Interface (CSI) driver.
- Create access keys as a Kubernetes secret and volume mount the Kubernetes secret. (This option is considered less secured than the CSI driver approach.)
- The values.yaml file can be overridden for configuring either a Kubernetes secret or CSI driver, which is explained in Override Helm chart values.
Network requirements
Browser requirements
Not applicable
Genesys dependencies
For detailed information about the correct order of services deployment, see Order of services deployment.