Get user offline when trying to send file from one Spark client to another


When I am trying to send a file from one Spark client to another I get a response saying that the client

is offline and the file transfer will be attempted once they are online, although they are both online.

Does anyone know what the issue is ? or has anyone had similar experience and resolved this ?

Best Regards,


What version of Spark do you use. Can you try with 2.6.0 Beta 2? What is the file extension (doc, zip, etc)? What is the size of the file? What server do you use and are there any download related settings changed?

Also are there any firewalls in play here. Both the server and client need to allow allow the transport ports openfre/spark want.

I’m using the 2.5.8 version of Spark. The Spark clients and the Openfire server (version 3.6.0a) are all running on the same linux box.

I’m using whatever default download settings there are.

The file I’m trying to transfer is a 50k jpg file.


I tried with the 2.6.0 Beta 2 version of Spark and am getting the same as well. The Spark clients and Openfire server (3.60a) are all running on the same

linux box. The clients are able to have a regular chat session fine.


Chat and file transfer use different ports. Have you allowed all ports listed in the admin site for Openfire.

The Spark client and server are on the same machine, so there are no firewall issues. (I can telnet to the 7777 port on the same machine with no issue)

try clients not on the same machine as the server.

Thanks for the suggestions - although, unfortunately I still get the same behavior when trying clients on different machines (I can telnet from one machine to the other on the port 7777)

I managed to get it to work once I added the user I’m sending the file to as one of the contacts.

I haven’t read through the relevant XEPP docs, but is this a requirement ?

I stumbled across it using the python jabber client and subscribing to the presence of the sending client.


Note well that the request to begin the stream is sent to the full JID
(user@host/resource) of the XMPP entity identified by the XMPP IRI/URI.
Therefore, the IRI/URI SHOULD include a full JID. If it does not, the
receiver MUST discover a full JID via presence or service discovery. If
the receiver cannot discover a full JID for the sender (e.g., in the
last resort through sending a presence subscription request to the
sender and receiving presence from the sender’s resources), then it
SHOULD abort the file transfer exchange.

Try sending the file to the full JID (username@servername/resource). As i understand the specs, if you can’t find out receiver’s full JID you should be subscribed to his presence.

Also you can try this with some other clients (on both sides), without adding a contact to a roster. You will have to unsubscribe first. So, maybe not only Spark is behaving like that.