Hi ingo,
[quote ingo:]
Openfire does not care about the hostname.
The only difference the Jingle Nodes plugin makes between Windows and Linux is the IP binding of the relay channels: on Linux it binds on all interfaces, while on Windows it only uses the configured or detected public IP address.
[/quote]
I thought so too.
I won't dispute the Computer name method in Windows "works", until you step into VMs having host names auto indexed on deployment for independant users assigning names. The vm's domain name registration becomes an independant issue of the "assigned" computer name mismatching the VM host name declaration and then host file alias alignment. Once the Openfire is installed and jingle identifies the correct public facing IP, jingle SHOULD NOT return a response of --- "Nodes Requires a Public IP for Internet Calling. Public IP Found: NONE"--- while showing jingle KNOWS the correct VM public IP address and no further output I could find in logs. Telling jingle to update and accept the ip address showing does nothing of course, it's already correct.
It was then suggested the problem was attributable to the xmpp server name versus host name in Openfire not matching.
Admittedly after renaming the VM and matching up the host file before installing Openfire to make sure the server and host name matched in Openfire, jingle STILL refused to come online with the same indication. The issue has several community queries with nobody as maintainer, so most queries to the issue dead end.
There has to be more to it than Openfire matching server name as host name or simply a matter of IP/port pairs. Actually it seems to me xmpp server name and host name should NOT match if the Openfire server is to have assignable independence from the domain / sub domain structure and end up properly associated with a DNS structure.
While I don't use Jingle Nodes myself, a glance at the plugin's source code doesn't indicate that it relies on a hostname anywhere. All you need to do is to configure your public IP in the plugin's configuration. Given that AFAIK the Jingle only uses ip/port pairs, this is no surprise.
Again, public facing ip of the vm is showing "correct", all ports are unrestricted during testing, but the plugin complains with no further indication.
I'm simply trying to increase potential traversal options using jingle, so I apologize huge we're drifting off topic.
This certainly is not a jitsi issue to fight with and I truly appreciate efforts offered here, not wanting to trash up the jitsi user-list. 
Mike
···
----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: "'Jitsi Users'" <users@jitsi.org>
Cc: <afpteam@sbcglobal.net>
Sent: Thursday, April 09, 2015 6:50 AM
Subject: RE: [jitsi-users] New user and questions
[Quote: Emil]
Sorry, I didn't understand this part at all so I am afraid I have no
solutions.
[Quote]
Openfire has two variables in config jingle needs to see match,
Actually so does Openfire as far as that goes...
A) Openfire's server name ...
and
B) Host name, derived by reading the Windows "Computer Name".
Openfire doesn't let us alter the "Host Name" read during config.
The windows "computer name" does not adhere to FQDN standards.
Hence, there is no way to configure Openfire to satisfy Jingle.
Without this alignment, Jingle cannot confirm multihomed scenarios.
As such, jingle fails to initiate.
This is a windows only issue, left unresolved in Jingle / Openfire.
The only difference the Jingle Nodes plugin makes between Windows and Linux is the IP binding of the relay channels: on Linux it binds on all interfaces, while on Windows it only uses the configured or detected public IP address.
Openfire and Jingle should permit the user to override and store these
values manually rather than trying to "allocate" during configuration, since
computer name allocation in windows is so broken. In VPS scenarios where
the machine is deemed "multi-homed" this becomes especially problematic as
jingle needs to know it's associating a virtual machine's public facing IP
addy separate of it's hypervisor control IP addy.
I really don't know what you're talking about here. Windows' computer name allocation is not broken in any way. You give the host a name, and a hostname can't have dots in it. If you want to configure an FQDN, set a DNS suffix.
Openfire does not care about the hostname. All that matter is the XMPP domain name, and you can freely configure that during the setup. Independent of the hosts name or its FQDN.
While I don't use Jingle Nodes myself, a glance at the plugin's source code doesn't indicate that it relies on a hostname anywhere. All you need to do is to configure your public IP in the plugin's configuration. Given that AFAIK the Jingle only uses ip/port pairs, this is no surprise.
There is probably a solution to be found in altering the Openfire / jingle
config and / or Host file alias after installations, but then you have to
maintain a hack through updates which is ridiculous. Worse, Openfire doesn't
seem to be interested in maintaining or improving this aspect of their
server design or the Jingle plugin basis which appears to be unmaintained at
this point.
Thanks for the CUSAX reference.
I'm looking into it.
Mike
Ingo
