Standard Routing Proxy Broadcast
Ability to route messages to an endpoint (bot) on the Symphony network that relays ingress messages to a list of known egress endpoints.
The bot has the ability to manipulate messages prior to any relay to destination endpoints.
...
→ bot: frank: message → endpointB
Context Based Routing Proxy
This is equivalent to the routing proxy in design, but supports routing to a select number endpoints determined by the content in the message body. The ultimate use case being NLP and machine learning applicability to create smart message routing.
...
frank: "Can you reset my password" --> Bot [Evaluate Message] → (if "password") → bot: frank: message → endpointA
(if "other") → bot: frank: message → endpointB
Scaling through bot offloading
One of the most difficult issues on a collaboration network is scaling a single endpoint (bot) with MPOP (multiple points of presence) enabled. The point being multiple instance of the same bot would see all messages being sent, which defeats the purpose of increasing the number of instances. The solution is to implement the concept of offloading work to other worker bots. In XMPP and SIP/SIMPLE based networks this fairly trivial to implement, but the use of streams slightly limits the design pattern.
If we were dealing with a XMPP or SIP/SIMPLE network it would be handled using the following pattern:
Action 1 Form multi-party-conversation: frank: (message) → Bot ← (invite) BotWorker1 of N
Action 2 Bot leave multi-party-conversation: Bot Exit
End State 1:1 conversation: frank <--> BotWorker1
Since Symphony concept of streams identifies a unique combination of endpoints as single identifier. So in the example above, Action 1 would start off being a multi-party conversation with all participants joined from the start. Basically no way of starting in a 1:1 conversation and upgrading to multi-party without changing the stream (conversation). So what can we do?
Action 1 Bot routes request : frank: (message) —> Bot ---> (/join frank message) BotWorker1 of N (STREAM A)
Action 2 BotWorker1 calls back frank: BotWorker1→ frank (STREAM B)
Although this creates scale there are two different sessions created, which means "frank" would be receiving a response on a different session ("think chat window").
Virtual Desk
The idea here is to take the routing proxy concepts and extend to create virtual chat rooms ("desk") which control visibility of information, routing and controls between N endpoints.
This can be extended to support different modes of communications and use cases like help-desks and anonymous access to the networks.
Please See:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|