thank you for the reply for my email and sorry for disturbing - I
mistakenly sent it to you directly, not to the list.
No problem. Thanks for resending it here.
So currently after a week of shaman dances I somehow managed things to
work. But I'm still in doubt what was the reason for previous faults.
Probably the reason was a bug within Jitsi settings which I will
Here is what I did to make it work:
1) Freshly installed OpenFire server with Jingle Nodes plugin activated
(on the Jingle Nodes settings tab the IP address was verified and has a
Right. You need to watch out for that one. Sometimes, on multihomed
machines or IPv4/IPv6 double stacks you'd get the wrong address in
2) Activated my own OpenFire-STUN server with additional IP address (as
Not necessary. I am not sure we even use it the STUN server we learn
from XMPP. (Would need to check though)
3) Activated Media Proxy on OpenFire (though not sure if it was
required - it is not in use when a call is in progress).
I wouldn't do that. I think it may only work on raw udp, but it can
only screw up ICE so best leave it off.
4) In Jitsi settings I disabled all other accounts (I suppose it is
important that all XMPP-type accounts in Jitsi have the same
ICE/STUN/Jingle settings, probably that was another reason for previous
This shouldn't be a problem. Accounts and their ICE settings are
5) In Jitsi XMPP account configuration -> ICE Configuration tab, I
activated only the following settings (All other checkboxes are OFF):
- Use ICE
- Use Jingle Nodes
- Auto discover Jingle Nodes relays
For Additional STUN servers I added IP address of my OpenFire-STUN
Ah OK. I see now. We use stun.jitsi.net if you don't set one.
Either way, that would only matter for finding a direct route, other
than Jingle Nodes.
The same settings applied on all endpoints. I'm testing voice between
different Windows and MacOS servers and now it works well. On the
OpenFire server console in the Jingle Nodes tab I can see a number of
active sessions and all traffic properly relays through my OpenFire
Through the JingleNodes plugin?
Now for the bugs.
While playing with Jitsi settings I found another bug which prevented
JingleNodes from working:
while experimenting with different settings I put my server IP address
into Additional Jingle Nodes section. Probably this parameter should
have another syntax, but Jitsi failed to establish correct Jingle Nodes
session all the time after that. The problem is that I can not delete
this wrong entry from the GUI - Jitsi shows that it is deleted, but
actually it is not. After restart of Jitsi this setting appears there
again. I had to manually remove the parameter from
This bug is confirmed for both Windows and Mac versions of Jitsi.
Oh. Could you please open an issue for that?
But although it is working now, I still have little understanding of
the underlying technology and requirements.
Emil, would you be so kind please to comment my investigations and also
answer on the following questions (from my previous email):
1) Jitsi XMPP account configuration, ICE Configuration tab:
a) should I really have "Use ICE"
and "Use Google's Jingle/ICE"
No, not necessarily. Unless you want to call Google Talk users.
checkboxes set ON? Is Jinglenodes functionality somehow related to ICE?
It is. ICE is about gathering all your potentially usable addresses
(Candidates), sending them to your contact, retrieving theirs and
trying to check every one of them before settling on one that you have
confirmed to work.
This allows you to only use relay technologies, such as JingleNodes,
only in cases when there's no other way of communicating.
b) the same for STUN/TURN settings - should it all be enabled (i.e. is
it required for Jinglenodes to work)?
TURN is pretty much the same as Jingle nodes. It just has a different
protocol for allocating relay channels.
STUN is different. It gives you a possibility to connect to people
that are outside your network without using a relay. It wouldn't work
with all NATs though, which is why you need ICE. With it, you can fall
back to TURN or Jingle nodes if the addresses your learned from your
STUN server did not work.
c) do I have to manually add my own OpenFire-STUN server there?
Not necessarily. You can just use Jitsi's (i.e. if you don't uncheck
the "Use Jitsi's Stun server" box)
2) Additional Jingle Nodes setting:
a) do I have to manually add my OpenFire server there or it should find
and discover it automagically?
It will be discovered automatically. You only need to add relays there
if your server doesn't have one, or in case you want to have an extra
b) does it rely on some DNS SRV records for the domain or uses current
server connection and XMPP protocol for Auto discovery of jingle nodes?
We learn about JingleNode relays from the XMPP server. No SRVs are
involved their. We do however use DNS SRV when discovering domain STUN
and TURN servers. That's what the corresponding checkbox is about.
c) last very important question - if I want to manually add Additional
Jingle Nodes (i.e. my OpenFire server), should I put there just a
server IP? The field asks for "JID Address" which supposed to be
firstname.lastname@example.org, is it? I have no idea what would be the JID of
the Jingle Nodes plugin on my Open Fire server.
It should be the name of the component that your Jingle Nodes relay is
registered with. I think OpenFire's plugin uses "relay" by default,
which would give you "relay.example.com" for your server. We have
"relay.jit.si" for the jit.si service.
Note that "relay" is not an actual domain name. It's just an XMPP
Thank you very much in advance,
in the lack of JN documentation your comments would be highly
Well, hope it helps. Please let me know if you have other questions.
On Thu, Aug 9, 2012 at 3:55 PM, <email@example.com> wrote: