Resurrecting iChat Audio/Video Conferencing

[pipetogrep]

Hi all,

This post is @Melchieor's and my effort to get iChat AV video conferencing again. Let me start by showing screenshots of our early results. Three screenshots, enlarged, actual size, full screen.

The good news is that it works! But the news is there are many caveats but we're still poking away at it. This post is the log of our efforts. It's also a call for help! We're looking for others to help us test, debug, and provide info where we may lack it.

How was this achieved?

First, we needed a functional Jabber account. Eventually I would like to host my own but for now we are using https://jabb.im. My handle if pipetogrep and his is melchieor. Feel free to add us and say hello.

Next, some ports need to be opened on each party's end. This is because iChat is peer-to-peer.

• 5060 - UDP: SIP (Session Initiation Protocol)
• 5190 - TCP & UDP: AIM/iChat file transfer
• 5678 - UDP: SNATMAP server (what's that?)
• 16384-16403 - UDP: RTP/RTCP (Real-Time Transport Protocol)

Port forwarding isn't enough, however. At this point we needed to figure out how iChat negotiates its audio/video connections. This was done with a combination of running iChat in debug mode with "/Applications/iChat.app/Contents/MacOS/iChat -errorLogLevel 7" and tcpdump. Here is what happens.

The first problem is that iChat attempts to figure out the public IP address using a proprietary Apple protocol call SNATMAP. This is necessary since we are all behind a NAT router. This process fails and is the main reason why efforts to use iChat for audio and video chat fails today. The process looks like this:

1. iChat makes and HTTP request to http://configuration.apple.com/configuration/macosx/ichat/1/snatmap.txt.
   This step fails because it has a 301 redirect from http -> https. If you go directly to the https URL in a modern (enough) browser, however, it returns the output "snatmap://snatmap.apple.com:5678".
   
   I was able to make iChat get around the 301 redirect problem by setting up my own web server, making my own copy of snatmap.txt at the path it expects, and editing my /etc/hosts file to look for configuration.apple.com at the IP of my web server. While iChat was able to resolve the path to Apple's snatmap after that, it was not able to communication with it or determine our respective IP addresses. We did come up with a workaround that I will describe later.
2. iChat attempts to query snatmap://snatmap.apple.com:5678 to get our respective IPs. This doesn't seem to work. I don't know why. While the snatmap server still exists, I can only guess that it has changed significantly since the days of iChat AV and it is not returning what iChat expects.

So here's what ends up happening considering all of this. I'm on a 192.168.0.* network and @Melchieor is on a 192.168.1.* network. In tcpdump output, I see that my iChat is making a call to 192.168.1.178 which was @Melchieor's local IP. This mistake is because the snatmap process is broken. Since we're trying to traverse NAT, there's no way that would work.

So I did some firewall hackery. This was the "fix" and isn't something everyone could be expected to easily do. I'm running pfSense so I had this option, but not everyone's firewall does. Along with the port forward rules detailed above, I created NAT rules that redirects requests where the destination is @Melchieor's local IP address and redirects them to his public IP. The rules look like this:

Interface	Protocol	Source Address	Source Ports	Dest. Address	Dest. Ports	NAT IP	NAT Ports	Description
WAN	TCP/UDP	*	*	192.168.1.178	5060	His public IP	5060	SIP
WAN	TCP/UDP	*	*	192.168.1.178	5190	His public IP	5190	File Transfer
WAN	TCP/UDP	*	*	192.168.1.178	5678	His public IP	5678	snatmap
WAN	TCP/UDP	*	*	192.168.1.178	16384-16403	His public IP	16384-16403	RTP

The result is any requests the iChat makes to 192.168.1.178 (his local IP) gets translated to his public IP, and the connection is able to be made. After that, video chat worked! Another caveat is, since he was unable to make a corresponding set of rules to translate my local IP to my public IP, it only works when he calls me and not the other way around.

The NAT issues aside, there is still a lot to figure out. For example, test with Bonjour, I'm able to get 320x240 at 30 fps but over the internet with broadband speeds far faster than they ever were back then, we can only get 160x120 at 15 frames per second. Yes, I'm aware that iChat makes a call to a bandwidth testing server that no longer exists and that failing that, it falls back to the stream speed settings in the Quicktime System Preferences pane. We both have them set to LAN/Intranet, but the iChat logs still show that it downgrades the bandwitch when the call is initiated, even after it states that it is using the Quicktime setting.

We've also been testing with both external iSight cams and modern Logitech webcams which work great under Leopard. We'll continue to test and will post more results here. If anyone has any input on this or wants to help us test, please let us know!

 

[mectojic]

This is awesome, and exactly what I want to do. Unfortunately I have no knowledge of such things, so would need a step-by-step guide on what to do, starting with how to open ports.

I look forward to your tests!

 

[sparty411]

This is awesome, and exactly what I want to do. Unfortunately I have no knowledge of such things, so would need a step-by-step guide on what to do, starting with how to open ports.

I look forward to your tests!

Port forwarding is done at the router level.

 

[Pedro Passamani]

Hi all,

This post is Melchieor's and my effort to get iChat AV video conferencing again.

Lots of great info there!

I came across your post as I was trying to find what ports iChat uses for conferencing. Recently, while reading about PowerPC Challenge 2024 over at TinkerDifferent, I came up with the ideia to try to use iChat with some friends. I've used it before, during the Google Talk days, but that's not an option anymore (AFAIK), so I'm hosting it locally on a Power Mac G4 running Tiger Server and the iChat service.

Chatting and voice/video calls work fine on the LAN, but only chatting works over the WAN (voice/video calls fail to connect). I already have all the needed ports "NATted" to the G4's local IP, but now I know that's not enough.

I'm yet to try the snatmap local server, so I'll see how it goes.

 

[pipetogrep]

Lots of great info there!

I came across your post as I was trying to find what ports iChat uses for conferencing. Recently, while reading about PowerPC Challenge 2024 over at TinkerDifferent, I came up with the ideia to try to use iChat with some friends. I've used it before, during the Google Talk days, but that's not an option anymore (AFAIK), so I'm hosting it locally on a Power Mac G4 running Tiger Server and the iChat service.

Chatting and voice/video calls work fine on the LAN, but only chatting works over the WAN (voice/video calls fail to connect). I already have all the needed ports "NATted" to the G4's local IP, but now I know that's not enough.

I'm yet to try the snatmap local server, so I'll see how it goes.

Hey, Pedro. In order to get it going through the public web, you need to create a NAT translation rule that maps the person's private IP to their public IP. This has to be done on their end as well.

The reason for this is Apple used to provide a service that would figure out what the public IP was of each person and pass that along in the video chat request. That service no longer exists.

Lemme know if you need more info on that!

 

[Pedro Passamani]

Hey, Pedro. In order to get it going through the public web, you need to create a NAT translation rule that maps the person's private IP to their public IP. This has to be done on their end as well.

The reason for this is Apple used to provide a service that would figure out what the public IP was of each person and pass that along in the video chat request. That service no longer exists.

Lemme know if you need more info on that!

Thanks for all the info! Everything that you and @Melchieor were able to find and test really helped me better understand how iChat works.

My hope was to get around SNATMAP by running the server locally, under Mac OS X Server, but unfortunately it didn't work. Text chats work fine (messages are piped through the server), but audio and video calls still rely on P2P and SNATMAP (but they work fine if all clients are on the same LAN, though).

From what I understand, iChat tries to get the participants external IP address from SNATMAP, fails to do so (as the service is no longer available) and then defaults to using their internal IPs, which cannot work if there isn't NAT translation going on at both ends (like you said).

We know it's just not feasible to have people creating NAT rules on their routers (some may not even have the required access to do it), so for now, I'm just using the next best thing, a VPN connection. I enabled the L2TP VPN service on the server (I know it's super unsafe to host a VPN server on an OS that hasn't been updated since 2009, but it's just for fun ) and I'm having all the participants connect to it.

I did a test run last weekend and it worked! I used two laptops, a 12" 1.33 GHz PowerBook G4 running Tiger and a 13" 2.5 GHz Core i5 2012 MacBook Pro running Lion, plus the server itself, to join a three-way video chat:

Quality was OK, especially when we consider the laptops were connected to the VPN through my phone's 4G data hotspot, and that the Power Mac's and PowerBook's CPU were pegged at near 100% utilization (well, the Power Mac was also doubling as the server, so that's kind of expected).

Later this week I'll have some friends join me so we can try a four-way video chat. I just hope the G4 systems can keep up!

 

[pipetogrep]

Thanks for all the info! Everything that you and @Melchieor were able to find and test really helped me better understand how iChat works.

My hope was to get around SNATMAP by running the server locally, under Mac OS X Server, but unfortunately it didn't work. Text chats work fine (messages are piped through the server), but audio and video calls still rely on P2P and SNATMAP (but they work fine if all clients are on the same LAN, though).

View attachment 2340366

From what I understand, iChat tries to get the participants external IP address from SNATMAP, fails to do so (as the service is no longer available) and then defaults to using their internal IPs, which cannot work if there isn't NAT translation going on at both ends (like you said).

We know it's just not feasible to have people creating NAT rules on their routers (some may not even have the required access to do it), so for now, I'm just using the next best thing, a VPN connection. I enabled the L2TP VPN service on the server (I know it's super unsafe to host a VPN server on an OS that hasn't been updated since 2009, but it's just for fun ) and I'm having all the participants connect to it.

I did a test run last weekend and it worked! I used two laptops, a 12" 1.33 GHz PowerBook G4 running Tiger and a 13" 2.5 GHz Core i5 2012 MacBook Pro running Lion, plus the server itself, to join a three-way video chat:

View attachment 2340358

Quality was OK, especially when we consider the laptops were connected to the VPN through my phone's 4G data hotspot, and that the Power Mac's and PowerBook's CPU were pegged at near 100% utilization (well, the Power Mac was also doubling as the server, so that's kind of expected).

Later this week I'll have some friends join me so we can try a four-way video chat. I just hope the G4 systems can keep up!

That is so cool! You took it to the next step. I started playing with L2TP, but all my VPN knowledge is OpenVPN centric so I struggled. I considered making a public L2TP server for the MacRumors community but the got distracted.

There's also that issue the issue of CPU being spent on CPU overhead. I did have some other ideas I wanted to consider.

1. Trying to do NAT translation at the host level. That could be scripted. It would be fragile but whatever.
2. Writing a custom XMPP plugin that would detect which IP the request was coming from and update it on-the-fly. I did do some packet captures on unencrypted iChat sessions to see what was going on in the background. This is a bit beyond my capabilities right now, however.

Another issue is no matter what you set your Quicktime bandwidth settings to, it never seems to select a higher quality video stream. You can verify by running iChat in debug mode.

If you want to try working together on this, I'd love the help!

 

[Aaferti_Kuazar]

I was searching for ways to get iChat working and ran into this

Set Up Your Own Secure Messaging System with iChat Server | Setting Up Your Server | Peachpit

iChat Server makes adding secure text and audio/video chat to your network fast and easy. Read on with Ryan Faas to find out how to set up internal instant messaging and video conferencing in a few clicks without spending a fortune.

www.peachpit.com

prior to this here post.
I wonder if it would be possible say using Wireshark 🤔 to utilize the server that the newer macs use with Messages?
I don't know enough about how Jabber works so I'm just guessing here.
It would be awesome to make ichat a thing again.
Thanks so much for your efforts...

 

[Slix]

Thanks for all the info! Everything that you and @Melchieor were able to find and test really helped me better understand how iChat works.

My hope was to get around SNATMAP by running the server locally, under Mac OS X Server, but unfortunately it didn't work. Text chats work fine (messages are piped through the server), but audio and video calls still rely on P2P and SNATMAP (but they work fine if all clients are on the same LAN, though).

View attachment 2340366

From what I understand, iChat tries to get the participants external IP address from SNATMAP, fails to do so (as the service is no longer available) and then defaults to using their internal IPs, which cannot work if there isn't NAT translation going on at both ends (like you said).

We know it's just not feasible to have people creating NAT rules on their routers (some may not even have the required access to do it), so for now, I'm just using the next best thing, a VPN connection. I enabled the L2TP VPN service on the server (I know it's super unsafe to host a VPN server on an OS that hasn't been updated since 2009, but it's just for fun ) and I'm having all the participants connect to it.

I did a test run last weekend and it worked! I used two laptops, a 12" 1.33 GHz PowerBook G4 running Tiger and a 13" 2.5 GHz Core i5 2012 MacBook Pro running Lion, plus the server itself, to join a three-way video chat:

View attachment 2340358

Quality was OK, especially when we consider the laptops were connected to the VPN through my phone's 4G data hotspot, and that the Power Mac's and PowerBook's CPU were pegged at near 100% utilization (well, the Power Mac was also doubling as the server, so that's kind of expected).

Later this week I'll have some friends join me so we can try a four-way video chat. I just hope the G4 systems can keep up!

Thanks for continuing to try things to make this work!

I've used the VPN + iChat Server method before, and it does work, as you discovered. I wish Apple hadn't taken down that service that it tries to ping first, it would make using Jabber nowadays much easier.