CROSS-CLUSTER COMMUNICATION	Started: 2011-05-27	Updated: 2017-01-01


!!!!! THIS FEATURE DOES NOT EXIST, THIS IS FOR PLANNING PURPOSES ONLY !!!!!


This is a planning document for how different vicidial clusters can communicate 
with each other to send various types of information between them. The overall 
goal is to allow for many clusters to talk to each other.

Some of the types of communication that we would like to achieve are:
- Setup of crossover trunks(SIP/IAX) allowing for 1-way or 2-way calling
- Allowing lookup of lead information while transferring between clusters
- Allow transmission of number of calls in queue, agents available and other stats
- Allow routing of calls to another cluster based upon total daily call percentage, drop rate, number of waiting calls or number of waiting agents



--------------------------------
 DATABASE AND ADMIN CHANGES:
--------------------------------

A new options in System Settings will be added:
- cross_cluster_enabled - Y/N
- local_cluster_id - the id that is used for this cluster by other clusters

This will require a new Admin subsection for cluster configuration:
- cluster_id
- cluster_name
- active - Y/N
- cluster_primary_server
- cluster_trunk_protocall - SIP/IAX
- cluster_agent_api_url
- cluster_nonagent_api_url
- cluster_api_user
- cluster_api_pass
- cluster_api_permissions - lead_lookup, user_lookup, ingroup_lookup, etc...
- cluster_user_group - used to define the campaigns/ingroups cluster is allowed to get info on
- <readonly auto-updated> cluster_dst, cluster_tz, cluster_local_gmt_now

There will be new options added to Servers:
- local_gmt_now - current calculated gmt offset
- cluster_id - default will be LOCAL cluster
- cluster_call_direction - IN_FROM_CLUSTER, OUT_TO_CLUSTER, BOTH, NONE
- cluster_server_ip - SERVER_IP, ALT_IP, EXTERNAL_IP

There will be a new table added to link lead_ids on clusters:
-vicidial_list_cluster_link
- lead_id
- cluster_id
- cluster_lead_id
- call_date
- caller_code

New table to keep track of the active in-groups and campaigns on other clusters
- group_id
- name
- type - INGROUP, CAMPAIGN
- cluster_id

Some tables will have a "cluster_id" field added to them to show where the call came from
- vicidial_auto_calls
- vicidial_campaign_stats



--------------------------------
 NON-AGENT API CHANGES:
--------------------------------

lead_id_lookup:
- REQUIRES: cluster_id, caller_code
- RETURNS: all lead and call information

lead_notes_lookup:
- REQUIRES: cluster_id, lead_id
- RETURNS: call history for lead_id including per-call notes

ingroup_status:
- REQUIRES: cluster_id, group_id
- RETURNS: status, after hours, number of agents waiting/incall/paused/total, number of calls waiting, calls today, drops today, drop %

campaign_status:
- REQUIRES: cluster_id, campaign_id
- RETURNS: status, number of agents waiting/incall/paused/total, number of calls waiting, calls today, drops today, dialable leads, drop %

ingroup_campaign_list:
- REQUIRES: cluster_id
- RETURNS: ID and name of all active campaigns and in-groups on the cluster

cluster_server_status:
- REQUIRES: cluster_id
- RETURNS: listing of defined servers, their current times as well as PHP and DB times



--------------------------------
 CALL FLOW AND TRUNK CHANGES:
--------------------------------

- IAX/SIP crossover trunks would be added between every server on every active cluster(depending on direction settings)
- dialplan context would be added for each foreign cluster to route calls with proper cluster_id flag allowing for lookups of lead information



--------------------------------
 SIMPLER ALTERNATIVE OPTION:
--------------------------------
Below is a description of a more simple option, which is to send lead data from one cluster to another as the lead is sent over.
- A call to be sent from one cluster to another should leave its callerIDname as the Caller Code, the 20-character code that includes the lead_id
- This call will go into an internal DID on the other cluster through an IAX trunk between the two
- At the DID, the call will get sent to a Call Menu where the call will go through an AGI script
- That AGI script will look up the lead_id on the originating system using the Non-Agent API and credentials set in a Settings Container
- If there is a match, then the AGI script will gather the default lead information, insert the information into the new system and change the callerIDname with the new system's lead_id included
- The call will then go to an In-Group with that lead_id set so it can then go on to an agent
