Before you begin

From Genesys Documentation
Revision as of 19:23, June 30, 2021 by Corinne.hicks@genesys.com (talk | contribs) (Published)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This topic is part of the manual Voice Microservices Private Edition Guide for version Current of Voice Microservices.

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:

  1. Persistent Volumes & Persistent Volume Claims
  2. 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
  • 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.
Here is the sample Kubernetes YAML file for creating PVCs for a Voicemail Service. The PVC creation is controlled by the Voicemail Service Helm chart by overriding the values.yaml.
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
  1. Replication strategies are not available for the data.
  2. Retention limit: Admins can't configure the auto-expiration for a Voicemail message.
  3. 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

Content coming soon

Browser requirements

Not applicable

Genesys dependencies

For detailed information about the correct order of services deployment, see Order of services deployment.

GDPR

Content coming soon
Comments or questions about this documentation? Contact us for support!