Jabber video chat fail

Question

Level 1

10 points

Jabber video chat fail

I have tested this on two Yosemite servers - running Server 5.0.3.

I am unable to get video chat to work offsite using messages service.

FQDN is working correctly, port forwarding is working correctly ( I even setup DMZ to be safe - so as not to miss any ports)

After upgrading from Mavericks to Yosemite server, Video Chat/ Audio Chat will not work from outside the network. Internally they work fine.

I can VPN into the server and then video chat with an internal client even. But its almost like Yosemite server is using bonjour to connect the video clients to work?

I built a second brand new server, at a different location to eliminate an ISP issue, setup FQDN, and tested again with DMZ and received the same failure.

Internal clients can video/audio chat fine.

But it seems like Yosemite running the newest server app will not allow video/audio chats from outside the network.

I have yet to see any discussions regarding this particular matter, so heres to hoping someone else is using Jabber on 10.10 and has attempted video/audio services from outside their local network using the messages service on Server App 5.0.3

Thanks!

Posted on Oct 12, 2015 8:21 AM

Reply

Answer 1

dwainsco Author

Level 1

10 points

Jan 11, 2016 8:36 PM in response to dwainsco

Update...

I have now setup a brand new 10.11.2 Server , running chat services.

Can Video Chat internally fine, but unable to Video Chat from external - all DNS running correctly - all port forwarding correct - even attempted using DMZ to be safe...

Anyone?

Reply

Answer 2

Chridi80

Level 1

0 points

Jan 26, 2016 5:33 AM in response to dwainsco

Same here!

And ScreenSharing fails, too.

Can you still use ScreenSharing?

Reply

Answer 3

xmddmx

Level 1

101 points

Jan 31, 2016 12:41 PM in response to dwainsco

It sounds like you are running OS X server inside a router/firewall?

If so, you might want to read this thread messages server proxy65 behind NAT? which talks about similar issues.

The short answer: it appears that some services on OS X server aren't very smart about this setup, and will either advertise the LAN address (when they should be giving out the DNS name) or they try to use the DNS name and then fail to configure properly (since they are trying to bind to ports on the router's IP address, rather than localhost). The trick I found was to hack some .py and .plist flies to use the FQDN (rather than LAN IP address) and then set up DNS so that the server gets the LAN IP address (rather than WAN) when it asks for it's own IP address. This is a hack and a kludge and I wish that Apple would do a better job of making "OS X Server behind router or NAT" work.

Reply