Uploaded image for project: 'Contributions'
  1. Contributions
  2. CONTRIB-2

Help Desk BOT- Call routing design pattern implementation using single application end-point alias

    Details

    • Type: Project Contribution
    • Status: Contributed
    • Priority: Medium
    • Resolution: Done
    • Labels:

      Description

      ABSTRACT
      Help Desk BOT will be a Java based application that implements call routing workflow based framework leveraging the Symphony API.

      PROPOSAL
      To implement a common design pattern which supports a call routing workflow from a named end-point (network user) to an application (BOT) end-point named alias (operator/call router), which routes to a rota of other named user end-points who service the call.

      • All communications from initiating user end-points to application end-point are private.
      • All communications from the application end-point to the rota of servicing user end-points are shared. Rules can be applied to prevent communications between servicing users.
      • The application end-point will maintain session state with all end-points.
      • The application end-point will have additional programmatic workflow hooks to support other implementations. These include event listeners and interfaces through the life-cycle of call handling.
        e.g. Connect, Validation, Session, Message, Rules, Context, Commands, Termination

      Simple Callback View:
      U(User) < - - > O(Operator)< - > R(Rota of Users/members)
      (~~~~~) <- - - - - - - - - - - - - - - -Ru(Rota User callback, direct)

      Advanced Proxy Callback View:
      U(User) < - - > O(Operator)< - - > R(Rota of Users/members)
      (~~~~~~~~~~~~~~~~~~~~)< - - >Ru(Rota User callback, proxy through O)

      For the purposes of this proposal, we shall call this implementation the Help Desk BOT, which introduces additional features to support the servicing of customers. These features are an extension of the base framework life-cycle interfaces.

      • Support of multiple alias end-points (operators), dynamically configured through management provisioning.
      • Query management:
        -Extension of individual sessions to store and manage queries. Pending, Active (serviced) and closed (history)
        -Map of all sessions/outstanding queries.
        -Message based control commands for servicing users (@take @queue @active)
      • History functions and metrics

      BACKGROUND
      This is a common workflow design pattern that has been implemented over many unified communication networks in the past. The development and concepts around this implementation where born out of an XMPP component implementation of MUC (Multi-user-chat XEP-0045), which will be converted to a single end-point application. In reality, this implementation will share common principals in a persistent multi-user-chat construct, but with the focus on underlying framework for future use. The workflow pattern has been historically coined as a "virtual desk" as the intention is to represent a group of users around a specific context. This context is represented as the aliased user (single destination) and can be constructed and torn down dynamically.

      Rationale
      This is the first of many workflow patterns which should be standardized for the community. Implementing this in a consistent way will benefit many other use cases and adoption.

      CORE DEVELOPERS

      Project Lead: Frank Tarsillo
      Contributors: Frank Tarsillo, TBD 1 External in conjunction with Paul Teyssier (Symphony), Rob Wisniewski (Symphony), Matt Harper (Symphony)

      INITIAL GOALS

      • Logical design mapping and interface definition
      • Sizing, requirements breakdown, roadmap
      • Core life-cycle construct implementation.
      • Contributor engagement and rhythm.

      Design Decisions
      *The intention is to leverage Apache Camel as a base framework for endpoint management (component), routing and exchange. An ideal solution would be the implementation of a Symphony camel component (client of Symphony leveraging the Agent API) for this project and future use. In the event such a component is constructed as part of this effort, the component itself should be contributed back to Apache Camel through the Symphony foundation.

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                ftarsillo Frank Tarsillo
                Reporter:
                ftarsillo Frank Tarsillo
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 4 weeks
                  4w
                  Remaining:
                  Remaining Estimate - 4 weeks
                  4w
                  Logged:
                  Time Spent - Not Specified
                  Not Specified