Standard Routing Proxy Broadcast (example: )

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.

An example would be a inbound message to the relay bot modifying the message with a prefix of the source user display name before sending it to all the destination users.

frank: message . --> Bot –> bot: frank: message → endpointA

→ 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 (example: )

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:

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

for detailed design and code that represents a few different examples.

Browser not supported