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.
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:
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:
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!
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)
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:
- 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. - 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 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!