[jitsi-users] New user and questions


#1

Hi,

This mail is mostly to close out the Openfire integration and configuration issues first discussed in this thread, hoping it may be helpful for others newly testing Jitsi on Openfire finding outdated articles leading to confusion sorting out proper provisions.

We resolved that our Openfire xmpp server residing on a separate vps machine from our primary domain, (absent integrated domain controller), was best settled by changing the Openfire Windows Computer name to match a subdomain name (CHAT), such that the Openfire setup utility adopted and assigned the Computer Name = subdomain name value to Openfire's "Host Name" field becoming "CHAT".

We filled in the Openfire "Server Name" field as "subdomain.domainname.com", (chat.example.com) such that the "chat" prefix, host and computer name matched.

We updated Windows host file to reflect the assigned IP address of the Openfire windows machine127.0.0.1 with localhost and loopback, IPV6 ::1 address to localhost, then IP address for FQDN matching chat.example.com.

We updated the domain registrar's DNS zone A with a record to point "chat" at the xmpp IP address and AAAA records with the IPV6 address of the xmpp machine.

Recommended port range permissions were then set in the Windows firewall by "for loop" in CMD prompt as server 2003 is a limited firewall at best from a gui perspective.

Last, the relevant ICMP permissions were opened to make sure legacy routing could operate normally.

While this didn't solve Jingle's failure to identify the VPS multi-homed condition Jingle is in fact definitely working as is STUN reflection. The connection is fairly instant reliability in Jitsi's relay mode assigning xmpp user addresses as user@chat.example.com with a side effect that user@example.com can "create" an account on the xmpp server but cannot login or authenticate after account creation, otherwise use of the full triplet behind user@ works perfectly in all respects for our current test model.

The problems were compounded by Forest Gump syndrome in that this was our first integrated IM attempt. We were UNAWARE Jitsi may take up to 15 seconds to complete the first visit handshake before completing the flip side of a voice call. Each time we made a "first" connection form my machine to another user the connection was instant and secured easily. The other client when calling back the other way to my machine would show "Connected in red" but no further result after only 5 seconds before committing a manual hang-up, "incorrectly assuming" failure. We learned a great deal watching a simple video at https://www.youtube.com/watch?v=udBBDHT-_UA which detailed a 15 second delay on first handshake as well as fuller explanation of the 4 character ZRTP matching sequence for extended security. Not sure how we missed this information in the current installation and configuration supports which would have saved hours of false impressions on one-sided failures which were not actually failures in retrospect.

Confirmation of point-to-point UDP was evident in the call data window even over the web which surprised me, assuming we would end up remaining in relay mode, however IP address confirmations and even turning the Openfire service off during call testing after connection, suggested the Jitsi IM's were continuing to operate voice in what appears to be UDP sustained P2P with impressive low noise and jitter stats, even long haul U.S. to London with relatively low latency. We don't use video at this time, so no feedback on that aspect.

The bottom line is that Jitsi is a VERY usable corporate tool in it's current state given some persistence in Admin efforts to track down relevant configuration and application supports. Jitsi appears capable of satisfying a corporate structure for security on Openfire. One should never assume SSL and TLS are a full solution against a more capable intruder able to access layers of data to circumvent security especially if one or more endpoints may be compromised already. Still, if there is a toolset capable of reaching higher security in a corporate setting Jitsi has what appears to be the fullest compliment of facilities of any Open Source communication asset we were able to locate and the ZRTP security feature compliments this well with the assurance of a clean provision in source code assuring no forms of unwanted eavesdropping.

Some of the other videos out there provide yet further understanding on SIP integration, it's limitations or features and fuller understanding of moving from integrated voice to true VoIP to phone PSTN integrations. The hours of dedicated efforts and evolution in the Jitsi project by it's contributors becomes evident for greater research reminding that documentation maintenance on Open Source is a huge part of supporting early users experience in getting off in the right direction and not giving up from early frustration.

My extended appreciation to devs and those on list putting up with Forest Gump early on. We'll try to keep Forest in his cubicle in the future. :slight_smile: As our firm should find continued success in it's current efforts it will be my pleasure to afford development support at least on par with proprietary commercial solutions if not perhaps greater to help assure Jitsi's continued place in the Open Source initiatives for privacy and design integrity. Given our focus is in the global investment industry, this is a critical aspect for us for improving a secure infrastructure over time.

afp

ยทยทยท

----- Original Message ----- From: <afpteam@sbcglobal.net>
To: <users@jitsi.org>
Sent: Thursday, April 09, 2015 8:39 AM
Subject: Re: [jitsi-users] New user and questions

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. :frowning:

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