CROSS-CLUSTER COMMUNICATION					2011-05-27


!!!!! 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
