[sip-comm] Which port I have to open on my routr for SIP and Jabber?


#1

Hello *,

my FreeSWITCH (SIP) and eJabber where in a DMZ but now I have installed
it on two dedicated servers (TI OMAP3530) and nothing is working... :-/

Please can someone tell me which ports I have to forward from my router
to FreesSWICH and reverse and the same for the Jabber server?

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

signature.pgp (189 Bytes)

···

--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/> Michelle Konzack
<http://www.can4linux.org/> Apt. 917
<http://www.flexray4linux.org/> 50, rue de Soultz
Jabber linux4michelle@jabber.ccc.de 67100 Strabourg/France
IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
ICQ #328449886 Tel. FR: +33 6 61925193


#2

It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#3

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:

···

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktfFXMACgkQrlZ/rySPZHoVrQCeNhDdYBbhIe6z7PRAEWEXlLAi
RQ0An2IEmetHM5gJRv08RBsEMovCEmag
=M6tV
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#4

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:
It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

- --
Regards,
Kertesz Laszlo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#5

Hello,

It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

You are right...

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):

Here pidgin/kphone too, but only Linux. I am trying to switch to SIP-
Communicator but failed. No file fransfer in Jabber and SIP can not
connect to FreeSWITCH.

Also SIP-Comm write arround 15 MByte/day of crap in my .xsession-errors.

I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

OTR is not workin for me, so I switched back to pidgin, where OTR is not
working too but the "pidgin-encryption 3.0" RSA plugin.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

Here exactly the same: SIP-Communicator and Pidgin.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

Hmmm... waiting for answers!

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

signature.pgp (189 Bytes)

···

Am 2010-01-26 18:16:51, schrieb Kertesz Laszlo:

--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/> Michelle Konzack
<http://www.can4linux.org/> Apt. 917
<http://www.flexray4linux.org/> 50, rue de Soultz
Jabber linux4michelle@jabber.ccc.de 67100 Strabourg/France
IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
ICQ #328449886 Tel. FR: +33 6 61925193


#6

Could you please open an issue for this? Someone will look into it when
possible.

Thanks,
Emil

Kertesz Laszlo написа:

···

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:
It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

- --
Regards,
Kertesz Laszlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktfHHYACgkQrlZ/rySPZHqD6wCgwJYSmX9ZConibk2J9hvIT7kX
fHMAn3+NhN1fmH67iSdwnBu6RQ0UO/Uf
=CeiB
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#7

Could it be a port forwarding issue? It is possible that file transfer uses port
7777 or 8010 or other and not 5222.
Using out-of-band file transfer sometimes requires a file transfer proxy server,
if behind a NAT. Psi only supports out-of-band transfers.

The most popular proxies are "proxy.jabber.org:7777" (hosted by the Jabber Foundation <http://www.jabber.org/>)
and "proxy64.jabber.ccc.de" (hosted by the Chaos Computer Club <http://www.ccc.de/> from germany). Also
you can look if your XMPP Server provides his own proxy, by doing a Service Discovery
on your XMPP Server. If you see something like "SOCKS5 Bytestreams Service"
you can enter the corresponding JID as "Data Transfer Proxy".

Maybe you need to configure in the clients the "file transfer proxy address".

Earl

Kertesz Laszlo wrote:

···

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:
  

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:
It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net
  
- -- Regards,
Kertesz Laszlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktfHHYACgkQrlZ/rySPZHqD6wCgwJYSmX9ZConibk2J9hvIT7kX
fHMAn3+NhN1fmH67iSdwnBu6RQ0UO/Uf
=CeiB
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#8

I did some further testing. Interesting results.

I tested Sip Communicator - Sip Communicator file transfer with larger files, both with 2
(different) jabber users on the local server, both computers in the same switch (Gigabit switch, but
one computer had only 100 Mbs connection).

Nevertheless, the file transfer was 39 KB/s constant (yes, 39 kilobytes). That would mean that the
files were transferred inband?

With Pidgin, with 2 comps (both with gigabit LAN adapters, in Gigabit switch we had 30-40 MB/s -
thats megabytes/seconds - transfer rate).

And i might left this information out previously, but we do use our server as a file transfer proxy.
And we have specified this in pidgin's configuration.

Also, pidgin - empathy file transfer works well (7-8 MB/s transfer rate on fast ethernet (100 MB/s).

P.S. Quite interestingly OTR works with Pidgin without problems.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#9

From a forum:

And on client side, if you want to transfer files, you have to turn on this option and
set fields (for client Psi)

- in global settings - set port for data transfer

- in global settings - set field "External address for data transfer" as proxy.
<server domain name>

- in account settings, "Misc" tab - set field "Proxy server for data transfer" as proxy.
<server domain name>

For now, I have successful results with Psi.
Clients, based on libpurple, have a bug with transfer files through NATs and firewalls
- they cannot detect public server IP (I think so, but it's may be a my bug in settings...)

I hope this solution will be helpful for anyone who have same problems : )

End of forum quote.---------------------

Notice that with Jabber when talking about proxies, it is always file transfer proxy
*NOT* connection or signaling proxy. NATs can cause Jabber file transfer problems.

Regards, Earl

Earl wrote:

···

Could it be a port forwarding issue? It is possible that file transfer uses port
7777 or 8010 or other and not 5222.
Using out-of-band file transfer sometimes requires a file transfer proxy server,
if behind a NAT. Psi only supports out-of-band transfers.

The most popular proxies are "proxy.jabber.org:7777" (hosted by the Jabber Foundation <http://www.jabber.org/>)
and "proxy64.jabber.ccc.de" (hosted by the Chaos Computer Club <http://www.ccc.de/> from germany). Also
you can look if your XMPP Server provides his own proxy, by doing a Service Discovery
on your XMPP Server. If you see something like "SOCKS5 Bytestreams Service"
you can enter the corresponding JID as "Data Transfer Proxy".

Maybe you need to configure in the clients the "file transfer proxy address".

Earl

Kertesz Laszlo wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:
It seems the Jabber/XMPP protocol specifications are differently implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the local network (on which the
jabber server is). We were using OTR. But i remember other occasions when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification that the file transfer is
initiated by the other), but when accepting, the file transfer doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#10

Also, when i sent files Sip Communicator -> Sip Communicator, if the receiver cancelled the file
transfer, the sender didnt aknowledged it and the file sending continued on the senders part.

Kertesz Laszlo wrote:

I did some further testing. Interesting results.

I tested Sip Communicator - Sip Communicator file transfer with larger files, both with 2
(different) jabber users on the local server, both computers in the same switch (Gigabit switch, but
one computer had only 100 Mbs connection).

Nevertheless, the file transfer was 39 KB/s constant (yes, 39 kilobytes). That would mean that the
files were transferred inband?

With Pidgin, with 2 comps (both with gigabit LAN adapters, in Gigabit switch we had 30-40 MB/s -
thats megabytes/seconds - transfer rate).

And i might left this information out previously, but we do use our server as a file transfer proxy.
And we have specified this in pidgin's configuration.

Also, pidgin - empathy file transfer works well (7-8 MB/s transfer rate on fast ethernet (100 MB/s).

P.S. Quite interestingly OTR works with Pidgin without problems.

- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

- --
Regards,
Kertesz Laszlo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#11

For some reason (probably because we changed our local mail server and things were a bit messed up
for some time) i was removed from the mailing list and i received the notification today. I
subscribed now with my gmail account. That's why i reply this late.

I remade the tests and i have the same results - 39 KB/s, no acknowledgement of the receiver's
cancel. I attached a screenshot of the receiving users window and the logs.

The test was - starting Sip Communicator with only the jabber accounts, sending a file
(nations_pride.flv, 13.8 MB)

Sender - Debian Squeeze on laptop with wireless connection (i reached 2.6 MB/s transfer rates on it
via sftp, so its not the issue).
Receiver - Debian Squeeze on desktop with 1 GB/s connection.
Sip Communicator version 2393.

Both computers are connected to the same gateway in the same local network. The jabber server is
OpenFire 3.6.3. Note that Pidgin to Pidgin file transfers work both ways.

Also, now sending files from Pidgin to Sip Communicator is working with high speed (2.6 MB/s or so
in my case). The reverse is not working, the transfer just hangs, just as before.

Regards,

Kertesz Laszlo

Hi,

I have made several tests with file transfer and jabber, and the strange
thing is that I got different results from the one you provided.

1. Sip Communicator -> Sip Communicator, working fine cancel on both sides
is dispatched as expected, speed ~500KiB/s.
2. Sip Communicator -> Pidgin, working fine cancel on both sides is
dispatched as expected, speed ~500KiB/s.
3. Pidgin -> Sip Communicator cannot send as pidgin complains that the other
party doesn't support file transfer, and some Pidgin logs :
(12:30:39) jabber: Unable to find caps: nothing known about buddy
(12:30:39) jabber: Unable to find caps: nothing known about buddy
(12:30:39) jabber: jabber_si_xfer_free(): freeing jsx 0x22f9e00
(12:30:39) jabber: in jabber_si_xfer_cancel_send

I will investigate that and see how we can fix this.

My test environment:
both clients on the same network
Sip Communicator - latest svn
Pidgin - 2.6.2.
Server Openfire 3.6.4 accessed over Internet.

damencho

receiver-sip-communicator0.log.0 (314 KB)

sender-sip-communicator0.log.0 (208 KB)


#12

Well the idea is to keep everything within our internal network. Our server works only in our
internal LAN. All of us have VPN access to the network. Everything is routed internally.
We have a Trixbox (Asterisk) SIP server and a Openfire (jabber) server in the network.
The policy is to keep everything (text messages, file transfers and voice calls) within the network.

We would have used Skype (instead of jabber+SIP) because that works in every scenario...

Earl wrote:

From a forum:

And on client side, if you want to transfer files, you have to turn on
this option and
set fields (for client Psi)

- in global settings - set port for data transfer

- in global settings - set field "External address for data transfer" as
proxy.
<server domain name>

- in account settings, "Misc" tab - set field "Proxy server for data
transfer" as proxy.
<server domain name>

For now, I have successful results with Psi.
Clients, based on libpurple, have a bug with transfer files through NATs
and firewalls
- they cannot detect public server IP (I think so, but it's may be a my
bug in settings...)

I hope this solution will be helpful for anyone who have same problems : )

End of forum quote.---------------------

Notice that with Jabber when talking about proxies, it is always file
transfer proxy
*NOT* connection or signaling proxy. NATs can cause Jabber file
transfer problems.

Regards, Earl

Earl wrote:

Could it be a port forwarding issue? It is possible that file
transfer uses port
7777 or 8010 or other and not 5222.
Using out-of-band file transfer sometimes requires a file transfer
proxy server,
if behind a NAT. Psi only supports out-of-band transfers.

The most popular proxies are "proxy.jabber.org:7777" (hosted by the
Jabber Foundation <http://www.jabber.org/>)
and "proxy64.jabber.ccc.de" (hosted by the Chaos Computer Club
<http://www.ccc.de/> from germany). Also
you can look if your XMPP Server provides his own proxy, by doing a
Service Discovery
on your XMPP Server. If you see something like "SOCKS5 Bytestreams
Service"
you can enter the corresponding JID as "Data Transfer Proxy".

Maybe you need to configure in the clients the "file transfer proxy
address".

Earl

Kertesz Laszlo wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but
not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer
notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on
the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:
It seems the Jabber/XMPP protocol specifications are differently
implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of
us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the
local network (on which the
jabber server is). We were using OTR. But i remember other occasions
when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification
that the file transfer is
initiated by the other), but when accepting, the file transfer
doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no
confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip
Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

- --
Regards,
Kertesz Laszlo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#13

Hi,

I have made several tests with file transfer and jabber, and the strange
thing is that I got different results from the one you provided.

1. Sip Communicator -> Sip Communicator, working fine cancel on both sides
is dispatched as expected, speed ~500KiB/s.
2. Sip Communicator -> Pidgin, working fine cancel on both sides is
dispatched as expected, speed ~500KiB/s.
3. Pidgin -> Sip Communicator cannot send as pidgin complains that the other
party doesn't support file transfer, and some Pidgin logs :
(12:30:39) jabber: Unable to find caps: nothing known about buddy
(12:30:39) jabber: Unable to find caps: nothing known about buddy
(12:30:39) jabber: jabber_si_xfer_free(): freeing jsx 0x22f9e00
(12:30:39) jabber: in jabber_si_xfer_cancel_send

I will investigate that and see how we can fix this.

My test environment:
both clients on the same network
Sip Communicator - latest svn
Pidgin - 2.6.2.
Server Openfire 3.6.4 accessed over Internet.

damencho

···

On Thu, Jan 28, 2010 at 3:50 PM, Kertesz Laszlo < laszlo.kertesz@infobenefic.ro> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Also, when i sent files Sip Communicator -> Sip Communicator, if the
receiver cancelled the file
transfer, the sender didnt aknowledged it and the file sending continued on
the senders part.

Kertesz Laszlo wrote:
> I did some further testing. Interesting results.
>
> I tested Sip Communicator - Sip Communicator file transfer with larger
files, both with 2
> (different) jabber users on the local server, both computers in the same
switch (Gigabit switch, but
> one computer had only 100 Mbs connection).
>
> Nevertheless, the file transfer was 39 KB/s constant (yes, 39 kilobytes).
That would mean that the
> files were transferred inband?
>
> With Pidgin, with 2 comps (both with gigabit LAN adapters, in Gigabit
switch we had 30-40 MB/s -
> thats megabytes/seconds - transfer rate).
>
> And i might left this information out previously, but we do use our
server as a file transfer proxy.
> And we have specified this in pidgin's configuration.
>
> Also, pidgin - empathy file transfer works well (7-8 MB/s transfer rate
on fast ethernet (100 MB/s).
>
>
>
> P.S. Quite interestingly OTR works with Pidgin without problems.

- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

- --
Regards,
Kertesz Laszlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkthlikACgkQrlZ/rySPZHoncQCfUJkJutnVipAASuCdVALStBoU
64MAni4iJIjuaCwCphOfVpBQD2CQMKBr
=j/JL
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#14

If using VPN to access LAN and wish to keep everything internal, this is secure
and has no NAT. So in theory things should work.

Skype has a central log-in server where keys are generated and given to the
client, so this system can not be considered to be secure. And who knows if
Skype contains a trojan or invisible VPN? Easy to use, works great, but no
security.

If things do not work with Jabber in your VPN, there is a good chance that it
is a routing problem. A Unix friend of mine needs to do the opposite; use his
VPN to get from company LAN to the Inet. He has Jabber connectivity now
using his VPN, but he needed to add a route statement somewhere to get it to
connect to Jabber server outside his firewall.

If file transfer works OK on the LAN, but not over the VPN, then most likely
a routing statement missing. If file transfer does not work internally on the LAN
check that all clients are configured to use the same port for file transfer.
Openfire has a parameter xmpp.proxy.enabled, which can be set true or false.
Maybe for VPN this must be set to false ???
The OpenFire server and all clients must have the same configuration concerning
file transfer ports and parameters.
Probably server and clients must all support out-of-band file transfer method.

If file transfer problem happens LAN to LAN, you might also look at the support
forum for OpenFire. Maybe someone has already solved this problem or can
help you. http://www.igniterealtime.org/community/index.jspa or
http://www.igniterealtime.org/community/community/support/openfire_(formerly_wildfire)_support
and enter >file transfer< in search box.

A test using the ejabberd server might provide useful information. Use port 52222
for ejabberd with test clients the same and see what happens with file transfer on
LAN and via VPN. http://www.ejabberd.im/
Of course, ejabberd and all clients will have to be configured to have same file transfer
settings.

Good luck.

Earl

Kertesz Laszlo wrote:

···

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well the idea is to keep everything within our internal network. Our server works only in our
internal LAN. All of us have VPN access to the network. Everything is routed internally.
We have a Trixbox (Asterisk) SIP server and a Openfire (jabber) server in the network.
The policy is to keep everything (text messages, file transfers and voice calls) within the network.

We would have used Skype (instead of jabber+SIP) because that works in every scenario...

Earl wrote:
  

From a forum:

And on client side, if you want to transfer files, you have to turn on
this option and
set fields (for client Psi)

- in global settings - set port for data transfer

- in global settings - set field "External address for data transfer" as
proxy.
<server domain name>

- in account settings, "Misc" tab - set field "Proxy server for data
transfer" as proxy.
<server domain name>

For now, I have successful results with Psi.
Clients, based on libpurple, have a bug with transfer files through NATs
and firewalls
- they cannot detect public server IP (I think so, but it's may be a my
bug in settings...)

I hope this solution will be helpful for anyone who have same problems : )

End of forum quote.---------------------

Notice that with Jabber when talking about proxies, it is always file
transfer proxy
*NOT* connection or signaling proxy. NATs can cause Jabber file
transfer problems.

Regards, Earl

Earl wrote:
    

Could it be a port forwarding issue? It is possible that file
transfer uses port
7777 or 8010 or other and not 5222.
Using out-of-band file transfer sometimes requires a file transfer
proxy server,
if behind a NAT. Psi only supports out-of-band transfers.

The most popular proxies are "proxy.jabber.org:7777" (hosted by the
Jabber Foundation <http://www.jabber.org/>)
and "proxy64.jabber.ccc.de" (hosted by the Chaos Computer Club
<http://www.ccc.de/> from germany). Also
you can look if your XMPP Server provides his own proxy, by doing a
Service Discovery
on your XMPP Server. If you see something like "SOCKS5 Bytestreams
Service"
you can enter the corresponding JID as "Data Transfer Proxy".

Maybe you need to configure in the clients the "file transfer proxy
address".

Earl

Kertesz Laszlo wrote:
      

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but
not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer
notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on
the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo написа:
It seems the Jabber/XMPP protocol specifications are differently
implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of
us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the
local network (on which the
jabber server is). We were using OTR. But i remember other occasions
when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification
that the file transfer is
initiated by the other), but when accepting, the file transfer
doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no
confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip
Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktf+VoACgkQrlZ/rySPZHomZACeMSBoCEOYpsGCUgo6kImDNb+H
AgoAnRDRRMRYhivesAATFX1nZwv//g6t
=XUSh
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#15

Routing is ok. File transfer works between Pidgin clients(pidgin/pidgin) and between Sip
Communicator clients (sip communicator/sip communicator). Its just that Sip Communicator cannot
exchange files with Pidgin.

Earl wrote:

If using VPN to access LAN and wish to keep everything internal, this is
secure
and has no NAT. So in theory things should work.

Skype has a central log-in server where keys are generated and given to the
client, so this system can not be considered to be secure. And who
knows if
Skype contains a trojan or invisible VPN? Easy to use, works great, but no
security.

If things do not work with Jabber in your VPN, there is a good chance
that it
is a routing problem. A Unix friend of mine needs to do the opposite;
use his
VPN to get from company LAN to the Inet. He has Jabber connectivity now
using his VPN, but he needed to add a route statement somewhere to get
it to
connect to Jabber server outside his firewall.

If file transfer works OK on the LAN, but not over the VPN, then most
likely
a routing statement missing. If file transfer does not work internally
on the LAN
check that all clients are configured to use the same port for file
transfer.
Openfire has a parameter xmpp.proxy.enabled, which can be set true or
false.
Maybe for VPN this must be set to false ???
The OpenFire server and all clients must have the same configuration
concerning
file transfer ports and parameters.
Probably server and clients must all support out-of-band file transfer
method.

If file transfer problem happens LAN to LAN, you might also look at the
support
forum for OpenFire. Maybe someone has already solved this problem or can
help you. http://www.igniterealtime.org/community/index.jspa or
http://www.igniterealtime.org/community/community/support/openfire_(formerly_wildfire)_support

and enter >file transfer< in search box.

A test using the ejabberd server might provide useful information. Use
port 52222
for ejabberd with test clients the same and see what happens with file
transfer on
LAN and via VPN. http://www.ejabberd.im/
Of course, ejabberd and all clients will have to be configured to have
same file transfer
settings.

Good luck.

Earl

Kertesz Laszlo wrote:
Well the idea is to keep everything within our internal network. Our
server works only in our
internal LAN. All of us have VPN access to the network. Everything is
routed internally.
We have a Trixbox (Asterisk) SIP server and a Openfire (jabber) server
in the network.
The policy is to keep everything (text messages, file transfers and
voice calls) within the network.

We would have used Skype (instead of jabber+SIP) because that works in
every scenario...

Earl wrote:

From a forum:

And on client side, if you want to transfer files, you have to turn on
this option and
set fields (for client Psi)

- in global settings - set port for data transfer

- in global settings - set field "External address for data transfer" as
proxy.
<server domain name>

- in account settings, "Misc" tab - set field "Proxy server for data
transfer" as proxy.
<server domain name>

For now, I have successful results with Psi.
Clients, based on libpurple, have a bug with transfer files through NATs
and firewalls
- they cannot detect public server IP (I think so, but it's may be a my
bug in settings...)

I hope this solution will be helpful for anyone who have same
problems : )

End of forum quote.---------------------

Notice that with Jabber when talking about proxies, it is always file
transfer proxy
*NOT* connection or signaling proxy. NATs can cause Jabber file
transfer problems.

Regards, Earl

Earl wrote:
   

Could it be a port forwarding issue? It is possible that file
transfer uses port
7777 or 8010 or other and not 5222.
Using out-of-band file transfer sometimes requires a file transfer
proxy server,
if behind a NAT. Psi only supports out-of-band transfers.

The most popular proxies are "proxy.jabber.org:7777" (hosted by the
Jabber Foundation <http://www.jabber.org/>)
and "proxy64.jabber.ccc.de" (hosted by the Chaos Computer Club
<http://www.ccc.de/> from germany). Also
you can look if your XMPP Server provides his own proxy, by doing a
Service Discovery
on your XMPP Server. If you see something like "SOCKS5 Bytestreams
Service"
you can enter the corresponding JID as "Data Transfer Proxy".

Maybe you need to configure in the clients the "file transfer proxy
address".

Earl

Kertesz Laszlo wrote:
     

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenFire 3.6.3.
The file transfer works Pidgin-Pidgin, Psi -> Sip Communicator, but
not Sip Communicator -> Psi ("An
error occured while sending file to user", no file transfer
notification in Psi).
And also works Pidgin <-> Sip Communicator if both programs run on
the same computer...
I an not sure if Pidgin uses Jingle.

Emil Ivov wrote:

Hey Kertesz,

Indeed, OTR is an unlikely cause.

What server were you using? We don't currently support Jingle file
transfers so transfers through GoogleTalk would probably not work.

Cheers,
Emil

Kertesz Laszlo =0?8A0:
It seems the Jabber/XMPP protocol specifications are differently
implemented in various jabber clients.

My issue is with Sip Communicator - Pidgin file transfers (most of
us our department use
pidgin-windows and Linux versions):
I did tests with the other party being logged from VPN, me in the
local network (on which the
jabber server is). We were using OTR. But i remember other occasions
when no OTR was used the same
thing happened.

Either way, the file transfer is initiated (you got the notification
that the file transfer is
initiated by the other), but when accepting, the file transfer
doesnt happens, just hangs. The file
is created however with a 0 bytes length. Just as if there is no
confirmation from the other side to
continue the download.

I did another test - I logged in from Pidgin with a user and Sip
Communicator as another on the same
computer and everything was working. With and without OTR.

Any ideas why this is happening and how can it be solved?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

- --
Regards,
Kertesz Laszlo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net