Modified: for 12.1.1

Overview

The TRM is enhanced to act as a centralized CAC entity in the CS pod. When the TRM is in the SC pod, it sends the CAC requests to the TRM in the CS pod. The TRM of the SC pod sends an ICM to the CS process running in the SC pod that is already connected to the CS process running in the CS pod, and it forwards the ICM message through the ZMQ connection. Upon receiving the message, the CS process running in the CS pod forwards it to the TRM of the CS pod through an ICM. When the TRM of the CS pod receives the message, it performs the CAC check based on the configuration and responds with the result through the same route.

The processes described below refer to the Ingress flow of the call. Similar processes apply to the egress flow for the following messages:

  • TRM_ALLOCATE_CMD_MSG
  • TRM_ALLOCATE_RPY_MSG

While Sending CAC RequestWhile Sending CAC Reply
TRM of SC pod
  • When it receives TRM_IP_LOOKUP_CMD_MSG, it creates the Call Control Block (CCB) and performs the local processing before sending the same message to the CS process of the SC pod through an ICM through the TRM cluster CAC FSM.
  • This message contains the GUID, which is used in the TRM of the CS pod to create the call control block to cater to the CAC requests.
  • These outgoing requests are stored in an array (structures with required info). The user can refer to it when any response is received and map back to the original request. Also, a half-a-second timer is available to keep a check on idle transactions to cover any message drop/network-related issues. The user must wait 3 seconds (6 timer counts) before marking a transaction as "expired" and clearing it from this array.

  • When it receives the message, it maps the response to the corresponding request through the array in which it stored the reference while sending the request.

  • The TRM cluster CAC FSM returns the result to the original requester using the existing utility method.

  • Since the TRM_IP_LOOKUP_RPY_MSG handles the response, the TRM cluster CAC FSM's response-taking routine is updated accordingly.

CS process of SC pod

  • When it receives the ICM, it adds the SC pod's ID into it and forwards the message to the CS process of the CS pod through the already established ZMQ connection.

  • When it receives the ZMQ message, it forwards the message to the TRM of the SC pod through an ICM.
CS process of CS pod
  • When it receives the ZMQ message, it forwards the message to the TRM of the CS pod through an ICM.
  • When it receives the ICM, it fetches the SC pod's ID. Based on that, it extracts the appropriate SC pod's information to forward the message to the CS process of that SC pod through the already established ZMQ connection.
TRM of CS pod

  • When it receives the message, it follows the same routine as the TRM of the SC pod since the TRM code and message type are the same. The TRM code for that routine is updated to act based on the pod type it is running on.

  • The GUID support is added since it is required for the Call Control Block (CCB)

  • Once the modified/enhanced CAC check based on the pod type is performed, the result is formulated and sent back to the SC pod.

  • The formulated result is then sent to the CS process of the CS pod through an ICM using TRM_IP_LOOKUP_RPY_MSG. The SC pod's ID received in the request message is copied into the response message.


The following diagram represents the call/message flow between the SC pod and CS pod:


The following diagram represents the call/message flow:



Switchover and Synchronization

Creation of the per SC CCB list

This is a linked list with each node depicting each SC pod connected to the CS pod, and each node will further have a hash map that will contain the data related to the CCBs as contained by callHashTbl.

  1. Whenever any SC pod connects with the CS pod, the CS process of the CS pod will send a message to CS TRM with the newly connected SC pod's instance ID and upon receiving that message, CS TRM will allocate memory (per SC CCB list) for this new SC pod's data.
  2. Whenever any SC pod disconnects from the CS pod, the CS process of the CS pod starts a 30-second timer.
    1. If the SC pod doesn't reconnect before this timer expires, the CS process deletes that SC pod's data and will send a message to CS TRM with that SC pod's instance ID to remove that SC pod's data and adjust its counters.
    2. If the SC pod reconnects before this timer expires, then SC TRM will automatically send a sync message with all the CCBs that are associated with it once it gets the connection up event from the CS process of the SC pod.

Note: In case 2. (a.) mentioned above, if the SC pod's data has been deleted by the CS pod (both CS process and TRM), then whenever it comes up, it registers with the CS pod and the connection between both the pods is up and running, SC TRM will automatically send a sync message with all the CCBs that are associated with it once it gets the connection up event from CS process of SC pod.


SC Switchover Scenario

Whenever an SC pod comes up, either initially or after switchover, and the CS process of the SC pod establishes a connection with the CS pod, it'll send the link's state notification message to SC TRM. Once SC TRM receives link state 'connected' event, it will send a sync message to CS TRM, including all the CCBs it is currently handling.

Upon receiving the sync message, CS TRM will go through the per SC CCB list for this particular SC and will start marking the 'retainCcb' flag as 'true' for all the CCBs received in the sync message. Once the syncing procedure is complete, SC TRM will send a sync completed notify message to CS TRM after that CS TRM will go through that per SC CCB list for that SC and for whichever CCB the 'retainCcb' flag is 'false', it'll delete that CCB from both the lists in CS TRM and will adjust the counters. [The CCBs for which the 'retainCcb' flag would be 'false', would potentially be the calls which got dropped during SC switchover]


SC-CS Disconnection Scenario

As the SC TRM receives SC-CS link state notify message, upon receiving that message:

  1. If the link state is 'disconnected', it will start ACCEPTING new calls without checking any CAC limit.
  2. If the link state is 'connected', it will send a sync message to CS TRM which will include all the CCBs which it is currently handling.

Note: All the changes in the CCB list of SC TRM during the disconnection period will be updated to CS TRM through the sync message which it would send once the connection between both the pods come up. The updated CCB list could include CCBs that got newly added and exclude the ones that got terminated; and the existing ones, CS TRM will handle all of them while processing the sync message with the help on 'retainCcb' flag as explained in 'SC switchover scenario'.


CS Switchover Scenario

Whenever CS pod would go down, SC TRM will behave exactly as it would in a SC-CS disconnection scenario explained above.