prepare documenation folders and clean up some depreciated folders I …

…found along the way

VERSION

@@ -1 +1 @@
-v2.10
+v3.0

applications/acdc/doc/ARCHITECTURE.org → applications/acdc/doc/architecture.md

@@ -1,8 +1,14 @@
-* Agents
+/*
+Section: ACDC
+Title: Architecture
+Language: en-US
+*/
+
+# Agents
 
 Agents represent the endpoints that a call in a queue will try to connect with.
 
-** Agent process layout
+## Agent process layout
 
 Agents are comprised of two processes, a gen_listener (named process) and a gen_fsm. A supervisor ensures that the gen_listener and gen_fsm are kept alive together. A supervisor above that manages the list of agents.
 
@@ -14,7 +20,7 @@ Agents are comprised of two processes, a gen_listener (named process) and a gen_
                         \|---[acdc_agent]
                         \|---[acdc_agent_fsm]
 
-*** Agent FSM
+### Agent FSM
 
 init -1-> sync -2-> ready -3-> ringing ---\
                      ^                     !
@@ -30,11 +36,11 @@ init -1-> sync -2-> ready -3-> ringing ---\
 6. Call has unbridged/hungup
 7. Wrapup timer has expired
 
-** Agent message processing
+## Agent message processing
 
 The interplay between AMQP messages, the agent process, and the agent FSM process
 
-*** Member Connect Requests
+### Member Connect Requests
 
               AMQP                      Erlang
 [Queue]                    [Agent]                     [AgentFSM]
@@ -46,7 +52,7 @@ The interplay between AMQP messages, the agent process, and the agent FSM proces
 
 An agent will respond to all connect requests while in the *ready* state. The acdc_agent will pass along the member_connect_req to the FSM. If the FSM is in the *ready* state, the FSM will pass the request JSON to the agent process to send the member_connect_resp message. If the FSM is in any other state, the member_connect_req payload will be ignored.
 
-*** Member Connect Win
+### Member Connect Win
 
               AMQP                      Erlang
 [Queue]                    [Agent]                     [AgentFSM]
@@ -71,7 +77,7 @@ An agent will respond to all connect requests while in the *ready* state. The ac
 
 When an agent receives a member_connect_win while in the *ready* state, the FSM will instruct the agent process to bridge to the agent's endpoint(s) and enter the *ringing* state. The agent process binds to the call events and attempts the bridge. Once the bridge is established, the FSM will instruct the agent process to send a member_connect_accepted and move to the *answered* state. On receiving a hangup event, the FSM will instruct the agent process to unbind from call events and will start the wrapup timer and enter the *wrapup* state. Once the timer fires, the FSM will return to the *ready* state.
 
-*** Member Connect Win (fail to bridge)
+### Member Connect Win (fail to bridge)
 
               AMQP                      Erlang
 [Queue]                    [Agent]                     [AgentFSM]
@@ -90,7 +96,7 @@ When an agent receives a member_connect_win while in the *ready* state, the FSM
 
 When an agent is in the *ready* state, receives a member_connect_win, attempts to bridge, and the bridge fails, the agent FSM will instruct the agent process to send a member_connect_retry, unbind from the call events, and return the FSM to the *ready* state.
 
-*** Member Connect Win (not in *ready* state)
+### Member Connect Win (not in *ready* state)
 
               AMQP                      Erlang
 [Queue]                    [Agent]                     [AgentFSM]
@@ -104,27 +110,27 @@ When an agent is in the *ready* state, receives a member_connect_win, attempts t
 If a member_connect_win is received when _not_ in the *ready* state, reply with the member_connect_retry immediately.
 
 
-* Agents Manager
+# Agents Manager
 
 Agent login requires starting an agent process group; the Agents Manager process will take care of handling agent process group startup. Agent logout requires stopping the agent process group; Agents Manager will ensure the agent process group has terminated.
 
-** Agents Manager process layout
+## Agents Manager process layout
 
 [acdc_sup]
    \|
    \|----[acdc_agents_sup]
    \|----[acdc_queues_sup]
    \|----[acdc_agents_mgr]
 
-** Agents Manager message processing
+## Agents Manager message processing
 
 CF: Callflow action (for now, other mechanisms possible later)
 AsM: acdc_agents_mgr
 AsSup: acdc_agents_sup
 ASup: acdc_agent_sup
 APG: Agent Process Group - acdc_agent, acdc_agent_fsm
 
-*** Agent Login
+### Agent Login
 
             AMQP               Erlang           
 [CF]                 [AsM]                [AsSup]           [ASup]           [APG]
@@ -135,7 +141,7 @@ APG: Agent Process Group - acdc_agent, acdc_agent_fsm
                                               -- start_child -->
                                                                -- start_link -->
 
-*** Agent Logout
+### Agent Logout
 
             AMQP               Erlang           
 [CF]                 [AsM]                [AsSup]           [ASup]           [APG]
@@ -146,7 +152,7 @@ APG: Agent Process Group - acdc_agent, acdc_agent_fsm
                                               -- terminate -->
                                                                -- terminate -->
 
-*** Agent Pause
+### Agent Pause
 
             AMQP               Erlang           
 [CF]                 [AsM]                [AsSup]           [ASup]           [APG]
@@ -157,7 +163,7 @@ APG: Agent Process Group - acdc_agent, acdc_agent_fsm
                                               -- pause -->
                                                                -- pause -->
 
-*** Agent Resume
+### Agent Resume
 
             AMQP               Erlang           
 [CF]                 [AsM]                [AsSup]           [ASup]           [APG]
@@ -168,16 +174,16 @@ APG: Agent Process Group - acdc_agent, acdc_agent_fsm
                                               -- resume -->
                                                                -- resume -->
 
-*** Agent Stats
+### Agent Stats
 
 The various agent processes and FSMs will send stats to the Agents Manager process, which will record them to a Folsom table. Queries from interested parties (like Crossbar) will send AMQP requests which the Agent Manager will respond to as well.
 
 
-* Queues
+# Queues
 
 A queue provides ordering of calls through it.
 
-** Queue process layout
+## Queue process layout
 
  [acdc_queues_sup]
          \|
@@ -194,7 +200,7 @@ A queue provides ordering of calls through it.
                                             \|----acdc_queue_shared
                                             \|----acdc_queue_fsm
 
-*** Queue Startup
+### Queue Startup
 
 When acdc_init starts up (last child of acdc_sup), it iterates through each account. In each account, iterate over the queues available.
 
@@ -217,11 +223,11 @@ acdc_queue_listener is the AMQP arm of the worker, listening for and delivering
 acdc_queue_fsm is the brains of the worker. It tracks what state the member call is in, which agent to respond with a Win to, etc.
 acdc_queue_shared is an AMQP listener for member_call payloads. It has the special restrictions of QoS of 1, and no auto-acking of payloads. When the FSM is finished with a member call, it is via acdc_queue_shared that the payload is ACK'd and the worker moves to the next call.
 
-*** Queue - Shared
+### Queue - Shared
 
 Because of the need to not auto-ack member call payloads, the consumption of messages from the shared AMQP queue necessitated moving that queue management into its own gen_listener, while messages betweem the queue process and agent processes flow unimpeded on the acdc_queue process's AMQP queue. The acdc_queue_shared routing is still passed to acdc_queue_handlers, to be fed into the acdc_queue_fsm process.
 
-*** Queue FSM
+### Queue FSM
 
  init ---> sync -1-> ready -2-> member_connect_req --\
                        ^                  4          3
@@ -234,11 +240,11 @@ Because of the need to not auto-ack member call payloads, the consumption of mes
 5. member_connect_accepted received from winning agent process
 
 
-** Queue message processing
+## Queue message processing
 
 The interplay between member_call requests (from callflow initially), the queue, queue fsm, and agent processes.
 
-*** Member Call Requests
+### Member Call Requests
 
             AMQP               Erlang                      AMQP                    AMQP
 [CF]                 [Queue]             [QueueFSM]                  [Agents]                [Agent]
@@ -267,7 +273,7 @@ The queue process sends the member_connect_req, and collects member_connect_resp
 
 Once the agent process has connected the caller to the agent endpoint, the queue process will receive a member_connect_accepted payload. The queue process hands this off to the FSM, which lets the queue process know it can ACK the member_call payload (and allow the AMQP queue to send the next member_call to the next consumer). The queue process unbinds from the call events.
 
-*** Member Call Requests (Agent Retry)
+### Member Call Requests (Agent Retry)
 
             AMQP               Erlang                      AMQP                    AMQP
 [CF]                 [Queue]             [QueueFSM]                  [Agents]                [Agent]
@@ -289,7 +295,7 @@ Once the agent process has connected the caller to the agent endpoint, the queue
                                        {member_conn_req}
 This flow diagram shows how a queue reacts to a member_connect_retry (sent by the winning agent for a variety of reasons). The diagram loops back at the FSM re-entering the *member_conn_req* state.
 
-*** Member Call Requests (Call hungup)
+### Member Call Requests (Call hungup)
 
             AMQP               Erlang                      AMQP                    AMQP
 [Call]              [Queue]             [QueueFSM]                  [Agents]                [Agent]
@@ -321,11 +327,11 @@ This diagram shows how the FSM reacts to receiving a HANGUP either during:
  *member_conn_req*: ignores member_connect_resps, unbinds from the call events, and ACKs the member_call so the queue can progress
  *member_conning*: ignores member_connect_accepted/retry messages, unbinds from the call events, and ACKs teh member_call
 
-* Supervisors
+# Supervisors
 
 A supervisor is able to listen/coach an agent while on the phone with a customer.
 
-** Supervisor process layout
+## Supervisor process layout
 
 Similar to agent processes. The FSM will manage the lifecycle of a coach/whisper/listen
 
@@ -337,5 +343,5 @@ Similar to agent processes. The FSM will manage the lifecycle of a coach/whisper
                       \|----acdc_super_listener
                       \|----acdc_super_fsm
 
-*** Supervisor startup
+### Supervisor startup
 

applications/acdc/doc/README.org → applications/acdc/doc/index.md

@@ -1,10 +1,16 @@
-* ACDc - Your friendly automatic call distribution commander
+/*
+Section: ACDC
+Title: Automatic Call Distributor
+Language: en-US
+*/
+
+# ACDc *Your friendly automatic call distribution commander*
 
 First, the "commander" part is a stretch, I know.
 
 High level concepts involved here are queues and agents. There's a many-many relationship between queues and agents: a queue can have many agents, and an agent can be part of many queues. As such, there needs to be a distinct differentiation between what an agent is responsible for and what a queue tracks.
 
-** Agents
+## Agents
 
 An agent represents an account user with a device (and possibly many devices). The agent tracks:
 
@@ -15,7 +21,7 @@ An agent represents an account user with a device (and possibly many devices). T
 5. the agent id
 6. the agent's account db
 
-*** Agent Statuses
+### Agent Statuses
 
 *init*: the agent process is starting up. Will not accept member connection requests.
 
@@ -31,7 +37,7 @@ An agent represents an account user with a device (and possibly many devices). T
 
 *paused*: the agent is on break or otherwise not taking calls. An optional timer can be set to limit how long the agent may remain in the paused state.
 
-*** Agent Process Initialization
+### Agent Process Initialization
 
 An agent can be represented by one or more Erlang processes, on any number of nodes, and in any one of the statuses above. As such, startup of the agent process is a tricky matter.
 
@@ -51,7 +57,7 @@ If a sync_resp is in the *wrapup* status, the resp should include the time left
 
 If a sync_resp is in the *paused* status, the resp should include the time left (if on a timed break). If no time is included, the initializing agent process will enter the *paused* status indefinitely, until an agent_status event instructs the agent process to come back to *ready*.
 
-*** Happy case for a member call
+### Happy case for a member call
 
 agent status: *ready*
 Agent process receives a member_connect_req message off the message bus. Agent publishes a member_connect_resp to the requesting queue's AMQP queue and enters the *waiting* state.
@@ -68,7 +74,7 @@ Agent process monitors the call's event stream, waiting for a hangup event. Upon
 agent status: *wrapup*
 Queue may optionally specify a wrapup_timeout, delaying how long an agent must wait before returning to *ready*.
 
-**** An attempt at a message flowchart
+#### An attempt at a message flowchart
 
 Q = A queue in an account
 AX(Y)(S) = Agent with id X, process Y, status S
@@ -111,11 +117,11 @@ Q <--- member_hungup --- A1(_)(Wr)
 5. Agent's wrapup timer expires, enters *ready* status
 Q                        A1(_)(R)
 
-** Queues
+## Queues
 
 Queues manage the dispersal of member calls to agents. Because the queue won't know if an agent is busy in another queue, the queue will broadcast a member_connect_req to all known agents. The queue will collect member_connect_resps and choose one agent, based on routing strategy, to send the member_connect_win message. If the agent is unable to connect the call and send the queue a member_connected, the agent will attempt the next appropriate member_connect_resp. If the list is exhausted, the queue will wait a configurable amount of time before sending another member_connect_req and repeating the process.
 
-*** Queue Process Initialization
+### Queue Process Initialization
 
 As with agents, multiple queue processes can (and should) be started per acdc queue. The challenge becomes how to coordinate member calls being distributed to agents with multiple queue processes running for the same queue.
 
@@ -125,7 +131,7 @@ Startup of a queue process should declare the AMQP queue as acdc.queue.ACCT.QID
 
 Of course, communication with the agent processes will occur with the queue processes dedicated AMQP queue. So each queue process will consume from both the shared AMQP queue and from their own private AMQP queue.
 
-*** Queue Call Handling
+### Queue Call Handling
 
 1. member_call published from callflow module to shared AMQP queue acdc.queue.ACCT.QID
 CF -- member_call --> Q1(1)

applications/acdc/doc/todo.md

@@ -0,0 +1,14 @@
+/*                                                                                                                                                                                                                                                                                                 
+Section: ACDC
+Title: TODO
+Language: en-US
+*/
+
+# TODO
+## Scenario 1
+* No agents logged in
+* Customer calls in...eventually hangs up
+* Agent logs in
+* Agent receives ghost call
+
+Call waiting log isn't updating

applications/acdc/doc/troubleshooting.md

@@ -0,0 +1,6 @@
+/*
+Section: ACDC
+Title: Troubleshooting
+Language: en-US
+*/
+

applications/acdc/doc/ui.md

@@ -0,0 +1,8 @@
+/*                                                                                                                                                                                                                                                                                                 
+Section: ACDC
+Title: UI Updates
+Language: en-US
+*/
+
+# UI Updates
+No restriction on agents. They are agents if they have a non-empty queues list. All users are allowed to be an agent.

applications/blackhole/doc/example_client.html → applications/blackhole/doc/index.md

@@ -1,3 +1,13 @@
+/*
+Section: Blackhole
+Title: Blackhole
+Language: en-US
+*/
+
+# Blackhole *Realtime HTTP Websocket Events*
+
+## Example Client
+~~~
 <html>
   <head>
     <script src="//cdnjs.cloudflare.com/ajax/libs/socket.io/0.9.6/socket.io.min.js"></script>
@@ -12,17 +22,19 @@
       socket.emit("subscribe", { account_id: "4b31dd1d32ce6d249897c06332375d65", auth_token: "7b70f69a2a4976d80bfa0382894d1553", binding: "conference.event.*"});
 
       socket.on("participants_event", function (data) {
-      console.log(data);
+        console.log(data);
       });
       socket.on("CHANNEL_CREATE", function (data) {
-      console.log(data); // data = EventJObj
+        console.log(data); // data = EventJObj
       });
       socket.on("CHANNEL_ANSWER", function (data) {
-      console.log(data);
+        console.log(data);
       });
       socket.on("CHANNEL_DESTROY", function (data) {
-      console.log(data);
+        console.log(data);
       });
     </script>
   </body>
 </html>
+~~~
+

applications/blackhole/doc/troubleshooting.md

@@ -0,0 +1,6 @@
+/*
+Section: Blackhole
+Title: Troubleshooting
+Language: en-US
+*/
+

applications/callflow/doc/index.md

@@ -0,0 +1,8 @@
+/*
+Section: Callflow
+Title: Callflow
+Language: en-US
+*/
+
+# Callflow *PBX Functionality*
+Please press 1 to continue