It would be great if someone could take a look on these two attached
files if they do match the Jitsi code style convention. I tried to
keep them comaptible as much as possible, but still I might have
missed something. When they will be ok I will know how to fix the rest
I've just had a look. They are pretty much ok, except for the following:
- there are some lines exceeding (both in code and javadocs) the 80th column.
- there are some trailing spaces too. You should be able to show them using your IDE. In Eclipse you can find the option in Preferences > General > Editors > Text Editors - "Show whitespace characters"
Something that's not in the code convention, but can help code readability is to put some empty lines between unrelated code snippets. For example in GTalkFileShareManager.processPacket you can put a new line between consecutive ifs and declarations. Like here:
logger.debug("Terminate/reject request for: "
+ sessionIQ.getInitiator() + ":" + sessionIQ.getID());
String sessionID = sessionIQ.getID();
GTalkFileShareSession transferSession = sessions.get(sessionID);
if (transferSession == null)
logger.warn("Session " + sessionID + " not found");
// ACK received IQ
But this is just my personal feeling
Regards, Paweł Domas
Thanks for help ! I've fixed the rest of files to match these rules.
So regards the patch description.
I had to modify two manifest files to export Pseudo TCP functionality
to jabber package. These are:
net.java.sip.communicator.impl.netaddr.netaddr.manifest.mf <- added
<-- added import here
The packages that I modify are:
net.java.sip.communicator.impl.protocol.jabber - here are contained
all logic classes
net.java.sip.communicator.impl.protocol.jabber.extensions.gtalk - here
are classes responible for creating/parsing XMPP packets extensions
First thing that enables GTalk file transfers is property named
which have to be set to "true" to enable file transfers. The code
responsible for that is in class ProtocolProviderServiceJabberImpl.
General class hierarchy
The main class is GtalkFileShareManager. It exposes method to create
new transfer sessions and these are used from
OperationSetFileTransferJabberImpl to send a file. It also listens to
XMPP packets that initiate file transfer sessions and creates new
For each session we can have multiple transfers. For incoming sessions
there are also transfer requests which are converted into transfers
once the user accepts the transfer. Session are active as long as
there are any valid transfers/requests or until remote peer cancels
the session. We have following classes which create this hierarchy:
GTalkFileShareSession - base class for both incoming and outgoing sessions
GTalkIncomingFileSession - class represents incoming sessions and it manages:
GTalkIncomingFileTransferRequest - transfer request
GTalkIncomingFileTransfer - incoming file transfers
GTalkOutgoingFileSession - class for outgoing sessions that consits of many:
GTalkOutgoingFileTransfer - outgoing transfers
Now regards the connectivity establishement. Eeach file sharing
session uses the GTalkFileShareTransportManager. This class was
created out of the P2PTransportManager class which extends
I've been trying to extract some base class that could be used by both
file share sessions and P2PTransportManager however it is too much
dependent from CallPeer class. This class would have to encapsulate
basic ICE connectivity functions. However it ended up that I've
extracted methods for harvesting candidates and establishing
connectivity to GTalkFileShareTransportManager.
It uses common method for creating ICE agent that is
TransportManagerGTalkImpl.createAgent() so that I do not duplcate code
responsible for gathering harvesters.
I've created static utility methods in IceUdpTransportManager for
retrieving ICE datagram sockets and target addresses selected by ICE.
These are getStreamConnectorSockets and getStreamTargetAddresses in
IceUdpTransportManager. They are now shared with
For now I am using only UDP candidates as I don't know how to handle
TCP socket with current Pseudo TCP implementation. Also I filtered out
IPv6 candidates as I had errors when transferring files with Empathy.
The code responsible for that is in
Once the ICE connectivity is established files are transferred over
Psuedo TCP using some parts of HTTP protocol. For incoming file share
session this is done by GTalkIncomingFileTransfer class in method
httpGetFile(). Outgoing session are sharing single instance of
GTalkHTTPFileServer which sends all transfer files over HTTP.
The issue here is special characters encoding in URLs. I haven't found
appropriate method to convert them the same way as the GTalk client
does it. I've been trying some java URL classes and some Apache Http
methods, but with no luck. Currently the only thing I do is changing
spaces to %20.
That's all regards the logic. Now how are GTalk file sharing XMPP
packets plugged into the system.
This is done in SessionIQProvider. File sharing IQs are recognized by
the namespace: http://www.google.com/session/share
When "initiate" session IQ is received with that namespace it is
marked as a "filesharing" one. This is done in
SessionIQProvider.parseIQ method. I had to add a check for this
condition in OperationSetBasicTelephonyJabberImpl.acceptPacket() so
that telephony will reject these packets.
All extensions used by file sharing feature are parsed in SessionIQProvider.
The required capabilities are
"http://google.com/xmpp/protocol/share/v1" as a feature
and "share-v1" as an ext feature.
These are added in ProtocolProviderServiceJabberImpl if GTalk sharing
feature property is enabled.
To decide if remote peer supports file sharing I check if it support
at least one of these. That is probably wrong for the "ext" feature,
but the problem is that GTalk client is not propagating
http://google.com/xmpp/protocol/share/v1 feature at all, but it
requires it from other clients. It's only propagates only "ext"
feature as far as I've been able to check.
There is one issuse regards the capabilities. When Jitsi is started
and GTalk client will login after that, Jitsi will not cache this
"ext" feature properly. This may be because GTalk client is sending
these feature list 2 times. First time something like "voice-v1" and
immidiately after that "voice-v1 share-v1". When Jitsi logins after
GTalk client everything is ok.
That would be all regards the patch description. To sum it up there
are the following known issues:
- special characters are not encoded as they are in GTalk client, but
it will work with Jitsi<->Jitsi communication
- when GTalk client will login after the Jitsi, there is a problem
with detecting correct capabilities(as described above)
- when communicating with Empathy it sometimes sends invalid Pseudo
TCP packet and it occurs only when communicating with Jitsi (it's ok
between Empathy <-> GTalk as I checked it on Wireshark). The problem
is that first hello packet has 4 bytes of data when there should be
only 1. My stack considers this packet invalid. I checked that on
Empathy log and Pseudo TCP stack sends hello with single byte of data,
but there are 4 going out to the network.
GTalkFileTransfer.patch (185 KB)
2012/9/20 Yana Stamcheva <firstname.lastname@example.org>:
Regards, Paweł Domas