Genesys Documentation - User contributions [en]

File:Voicemcs private edition architecture diagram.png

2022-07-18T05:45:50Z

Corinneh: Corinneh uploaded a new version of File:Voicemcs private edition architecture diagram.png

Draft:RN/VoiceOrchestration Service/100.0.100.0055

2022-06-30T02:44:11Z

Corinneh: Corinneh moved page Draft:RN/VoiceOrchestration Service/100.0.100.0055 to Draft:RN/VoiceOrchestration Service/100.0.100.0056: The team had to republish software, which changed the release number

#REDIRECT [[Draft:RN/VoiceOrchestration Service/100.0.100.0056]]

RN/VoiceSIP Proxy Service/100.0.100.0010

2022-03-30T18:14:14Z

Corinneh: Published

{{ComponentRN
|ComponentId=4c32d167-fb8a-4157-a204-8dbb1342a9f8
|JQL=issue = VOICEMCS-3063
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1, 8b480b3c-2733-433a-9166-eab2c2d0663a
|ReleaseDate=2021-11-12
|PrivateEditionReleaseDate=2022-03-28
|Highlight=100.0.100.0010: Resolved issue.
}}
{{Issue
|TicketNumber=VOICEMCS-3063
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Voice SIP Proxy Service now includes an X-Genesys-Partition-Id header in the incoming initial INVITE message.
|LocalContent=Voice SIP Proxy Service now includes an '''X-Genesys-Partition-Id''' header containing the tenant '''callcenterid''' (CCID) in the outgoing initial INVITE message.
}}

RN/VoiceSIP Proxy Service/100.0.100.0014

2022-03-30T18:12:30Z

Corinneh: Published

{{ComponentRN
|ComponentId=4c32d167-fb8a-4157-a204-8dbb1342a9f8
|JQL=issue = VOICEMCS-3813 OR issue = VOICEMCS-3855 OR issue = VOICEMCS-3638
|DeploymentTypeId=8b480b3c-2733-433a-9166-eab2c2d0663a, 5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-03-08
|PrivateEditionReleaseDate=2022-03-28
|Highlight=*Support for a new voice call rebalancing feature.
*Voice SIP Proxy service now supports the reuse of TCP connections.
*Voice SIP Proxy now maintains a TCP connection when it receives an incorrect SIP message over the connection.

}}
{{Issue
|TicketNumber=VOICEMCS-3855
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=SIP Proxy now does not close TCP connection if received incorrect SIP message over it. SIP Proxy now will reject with 400 Bad request response and keep connection intact.
|LocalContent=Voice SIP Proxy no longer closes a TCP connection when it receives an incorrect SIP message over it. Instead, SIP Proxy now rejects the message with a <tt>400 Bad request</tt> response and keeps the connection intact.
}}
{{Issue
|TicketNumber=VOICEMCS-3813
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=SIP Proxy now supports SIP devices reusing same TCP connection for all communications with SIP Proxy
|LocalContent=Voice SIP Proxy service now supports SIP devices reusing the same TCP connection for all communications with SIP Proxy.
}}
{{Issue
|TicketNumber=VOICEMCS-3638
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|LocalContent=Voice SIP Cluster service now supports a voice call rebalancing feature that allows the transition of voice calls from a SIP Cluster service instance, undergoing graceful termination, to a successor service instance. This type of voice call transition enhances call handling continuation during a rolling upgrade or service scale-down. Voice SIP Proxy service both supports and facilitates the voice call rebalancing feature.
}}

File:Pe ges architecture diagram.png

2022-03-29T19:34:32Z

Corinneh:

PrivateEdition/Current/TenantPEGuide/Deploy

2022-03-21T17:39:00Z

Corinneh: Published

{{Article
|Standalone=No
|DisplayName=Deploy the Tenant Service
|Context=Learn how to deploy the Tenant Service.
|ComingSoon=No
|Section={{Section
|alignment=Vertical
|structuredtext={{NoteFormat|Make sure to review {{Link-SomewhereInThisVersion|topic=Planning}} for the full list of prerequisites required to deploy the Tenant Service.|}}

|Status=No
}}{{Section
|sectionHeading=Deployment scenarios
|anchor=Scenarios
|alignment=Vertical
|structuredtext=More than one deployment scenario is supported, including single region, redundant, and multi-region deployment as well as multi-Tenant deployment.

===Single region/location/cluster===
You deploy Tenant resources in a single Kubernetes cluster within the same or separate namespace (project) with the Voice platform. If shared resources are being deployed across all Tenants, they must also be added to the same target namespace.

The Tenant deployment process creates resources using a ''release name'' parameter, specified when executing the Helm deployment step. When installed in a single namespace, you must make sure that the release name value is distinct across all Tenants and other deployments.

For example, you might specify the Helm release name in the format <tt>t<short_id></tt>. Optionally, if you want the Tenant service name to match other Voice services, you can prefix the Tenant name with <tt>voice-</tt> in the Helm release name. So, in this example, you would specify the release name as <tt>voice-t<short_id></tt> during Helm deployment. The value for <tt><short_id></tt> is the last four characters of the Tenant UUID that you configure in the '''values.yaml''' file. For more information about the identification parameters for the Tenant service, see {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=idparams|display text=Identification}}.

If you plan to use Prometheus monitoring or Fluent Bit logging framework for Tenant, you must execute the '''tenant-monitor''' module, as described in {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Deploy|anchor=locationspecificdeploy|display text=tenant-monitor}}. The module enables the following features:

*Prometheus PodMonitor definition for all tenant pods.
*Common Fluent Bit framework configuration for all tenant pods.

====Single Tenant: Basic deployment====
Single-node deployment requires a single override file and one "tenant" module to deploy, with reference implementation described at {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Deploy|anchor=servicespecificdeploy|display text=Single service at one location}}.

{{AnchorDiv|mandatoryparams}}Mandatory parameters for basic installation are:

*tenant uuid (v4)
*tenant nickname (becomes a Helm release name)
*all {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=backend|display text=backend parameters}} (along with all secrets that may be required based on these parameters)

To increase the number of nodes, adjust the '''node count''' parameter. For more information, see {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=scalabilityparams|display text=Scalability and redundancy parameters}}.

====Upgrade====
An upgrade can be performed by re-running deployment with the same mandatory parameters and adjusted version of Tenant image(s) and Helm charts. The upgrade is performed automatically, one node at a time (if '''node count''' is > 1). The update of the Tenant configuration may happen automatically when the primary node is upgraded. Genesys recommends performing a backup of the backend database for a Tenant Service before upgrading.

====Multiple Tenants at one location: Basic deployment====
You can deploy additional Tenants at the same location using the following guidelines:

*Each Tenant Service must have a unique tenant uuid, shortid, and nickname.
*Each Tenant Service is deployed or upgraded and adjusted independently.
|Status=No
}}{{Section
|alignment=Vertical
|structuredtext====Multiple regions/locations/clusters: Basic deployment===
In multi-regional/multi-location deployments, one region/location is considered "master" (from the Tenant perspective) and includes the database backend with <tt>write</tt> capabilities. Other regions/locations have replicas of the database backend in read-only mode. A Tenant Service at each location may be deployed to have one of its nodes running as master (<tt>write</tt> access to provisioning data through the config API) or have all its nodes running only as replicas (<tt>read</tt> access to configuration).

Multi-regional deployments must be performed using the following steps (with prerequisites already satisfied at each region/location):

*If required, deploy the '''tenant-monitor''' module at a location planned as a Master Tenant node.
*Complete the basic deployment of a Tenant Service in the Master region, including specification of DR parameters for the Master, as per {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=scalabilityparams|display text=Scalability and redundancy parameters}}.
*Complete the deployment of the database backend with replica of the Master database at location(s) where the replica Tenant nodes are expected to run, including provisioning of access keys/secrets to access the local replica.
*If required, deploy the '''tenant-monitor''' module at location(s) where replicas are expected to run.
*Complete the basic Tenant deployment for additional region(s) and specify DR parameters for the Master region (see {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=scalabilityparams|display text=Scalability and redundancy parameters}}).

The same customization scenarios described for Tenant nodes can be applied for each location independently.

====Upgrade====
An upgrade can be performed by re-running the deployment with the same mandatory parameters and adjusted version of the Tenant image(s) and Helm charts for every location. Update of the tenant configuration may happen automatically when the Master node in the Master region is upgraded. Genesys recommends performing a backup of the backend database for a Tenant Service before you upgrade the Master region.
|Status=No
}}{{Section
|sectionHeading=Deploy the service
|anchor=DeployService
|alignment=Vertical
|structuredtext=This section provides reference commands with key parameters that are required to complete each deployment step.

On this page, the '''tenant-values.yaml''' file refers to the '''values.yaml''' file in the Tenant Helm chart. Likewise, the '''tenant-monitor-values.yaml''' file refers to the '''values.yaml''' file in the Tenant Monitor Helm chart.
===Prerequisite===
Before proceeding with the Tenant Service deployment, ensure you have completed procedures in the {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=ConfigSecurity|display text=Configure security}} section of this guide.
{{AnchorDiv|locationspecificdeploy}}

===Location-specific deployment steps===
====tenant-monitor====
Monitoring/logging shared configuration and infrastructure deployment:<source lang="text">
helm upgrade --install --force --wait --timeout 600s -n voice tenant-monitor https://<jfrog artifactory/helm location>/tenant-monitor-$TENANT_MANIFEST_VERSION.tgz --username "$JFROG_USER" --password "$JFROG_PASSWORD"
</source>

To enable Prometheus monitoring, you can use the following overrides with tenant-monitor. Use the following changes in the '''tenant-monitor-values.yaml''' file to implement the changes:
<source lang="text">
prometheus:
podMonitor:
create: "true"
</source>

To enable Fluent Bit to send additional logs to stdout in json format (for selected Tenant functions, such as configuration audit) and/or raw format (such as from internal applications such as StatServer and URS), modify the following changes to upgrade tenant-monitor. Use the following changes in the '''tenant-monitor-values.yaml''' file to implement the changes.

<source lang="text">
fluent:
enable: "true"
rawlogs:
stdout:
enable: "true"
jsonlogs:
stdout:
enable: "true"
</source>

To enable RWX Persistent Volume Claim (PVC) in tenant-monitor to store Tenant logs shared across all Tenant pods, make the following modifications to override values in the '''tenant-monitor-values.yaml''' file:

<source lang="text">
tenant:
logging:
volume:
enabled: "true"
createSC: "false"
createpvClaim: "true"
logClaim: "tenant-logs-pvc"
logClaimSize: "5Gi"
logStorageClass: "<storage class>"
Storageprovisioner: "TBD OC provisioner"
parameters: {}
</source>

RWX PV is disabled by default; no overrides are required in the '''tenant-monitor-values.yaml''' file to disable it.

{{AnchorDiv|servicespecificdeploy}}

===Service-specific deployment steps: Single service at one location===
A PostgreSQL database must be available for the Tenant Service before you begin the service deployment. For more information about the database requirements, see {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Planning|anchor=ThirdParty|display text=Third-party prerequisites}}. In addition, after the PostgreSQL database is deployed and before you deploy the Tenant Service, you must configure secrets that contain values for certain PostgreSQL database parameters. To configure the secrets, see {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=servicespecificsecrets|display text=Service-specific secrets}}.

Use the following template if you are deploying with the tenant Helm chart. A single-service deployment can be implemented with the following sample parameters in the '''tenant-values.yaml''' file:

<source lang="text">
##UUID 4 format ( Set a new UUID for new tenant deployment)
tenantid: <tenant-uuid>

serviceAccount:
create: true

images:
imagePullSecrets: mycred
registry: <docker-repo>
pullPolicy: Always
tenant:
tag: <version of tenant service>

pgdbInit:
tag: <version of tenant service>

rcsInit:
tag: <version of roles service batch image>
enable: "true"

pulseInit:
tag: <version of tenant service>
enable: "true"
pulseMode: "setup"

tenant:
general:
upstreamServices: voice-sipfe:9101,voice-config:9100,ixn-server-{{ $.Values.tenantid }}:7120,ixn-vqnode-{{ $.Values.tenantid }}:7122"
pgdb:
dbhost: "/opt/genesys/dbserver/dbserver"
dbuser: "/opt/genesys/dbuser/dbuser"
dbname: "/opt/genesys/dbname/dbname"
securityContext:
fsGroup: 0

logging
....
volumes:
logPvc:
enabled: "true"
logClaimSize: "5Gi"
accessModes: "ReadWriteOnce"
logStorageClass: "<storage class>" #Replace the storage class that's relevant to the Openshift Cluster

mounts:
log:
- name: log
mountPath: /opt/genesys/logs/volume
- name: log
mountPath: /logs
secrets:
pgdb:
pwd:
secretName: "/opt/genesys/dbpassword/dbpassword"
secretKey: "dbpassword"
volumes: |
- name: dbpassword
secret:
secretName: dbpassword
- name: dbserver
secret:
secretName: dbserver
- name: dbname
secret:
secretName: dbname
- name: dbuser
secret:
secretName: dbuser
mounts:
- name: dbpassword
readOnly: true
mountPath: "/opt/genesys/dbpassword"
- name: dbserver
readOnly: true
mountPath: "/opt/genesys/dbserver"
- name: dbname
readOnly: true
mountPath: "/opt/genesys/dbname"
- name: dbuser
readOnly: true
mountPath: "/opt/genesys/dbuser"

consul:
acl:
secretName: "/opt/genesys/consul-shared-secret/consul-consul-voice-token"
volumes:
- name: consul-shared-secret
secret:
secretName: consul-voice-token
mounts:
- name: consul-shared-secret
readOnly: true
mountPath: "/opt/genesys/consul-shared-secret"
redis:
configPwd:
secretName: "/opt/genesys/redis-config-secret/redis-config-state"
volumes:
- name: redis-config-secret
secret:
secretName: redis-config-token
mounts:
- name: redis-config-secret
readOnly: true
mountPath: "/opt/genesys/redis-config-secret"

streamPwd:
secretName: "/opt/genesys/redis-tenant-secret/redis-tenant-stream"
volumes:
- name: redis-tenant-secret
secret:
secretName: redis-tenant-token
mounts:
- name: redis-tenant-secret
readOnly: true
mountPath: "/opt/genesys/redis-tenant-secret"

kafka:
pwd:
secretName: "/opt/genesys/kafka-secrets/kafka-secrets"
volumes:
- name: kafka-secrets
secret:
secretName: kafka-secrets-token
mounts:
- name: kafka-secrets
mountPath: "/opt/genesys/kafka-secrets"
gws:
user:
secretName: "/opt/genesys/gauth-client-id/clientid"
pwd:
secretName: "/opt/genesys/gauth-client-token/clientsecret"
volumes:
- name: gauth-client-id
secret:
secretName: gauthclientid
- name: gauth-client-token
secret:
secretName: gauthclientsecret
mounts:
- name: gauth-client-id
readOnly: true
mountPath: "/opt/genesys/gauth-client-id"
- name: gauth-client-token
readOnly: true
mountPath: "/opt/genesys/gauth-client-token"

redis:
isCluster: true
</source>

In addition, use the following deployment command:

<source lang="text">
helm upgrade --install --force --wait --timeout 600s -n voice -f ./tenant-node-values.yaml t<shortid> \
https://<jfrog artifactory/helm location>/tenant-<helm version>.tgz \
--username "$JFROG_USER" --password "$JFROG_PASSWORD"
</source>

The preceding deployment will create a Tenant with the password of the service account set up explicitly and without enabling GWS integration. See {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Deploy|anchor=enablegws|display text=Samples and references}} for values that allow you to reset the Tenant password upon deployment using a pre-generated value from the secret and to enable automated GWS integration.
|Status=No
}}{{Section
|sectionHeading=Samples and references
|anchor=SamplesReferences
|alignment=Vertical
|structuredtext=Enabling a service admin password (the secret should be created as described in the {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=servicespecificsecrets|display text=Service account password}} section):
<source lang="text">
...
tenant:
serviceuser: "default"
svcpwdSecretName: "/opt/genesys/service-user-account/svcpassword"
...
volumes: |
- name: service-user-account
secret:
secretName: svcuseraccount
...
volumeMounts: |
- name: service-user-account
readOnly: true
mountPath: "/opt/genesys/service-user-account"
....
initVolumeMounts: |
- name: service-user-account
readOnly: true
mountPath: "/opt/genesys/service-user-account"
....
</source>

{{AnchorDiv|logstostdout}}
To enable stdout log output for all Tenant components, make the following modifications to override values in the '''tenant-values.yaml''' file.

<source lang="text">
images
fbregistry: fluent/fluent-bit
...
fluentBit:
enable: "true"
name: json-sidecar
tag: 1.8.x

fluentBitUrs:
enable: "true"
name: stdouturs-sidecar
tag: 1.8.x

fluentBitSs:
enable: "true"
name: stdoutss-sidecar
tag: 1.8.x

fluentBitOcs:
enable: "true"
name: stdoutocs-sidecar
tag: 1.8.x

fluentBitCs:
enable: "true"
name: stdoutcs-sidecar
tag: 1.8.x

tenant:
...
logging:
volumes:
log:
- name: log
jsonLog:
- name: fluent-logs
emptyDir: {}
stdoutUrsLog:
- name: fluenturs-logs
emptyDir: {}
stdoutOcsLog:
- name: fluentocs-logs
emptyDir: {}
stdoutSsLog:
- name: fluentss-logs
emptyDir: {}
stdoutCsLog:
- name: fluentcs-logs
emptyDir: {}
fluentBconfigmap:
- configMap:
defaultMode: 420
name: tenants-fluent-bit-config
name: tenants-fluent-bit-config
fluentBconfigmapCs:
- configMap:
defaultMode: 420
name: tenants-fluent-bit-config-cs
name: tenants-fluent-bit-config-cs
fluentBconfigmapSs:
- configMap:
defaultMode: 420
name: tenants-fluent-bit-config-ss
name: tenants-fluent-bit-config-ss
fluentBconfigmapOcs:
- configMap:
defaultMode: 420
name: tenants-fluent-bit-config-ocs
name: tenants-fluent-bit-config-ocs
fluentBconfigmapUrs:
- configMap:
defaultMode: 420
name: tenants-fluent-bit-config-urs
name: tenants-fluent-bit-config-urs
mounts:
log:
- name: log
mountPath: /opt/genesys/logs/volume
- name: log
mountPath: /logs
jsonLog:
- name: fluent-logs
mountPath: "/opt/genesys/logs/JSON"
stdoutUrsLog:
- name: fluenturs-logs
mountPath: "/opt/genesys/logs/URS"
stdoutSsLog:
- name: fluentss-logs
mountPath: "/opt/genesys/logs/SS"
stdoutOcsLog:
- name: fluentocs-logs
mountPath: "/opt/genesys/logs/OCS"
stdoutCsLog:
- name: fluentcs-logs
mountPath: "/opt/genesys/logs/confserv"

fbJsonLog:
- name: fluent-logs
mountPath: "/mnt/logs"
fbstdoutUrsLog:
- name: fluenturs-logs
mountPath: "/mnt/logs"
fbstdoutSsLog:
- name: fluentss-logs
mountPath: "/mnt/logs"
fbstdoutOcsLog:
- name: fluentocs-logs
mountPath: "/mnt/logs"
fbstdoutCsLog:
- name: fluentcs-logs
mountPath: "/mnt/logs"

fluentBconfigmap:
- mountPath: /fluent-bit/etc/
name: tenants-fluent-bit-config
fluentBconfigmapCs:
- mountPath: /fluent-bit/etc/
name: tenants-fluent-bit-config-cs
fluentBconfigmapSs:
- mountPath: /fluent-bit/etc/
name: tenants-fluent-bit-config-ss
fluentBconfigmapOcs:
- mountPath: /fluent-bit/etc/
name: tenants-fluent-bit-config-ocs
fluentBconfigmapUrs:
- mountPath: /fluent-bit/etc/
name: tenants-fluent-bit-config-urs
</source>

{{AnchorDiv|rwopvclogging}}
You can deploy Persistent Volume/Persistent Volume Claim (PV/PVC) in two ways:

#Enable ReadWriteOnce (RWO) from the tenant Helm chart, which maintains unique PVCs for each pod/replica from the same Tenant.
#Enable ReadWriteMany (RWX) from the tenant-monitor Helm chart, which has multiple Tenant pods sharing the same PVC.

To enable RWO PV/PVC logging from individual Tenant pods in Statefulset, make the following modifications to override the values in the '''tenant-values.yaml''' file. RWO Persistent Volume is disabled by default.

<source lang="text">
logging
....
volumes:
logPvc:
enabled: "true"
logClaimSize: "5Gi"
accessModes: "ReadWriteOnce"
logStorageClass: "<storage class>" #Replace the storage class that's relevant to the Openshift Cluster
</source>

{{AnchorDiv|enablegws}}
Enabling GWS integration (the secret should be created as described in the {{Link-SomewhereInThisVersion|manual=TenantPEGuide|topic=Configure|anchor=servicespecificsecrets|display text=Genesys Authentication backend secrets}} section):
<source lang="text">
tenant:
…
gws:
# enable: Enable GWS registeration about tenant
# tls: Enable/Disable Secure connection to GWS
# authEndpoint: GWS auth end point
# envEndpoint: GWS env end point for Registeration
# db: Pass DB infromation for GWS to connect to PSQL DB for read and store data
enable: "true"
tls: false
authEndpoint: "gauth-auth.gauth.svc.cluster.local"
envEndpoint: ""
db:
enable: "false"
read: "false"
init: "false"
secrets:
……….
gws:
enabled: true
user:
secretName: "/opt/genesys/gauth-client-id/clientid"
pwd:
secretName: "/opt/genesys/gauth-client-token/clientsecret"
volumes:
- name: gauth-client-id
secret:
secretName: gauthclientid
- name: gauth-client-token
secret:
secretName: gauthclientsecret
mounts:
- name: gauth-client-id
readOnly: true
mountPath: "/opt/genesys/gauth-client-id"
- name: gauth-client-token
readOnly: true
mountPath: "/opt/genesys/gauth-client-token"
</source>

{{AnchorDiv|mountpvc}}
To mount the PVC to store Tenant logs, make the following modifications to override the values in the '''tenant-values.yaml''' file:
<source lang="text">
.....

tenant:
...
logging:
mounts:
log:
- name: log
mountPath: /opt/genesys/logs/volume
- name: log
mountPath: /logs
</source>
|Status=No
}}{{Section
|sectionHeading=Validate the deployment
|anchor=Validate
|alignment=Vertical
|structuredtext={{Notices|Notice=PEComingSoon}}
|Status=No
}}
|PEPageType=45d1441f-dc69-4a17-bd47-af5d811ce167
}}

RN/VoiceSIP Proxy Service/100.0.100.0014

2022-03-09T05:17:10Z

Corinneh: Published

{{ComponentRN
|ComponentId=4c32d167-fb8a-4157-a204-8dbb1342a9f8
|JQL=issue = VOICEMCS-3813 OR issue = VOICEMCS-3855 OR issue = VOICEMCS-3638
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-03-08
|Highlight=*Support for a new voice call rebalancing feature.
*Voice SIP Proxy service now supports the reuse of TCP connections.
*Voice SIP Proxy now maintains a TCP connection when it receives an incorrect SIP message over the connection.
}}
{{Issue
|TicketNumber=VOICEMCS-3855
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=SIP Proxy now does not close TCP connection if received incorrect SIP message over it. SIP Proxy now will reject with 400 Bad request response and keep connection intact.
|LocalContent=Voice SIP Proxy no longer closes a TCP connection when it receives an incorrect SIP message over it. Instead, SIP Proxy now rejects the message with a <tt>400 Bad request</tt> response and keeps the connection intact.
}}
{{Issue
|TicketNumber=VOICEMCS-3813
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=SIP Proxy now supports SIP devices reusing same TCP connection for all communications with SIP Proxy
|LocalContent=Voice SIP Proxy service now supports SIP devices reusing the same TCP connection for all communications with SIP Proxy.
}}
{{Issue
|TicketNumber=VOICEMCS-3638
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|LocalContent=Voice SIP Cluster service now supports a voice call rebalancing feature that allows the transition of voice calls from a SIP Cluster service instance, undergoing graceful termination, to a successor service instance. This type of voice call transition enhances call handling continuation during a rolling upgrade or service scale-down. Voice SIP Proxy service both supports and facilitates the voice call rebalancing feature.
}}

RN/VoiceSIP Cluster Service/100.0.100.0025

2022-03-07T20:19:19Z

Corinneh: Published

{{ComponentRN
|ComponentId=dc95d354-6dba-4291-98d9-f11343c12f7b
|JQL=issue = VOICEMCS-3844 OR issue = VOICEMCS-3843
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-03-07
|Highlight=*Support for a new voice call rebalancing feature.
*Support for customization of the Designer Application Server (DAS) part of the <tt>dial-plan-moh</tt> option value.
}}
{{Issue
|TicketNumber=VOICEMCS-3844
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=In this release, SIP Cluster service introduces support of new ‘Voice call rebalance’ feature allowing transition of voice calls from a SIP Cluster service instance, undergoing graceful termination, to a successor service instance.Such transition of voice calls enhances call handling continuation in cases of rolling upgrade or service scale down. (VOICEMCS-2596)
|LocalContent=Voice SIP Cluster service now supports a voice call rebalancing feature that allows the transition of voice calls from a SIP Cluster service instance, undergoing graceful termination, to a successor service instance. This type of voice call transition enhances call handling continuation during a rolling upgrade or service scale-down.
}}
{{Issue
|TicketNumber=VOICEMCS-3843
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|LocalContent=Voice SIP Cluster service now allows customization of the Designer Application Server (DAS) part of the <tt>dial-plan-moh</tt> option value. To customize the value, specify a new <tt>designerDasAddress</tt> parameter in the Helm chart '''values.yaml''' file.

Support for this feature begins with Helm chart version voice-sip-100.0.1000013.tgz.
}}