Future integration and deployment

Smack Smack Dev
1

Hi all,

I’'m currently reviewing a feature-set for one of my future applications, and wish to develop an online help system using jabber (and Smack libs), and would like the user to simply be able to click on the help tab from the menu and select “online help”. This would then load up a separate Window which would display an interface which would allow the user to chat to any of the help team (who are currently connected to the jabber network).

My question is, how would I be able to let the user chat to help admins if the user does not have their own jabber account? I do not want to get the user to register for an account just to talk to the help team…and hard coding an account would throw off any other users using the same application at that point in time. So is it possible to some way either bypass login and chat with a local guest account or I suppose create a component which tries to register a dynamic account the first time the application is launched?

Feedback would be very much appreciated.

Regards,

Antony

2

Hi,

There are a few ways to tackle the problem. The first is to create a guest account. Then all anonymous chat sessions login to the guest account under different resources (just make the resource name equal the session id). On the agent side, you’‘ll need to make sure your agent clients keep chats with a person directed to only their full jid with resource otherwise messages will be routed to other anonymous guests (there is still a possibility of this happening with this mechanism but it’‘s unlikely… and you can filter out messages sent to a different resource in the client so that the end user doesn’'t see these misrouted messages).

The cleaner method is to use anonymous authentication. This is supported by the XMPP/Jabber protocols but is rarely turned on in servers due to the possibility of abuse. However, if you can set up your server to accept anonymous authentication and protect that port from connections not coming from your JSPs it’'s the best solution. Messages will be cleanly handled without the need for workarounds as in the first method.

The last possibility is to create a new account on the server when an anonymous user logs in. This may be a good way to get the user to register on the site and you can always make the client create a random account if you don’‘t want to force the user to create a real account. However, this approach will result in a lot of ‘‘dead’’ accounts on your server that you’'ll have to clean out periodically.

-iain

3

Antony,

I think Iain covered the client side pretty well, but there is also the operator side to consider (by operator, I mean the support people). To make the system an elegant one, what you really need is a routing engine so that support requests are passed to the appropriate operator. For example, there could be a Jabber alias "support@acme.com". Any chat request to that alias would then be routed to a support person. Rules around this might include:

  • Do round-robin routing, but never let a an operator have more than X simultaneous chats.

  • Give the operator a certain amount of time to respond to the chat request before routing it to another operator.

  • Chats will only be routed to operators when they’'ve set their presence to be available for support requests.

  • CRM data might play a role in routing decisions. For example, if the customer has a license to the Enterprise version of the product, they might be automatically routed to a more senior support person if one is available.

Obviously, a standard Jabber server doesn’‘t support any of this behavior. However, this is one of the areas of functionality that we’‘re planning on targeting with our XMPP server solution, Jive Messenger. We also plan to support these extensions with a Smack add-on so that you could easily embed all this functionality into an existing application. If you’'re interested in discussing this functionality with us further, please drop me an email.

Thanks,

Matt

4

Thank you both for providing very detailed replies!!

Iain - Anonymous authenication sounds like the ideal solution, but I have not had time as of yet to investigate the jabberd server implementation. I’‘m also currently in the process of building a small linux machine on which I can conduct all my server testing. This is likely to take another 2 months though (as I am awaiting specific hardware components with long lead times). Therefore, anon authentication is not possible just at the moment. I had originally thought about the creation of a new account each time an anon user logs on, but as you said, this would be a very inefficient method and I just wouldn’'t be happy knowing there are better ways around the problem.

So, I feel that the guest account (with resource specified by the unique application id created on first run of the product), would suit my situation best. Before your post, I hadn’'t realised what the resource parameter could be used for - now I know. You note that there will still be a slight chance of a message being routed to all other guests, under what specific circumstances would this happen? Is there anything else that can be done to minimise or totally remove the chance of this effect occuring (but I suppose the client-side filtration system you mentioned would solve all these problems - correct?)?

5

Matt - Yes, the operator side is also an important aspect which I hadn’'t really considered until now.

I’'m a partner of a SME, and am in charge of all IT related developments. I will soon begin building a web & application based system for a business-2-business project. I want to allow the company the option of “nearly anytime help”, so if they have any problems or questions they can use the system briefly described in my first post to contact one of a small number of number of my advisory team. This team will consist of a small number of people (3-4), with I as the main person in charge of all technical support and related questions.

You mention a number of “rules” in your posting, which I find very logical and hadn’‘t really thought about at all until you brought the subject to view. I’'m thinking of rules such as “always try to go to primary helpdesk operator (i.e. me), then, if no answer within a set period of time, retransmit message to secondary helpdesk users”. Just a thought.

A Smack add-on would be very cool! Any ideas as to when you may begin to add these extensions to the Smack libs?

It certainly appears as if you guys have been thinking quite deeply about the kind of features I’'m looking to implement and it would be great to know what other features your looking into.

Cheers,

ribot.

6

You mention a number of “rules” in your posting,

which I find very logical and hadn’'t really thought

about at all until you brought the subject to view.

I’'m thinking of rules such as "always try to go to

primary helpdesk operator (i.e. me), then, if no

answer within a set period of time, retransmit

message to secondary helpdesk users". Just a

thought.

Yep, that definitely makes sense. Our plan is to have a pluggable routing engine that has a number of useful presets, but also allows you to define your own routing rules.

A Smack add-on would be very cool! Any ideas as to

when you may begin to add these extensions to the

Smack libs?

The routing engine and rules definition will all be in our server, Jive Messenger. So, once the functionality is available there, we’‘ll begin work on the Smack extensions. Again, if you’'re interested in participating early in this process, please drop me an email.

Regards,

Matt

7

also currently in the process of building a small

linux machine on which I can conduct all my server

testing. This is likely to take another 2 months

though (as I am awaiting specific hardware components

with long lead times). Therefore, anon

Cool. As you may know, we have an XMPP server, Jive Messenger, in development (pure Java). Anonymous authentication isn’‘t implemented mainly for security reasons (we need time to figure out how to make it manageable). For XMPP development, it’‘s an ideal, XMPP server that runs easily on any platform with Java 1.3 or later. Smack is being developed against Jive Messenger so you can expect features to appear in parallel between the two… I’'ll add anonymous authentication to our issue tracker.

So, I feel that the guest account (with resource

specified by the unique application id created on

first run of the product), would suit my situation

best. Before your post, I hadn’'t realised what the

resource parameter could be used for - now I know.

You note that there will still be a slight chance of

a message being routed to all other guests, under

what specific circumstances would this happen? Is

XMPP tries to route messages to a jid with a best effort algorithm. A message sent to user@server.com/resource goes to that particular resource if it is online. However if a message is sent to a resource that is not available, the message is routed as if the message was sent to user@server.com. In other words, the message is transmitted to the ‘‘preferred’’ resource, determined by highest seen by the server in a presence packet from a particular resource.

So the most typical scenario for packets to get redirected to the wrong client would be if your agent were chatting with a user anon@server.com/clientA and anon@server.com/clientB and clientA logs off and the agent sends another message not realizing clientA has logged off. Then the server will see clientA unavailable and reroute it to clientB.

there anything else that can be done to minimise or

totally remove the chance of this effect occuring

(but I suppose the client-side filtration system you

mentioned would solve all these problems -

correct?)?

I was thinking about that. One possibility would be to actually have everyone log in to one account with different resources as discussed earlier. However, instead of conducting one-on-one chats, each customer’‘s client actually joins a unique groupchat room and sends an invitation to the agent’‘s client to join that chatroom. The agent’‘s client will join the chatroom and then messages sent to the chatroom will show up in both agent and customer’‘s clients. When the customer wants, they can log off by leaving the chatroom and then logging out. It’'s importantant that they leave the chatroom first. That makes sure that any messages that the agent sends to the chatroom stay in the chatroom rather than get transmitted to the customer. Since no groupchat messages go to the customer when they are not in a chatroom, this should prevent any stray messages from ever being sent to that user.

Chatrooms are also nice because you can have multiple participants join the chat. This would allow an agent to invite another agent to join the chat which could be useful. In addition, you could invite a simple chatbot client to the room that could automatically log everything in the chatroom to a database or logfile or to listen in on the conversations and automatically provide information. For example, if you go into a conference.jabber.org chatroom and type ‘’?? query’’ without the quotes and with query being what you want to know about like ‘’?? XMPP’’ you’‘ll see a chatbot answer). Or try ‘’!time’’ to get the time from another chatbot. This may be a great tool for agents to easily send common information from a faq or something to the user in a chat session.

Hope that helps.

-iain

8

Hi,

Thought I should point out that all of these alternate workarounds are going to be a bit of a hack. It should work for the limited case we’'ve been discussing but may cause future problems when you want to extend the system to accommodate more advanced features (CRM, email, call center, etc).

We (Jive) have been thinking about these issues and begun discussions with select customers to create an elegant solution that meets support system needs in the Jive tradition: pure Java, extensible, flexible, skinnable, and pluggable. XMPP, forums, and kb would individually and as an integrated whole, work to make your life easier in rolling out support solutions.

For XMPP, we’‘re already planning some advanced server side behavior (pluggable routing rules, configurable JID aliases, etc) and XMPP extension protocols to make this happen. If you’'re interested in learning more, please feel free to email me.

-iain

9

Matt -

Sorry about not replying earlier, I’'ve been on a 7 day training holiday running at least 15k a day.

Yep, that definitely makes sense. Our plan is to have

a pluggable routing engine that has a number of

useful presets, but also allows you to define your

own routing rules.

Right, sounds like a good plan! I personally always try to make systems as dynamic and flexible as possible within my limits, and it sounds like you guys are working by the same ethics.

The routing engine and rules definition will all be

in our server, Jive Messenger. So, once the

functionality is available there, we’'ll begin work on

the Smack extensions. Again, if you’'re interested in

participating early in this process, please drop me

an email.

I’‘ll probably include some of these questions in my email to you, but could you briefly outline the purpose and goals of Jive Messenger and how it will/does integrate with other current and future products. I would be more than happy to help with regard to early progression of these products - I’'ll send you an email later today.

Thanks for taking so much time to answer all my questions.

Regards,

Antony

10

Iain -

As I said to Matt, sorry for the delay in my reply.

Cool. As you may know, we have an XMPP server, Jive

Messenger, in development (pure Java). Anonymous

authentication isn’'t implemented mainly for security

reasons (we need time to figure out how to make it

manageable). For XMPP development, it’'s an ideal,

XMPP server that runs easily on any platform with

Java 1.3 or later. Smack is being developed against

Jive Messenger so you can expect features to appear

in parallel between the two… I’'ll add anonymous

authentication to our issue tracker.

Pure Java always rocks! Thanks for adding the anon authentication to the list!

XMPP tries to route messages to a jid with a best

effort algorithm. A message sent to

user@server.com/resource goes to that particular

resource if it is online. However if a message is

sent to a resource that is not available, the message

is routed as if the message was sent to

user@server.com. In other words, the message is

transmitted to the ‘‘preferred’’ resource, determined

by highest seen by the server in a

presence packet from a particular resource.

So the most typical scenario for packets to get

redirected to the wrong client would be if your agent

were chatting with a user anon@server.com/clientA and

anon@server.com/clientB and clientA logs off and the

agent sends another message not realizing clientA has

logged off. Then the server will see clientA

unavailable and reroute it to clientB.

I see, sounds like a simple enough process to me. Have you any other algorithms in development worth mentioning?

I was thinking about that. One possibility would be

to actually have everyone log in to one account with

different resources as discussed earlier. However,

instead of conducting one-on-one chats, each

customer’'s client actually joins a unique groupchat

room and sends an invitation to the agent’'s client to

join that chatroom. The agent’'s client will join the

chatroom and then messages sent to the chatroom will

show up in both agent and customer’'s clients. When

the customer wants, they can log off by leaving the

chatroom and then logging out. It’'s importantant that

they leave the chatroom first. That makes sure that

any messages that the agent sends to the chatroom

stay in the chatroom rather than get transmitted to

the customer. Since no groupchat messages go to the

customer when they are not in a chatroom, this should

prevent any stray messages from ever being sent to

that user.

Chatrooms are also nice because you can have multiple

participants join the chat. This would allow an agent

to invite another agent to join the chat which could

be useful. In addition, you could invite a simple

chatbot client to the room that could automatically

log everything in the chatroom to a database or

logfile or to listen in on the conversations and

automatically provide information. For example, if

you go into a conference.jabber.org chatroom and type

‘’?? query’’ without the quotes and with query being

what you want to know about like ‘’?? XMPP’’ you’'ll see

a chatbot answer). Or try ‘’!time’’ to get the time

from another chatbot. This may be a great tool for

agents to easily send common information from a faq

or something to the user in a chat session.

The group chat was one of the idea’‘s I too was thinking about. The way you describe it, it does seem like a very viable solution to the routing problem, but one that I may have to test before making a final decision. Thanks for the extra info regarding queries in the chatroom - I didn’'t even realise these existed.

Hope that helps.

Yes, thank you ever so much, I’'ve got lots more ideas flying around in my head now due to this very informative discussion. Thank you for taking the time to make all this information clear to me and any others who read this thread.

Regards,

Ribot