iChat AV - The best unusable video and voice chat program

Apple has a little product called iChat AV which is only available on Mac OS X systems. I remember watching the keynote when Steve Jobs first announced the video conferencing solution and I was blown away. h.264 as the primary CODEC, great quality, multi-party chats! It's got some amazingly cool features that many other solutions don't have. There's only one problem: it doesn't work.

At this point some readers will be up in arms telling me how they were able to connect to their cousin in Utah just fine, or did a test from 2 computers in their home just fine. "IT WORKS" you'll say. In home to home situations iChat seems to work 75% of the time. The problem I'm encountering is a bit larger. We use video conferencing software (VVoIP or Video/Voice over IP) to do our video interviews from anywhere in the world. I need the highest quality solution I can find with the least amount of technical jargon to throw at the interviewee. iChat has great quality, but it has a horrible time break through firewalls and NATs. No ability to route through a NAT means no ability to actually work. Most companies have their employees on an enterprise grade NAT so when we want to interview the CEO of a company, well, with iChat we can't.

VVoIP programs such as Skype and SightSpeed are able to work on just about any network we try. Here at the Technology Evangelist office we have a Cisco NAT and iChat won't even begin to try and crawl through that. It's not a fault of our NAT as both Skype and SightSpeed work fine here. On home routers UPnP needs to be enabled and even then maybe it will connect if the firewall settings are correct. Of four different business networks I tried it on, not one worked with iChat. I thought that maybe it was just the company blocking VVoIP traffic. Nope, both SightSpeed and Skype work great on all four networks. The only app that won't work is iChat.

I brought my MacBook Pro home and tried iChat on my home network with a test Apple account. IT WORKED! Oh, and it was beautiful too. By far the best quality VVoIP I have ever seen, it's up there with pro grade video conferencing units. I was ecstatic! I then tried it again to show off iChat and... it failed with an error -8. I was able to get iChat to work on one computer, not a second computer at all and on the computer it did work on it would only work 2 out of 3 times. At this point I was pulling out my hair.

For us this is a huge bummer. Apple is introducing some amazingly cool features into the next version of iChat that include desktop sharing and automatic keying. I really hope that Apple focuses on networking first and foremost. A quick glance at the support forums will show that I am by far not the only person with this issue. For a company that makes computers and products for mere mortals, iChat AV seems to be set up for only the elite few who can get a public IP address with no firewall on both computers they want to connect to.

If you are disappointed in iChat's NAT/Firewall performance or network performance in general I would suggest sending Apple as much data as you can about the errors you are getting in iChat. When a conference fails you get a 'Communications Error' dialog. Make sure to send the details of that to Apple every single time by hitting 'Send to Apple' when this pops up. Hopefully with enough error reports pointing to bad NAT transversal, they will be able to fix it in the next version. If you simply don't use iChat anymore then sending Apple some feedback on their product may be a good idea. Let them know exactly where the issues are. I'm still an idealist so I hope and believe that Apple cares and with enough people sending constructive feedback, they will make a change for the better.

Listen to this article posted by Benjamin J. Higginbotham on February 14, 2007 1:49 PM | Permalink
More posts about Apple

                                             

The thing I don't like about Skype is it's basically a black box installed on your computer. It's a private and closed system where you don't really know what's installed, what it's doing, or what it's reporting. And it's from the guys that gave us the biggest malware installer of all time, Kazaa. Scary!

The secret is using a NAT/Firewall device that supports SIP transformation. SIP transformation replaces the private IP and the assigned port of the SIP message with the public IP and outside port. It also controls and opens the RTP/RTCP (Real-time transport Protocol/Real-time Control Protocol) ports that are needed for a SIP session.

Most enterprise NAT/Firewall vendors include this feature in their newer firmware or newer devices since this feature is essential for allowing SIP based phones to communicate with SIP proxy servers outside the network.

In addition, I have noticed certain vendors that support SIP transformations have the feature disabled by default.

SIP transformation is also referred to as SIP ALG (Application Layer Gateway) by some vendors (Adtran, Cisco, etc.)

Skype is terrible in comparison to the quality of iChat. This article has valid points but for the majority of users, it is not an issue.

I hope Apple fixes this issue, however.

What's atheist for Amen?

Thank goodness you said it.
100% totally in agreement with you. I would love to be able to use iChat. But it comes up with some meaningless error message every time.
Apple stuff should just work - Google a fellow called Ralph Johns. This guy has made it his mission to help people get iChat working. There are pages and pages of voodoo on his website telling people to change this setting. Open these ports. Stand on one leg chanting.

Meanwhile Skype just works.

If Apple could deliver a quality videoconferincing solution that worked through corportate firewalls, it would sell Macs as dedicated videoconferencing units.

C.

I am glad it's just not me.My ichat didn't work for the longest time trying to get the grand kids to talk to the grandparents in the uk.I put it down to my 70 year old father doing something wrong. The Apple Test site works perfectly though.Long story short, it works great everytime now as long as I disconnect from the network router and plug the cable modem directly into the mac.
Only way it consistently work,
Three leveles of Apple support were useless.

Make sure to fill out the Apple feedback forms and let Apple know that you're having NAT problems. I believe that if enough people fill it out, then maybe they will do something about it.

I have other SIP VoIP apps that work through my NAT, just not iChat.

Just because other SIP based VOIP services work does not mean iChat should work too. iChat uses a complex call setup procedure, Apple most likely choose this route to provide the high quality video in iChat. You can either have easy setup and low quality video (skype) or moderate difficulty and high quality video (iChat).

I agree it should be easier to use iChat, but in time the NAT/Firewall vendors will make the adjustment on their products not Apple changing their software.

Dave, I think we fundamentally disagree on who should fix the problem. I see pro grade conferencing units that look just as good as iChat, are SIP based and work fine. They cost a lot of money though, but at least we know it can be done. I see SightSpeed which is free and very close to iChat's quality. The others, Messenger, AIM, Skype, etc. all seem to pale in comparison, but at least they work. High quality and not working is not better than low quality but working. I simply believe it's a problem with Apple's NAT transversal and not the hardware vendors problem. Maybe we're both right and changes need to occur on both sides.

Based on a comment you made earlier I did a bit of research on Cisco NATs and what it would take to get better SIP support on our 7204 VXR... Looks like an IOS upgrade and simple change to my config may help. This was a good starting point for me. I can't bring my network down right now to test, but I'll be doing so in off-peak hours. I'm excited to try her out.

If Apple can make a change on their end to make things easier I am all for it as long as it does not take away from quality or limit features in the new version (screen sharing etc). I do believe you have a better chance on getting hardware vendors to add support to their products first (This is my main point). We struggled for a long time to get our iChat issues resolved and spent a lot of time researching all the options. We wanted to find a solution that did not require port forwarding, one to one NAT, or public IPs. After reading a lot of documentation and installing a firmware upgrade we had iChat working flawlessly.

The big issue for you is going to be, even if you get things working on your Cisco you still will always have to worry about the caller on the other end. If you plan on using iChat for your interviews, I would suggest using a SSL VPN as a backup for users with connection problems on their end. This way you have a quick plan B in place. They would simply go to your SSL VPN gateway run the Layer 3 network connect and tunnel into a dedicated VLAN for video conferencing.

Well, it's much more fun and exciting when you accomplish the impossible! One gets a real sense of achievement when getting iChat AV to actually function as advertised.

The reason why Skype simply works, is that it automatically assumes that no routers in this world works, then hides it's communications (what people call a "black box" - and then it works.

The reason? By keeping network technologies close and secret, no fumbling by 3rd grade router programmers etc. needs to be taken into consideration. I too have a Zyxel SIP aware router, and my SIP phone only works then the SIP awareness has been disabled.

So I don't have any problems installing a program like Skype, which simply works.

see http://enginepuller.com

skype suxs, most mediocre audio and video ever.... no comparison to ichatAV.

I've been using iChat regularlly for the last couple of years. There's NAT on the network in the office, and NAT on the network at home. On these networks I've had no trouble connecting.

The twice on other networks where it didn't want to work we got the admins to open a port in the firewall and it started working.

My experience with iChat has been pretty good. It's not infallible, but what is?

Agree completely with the article- of the 20 times I've tried, its worked 1 time. I thought it was my error and was so happy to find this page (the photo above could easily been of me!)
Plain and simple, I'm a mom who wants to be able to video chat home with the kids while I'm on the road for work. I need to be able to count on the program navigating whatever it has to navigate because every hotel, airport, city has a different setup. Whomever needs to fix this (Apple or others) needs to do it!
We just purchased two of these Mac Book Pro's for the purpose of staying connected- hope they can make this work!

Kristen, you're in luck just not with iChat AV. The programs that DO work just about anywhere are http://www.sightspeed.com which is my favorite and http://www.skype.com. Download one of these on both computers and use it in place of iChat AV. If you need multiple people to video conference at the same time then you'll need to stick with the pro version of SightSpeed.

Hope that helps!

How disappointing, I just purchased 2 Imacs and got my brother on the easy coast to purchase an Imac so we can talk. I am so frustrated and upset that I went back to using an apple. Has this been fixed yet?

NAT should die a quick death, it's a horrible horrible hack. Unfortunately there are a lot of ignorant people out there that believe NAT offers some sort of security benefit.

Bring on IPv6 and proper firewalls i say.

Anyway, i had a quick poke around with the new version of iChat in Leopard and it seems to indicate that it supports ICE in addition to Apple's SNATMAP system of traversing NAT. If this is in fact correct there should be a dramatic increase in iChat's ability to successfully traverse NAT (far better than the solutions you claim "just work" at the moment, Sightspeed and Skype).

Unfortunately there's still no support for connecting to a SIP server nor does it seem to support Google Talk (audio).

I guess we'll have to wait and see what's really going to happen, but at least it looks like NAT traversal might see a fix with Leopard.

I cannot tell you how long I have spent trying to figure out this problem. We have a bunch of macs sitting behind a NATed Cisco 2811 router, and iChat will just never work, throwing the good ole' -8 error.

Having a good understanding of SIP, I decided to get down an dirty with the investigation of why iChat doesn't work behind some routers, while it does on others.

iChat uses SIP, but as I have found, Apple's implementation of it does not completely honor the RFC. This is the root cause of iChat not working behind enterprise grade routers that have SIP ALG activated (details later).

Apple uses its own flavor of NAT traversal: SNATMAP. This is an Apple service that is utilized every time a video/voice conference is created from iChat. For those of you familiar with SIP, SNATMAP essentially performs the same function as a STUN server. This service abstracts the port specifications necessary to get around NATs to a server on the public Internet.

With some routers, this SNATMAP seems to work fine. With others, not so much. I honestly don't have too deep of an understanding of SNATMAP so I cannot get into too much detail as to why it doesn't work with some routers. If anyone knows, please chime in!

I can, however, clearly indicate why it doesn't work behind routers that have a SIP ALG, which essentially has the intelligence to pick apart to SIP packet to make them NAT friendly. Basically, there is a portion of SIP packets called the SDP (Session Description Protocol) that provides all of the information necessary to set up the voice and video stream. The SIP RFC calls for this section to include information like the connection IP address, port, video codec, audio codec, etc. HOWEVER, Apple's implementation of iChat DOES NOT INCLUDE THE PORT. Therefore, when a SIP ALG tries to intelligently convert the port, it isn't there to change. Even if it does manage to insert a port number into the SDP, the iChat client receiving the SIP packet doesn't respect that port number and just dumbly sends the request back to the default SIP port (5060).

Here is a little flow of the process:

1. A SIP packet is sent out from iChat to the cisco router

2. Cisco intercepts the packet, changes the private IP address of my computer to the public IP address of the interface, and changes the port to one that it assigns on the public interface. So, basically the SIP packet enters the cisco with the SDP info like 192.168.100.137:5060 and leaves the Cisco like :1877.

3. On the receiving end, the SIP packet and SDP section is read with our DSL connection's public IP address, so when it tries to make contact back, requests are sent to the DSL public IP address and not an unrouteable private IP. Also, it sends to the port specified in the SDP section.

4. When a packet comes in from the peer, the destination is something like :1877. The cisco NAT translation table remembers that things destined to port 1877 should be converted to 192.168.100.137 on port 5060. The SDP section of the SIP packet is modified and things are peachy.

5. This happens back and forth for all SIP messages that traverse the NAT.

iChat is not SIP RFC compliant which is why we are having these natting issues. iChat does not specify a port in the SDP portion of the SIP messages it is sending out: a big no-no. Therefore, when the recipient iChat is sending back its requests to 207.182.233.32, it is sending it to port 5060 instead of assigned port 1877. The public port 5060 is blocked, and is not routed to any specific computer, resulting in a timeout. Here is the Cisco output 'debug ip nat sip'

001892: .Oct 2 22:53:04.108 PCTime: NAT: SIP: [0] processing INVITE message
001893: .Oct 2 22:53:04.108 PCTime: NAT: SIP: [0] register:0 door_created:0
001894: .Oct 2 22:53:04.108 PCTime: NAT: SIP: [0] translated embedded address 192.168.100.138->
001895: .Oct 2 22:53:04.108 PCTime: NAT: SIP: [0] No port present. Use new port 5060->1210

As you can see, it is processing the INVITE request and translating the internal IP address to the public one.
However, it reports no port present, meaning that the port specification in the SDP section of the SIP packet is not present. It does a port translation because it feels obligated to, but iChat doesn't respect that on the other end and sends to 5060 anyway which is not mapped to any specific internal IP addess, so, alas, it doesn't work.

Now, that being, said, this explains why iChat doesn't work behind SIP ALGs. However, if you are able to disable the SIP ALG (on cisco: 'no ip nat service sip udp 5060'), it still doesn't work. With the ALG turned off, the SDP translations don't occur, but for some reason SNATMAP still doesn't work either. I am thinking that could be due to a nat issue, but I haven't figured that out yet. Anyone's insight would be appreciated!

Hope this helps anyone out there seeking help / console with iChat Error -8 issues behind an enterprise grade router.

sooo...i don't know much about computers, but i seem to have exactly the same "communication errors" that everyone else is having here. sometimes it works and its so much fun! being a freshman in college, i need ichat to keep in touch because most of my friends won't get skype.

Long story short: have we found a solution? or are we just going to keep sending those data reports to Apple until they realize that there are a LOT of unhappy people out here? i just tried to iChat with a friend and we tried maybe 10x and it STILL didn't work. I'm mad now. Well, as mad as an young girl who is procrastinating her French homework in the middle of the night can be. ;P

This does seem to still be an issue. I work at a media school and we're very interested in making Ichat work for teachers and students. We are successful with about 75% of our chats now that we're on Leopard.

However with the ones that don't, I've done port scans for both 5060, and 5190 and they are open, ping tests and they can play the video from the ichat test user.

Still we get this when we try to connect with several of our students.

AVChatStateConnecting to AVChatStateEnded.
2008-03-07 11:34:14 -0500: fsospecialist4@mac.com3: Error -8 (Did not receive a response from 0x188b2930.)

Video Conference Error Report:
19.189023 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]

I've been to the Ralph Johns site which is very good, but does seem to be a bit more focused on the Tiger version of ichat.

Am having a lot off problems with my iChat AND STILL CAN'T FIGURE IT OUT MY

Crikey! This is an annoying problem and I really really wish that Apple would resolve the network traversing issues! I hate that I cannot successfully negotiate an iChat video session. Grrrr!!!

As a tech support engineer for a major router manufacturer, it is difficult to locate accurate information on how the NAT traversal mechanism in iChat works. Asking an enterprise class network to open UDP 1024-65535 is ludicrous. The description by Matt above is quite accurate - Apple failed to honor the RFCs and uses a uPnP hack to traverse some firewalls (Linksys, etc). Most enterprise class routers do not support uPnP because of this security flaw, but support a SIP ALG or SIP proxy to properly configure the firewall to permit the RTP flows. Another misstep by Apple was to move all RTP traffic onto 16402 and bypass standard SIP altogether (5060) for the sake of simplicity. This renders most SIP ALGs and proxies useless. Anyone with detailed info on SNATMAP, please contact me!

Ok, after working with cisco TACs here is how to address issues with iChat and Cisco IOS routers.

First identify your outside interface and the acl that is applied to that interface.

Verify with a show access-list "acl # of outside interface" that all the sequence numbers fit to this sample configuration, all them need to be behind the sequence numbering of the 1st line

Conf t

ip access-list ext "acl # of outside interface"

2 permit udp any host "public ip of outside interface" eq 5060
3 permit udp any host "public ip of outside interface" eq 5190
4 permit udp any host "public ip of outside interface" eq 5297
5 permit udp any host "public ip of outside interface" eq 5298
6 permit udp any host "public ip of outside interface" eq 5353
7 permit udp any host "public ip of outside interface" eq 5678
8 permit udp any host "public ip of outside interface" range 16384 16403

next add these two lines

no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060

TEST TEST TEST

if it works issue the wr mem command and exit your router config

I too have been having major issues. The one thing that I have found that people with problems seem to be having is either a cisco router or VOIP.

I called my VOIP company and they told me to open UDP 16384-16482. And 5060.... Apple, told me to iChat uses UDP 16393-16402 and 5060.... Ding Ding - SAME PORTS! I cant figure out a way to force either one to use different port!

So, I figured I would physically change the configuration. In my case, I now have DSL -> Airport Extreme -> Cisco Speedstream 4100 router for my VOIP. I assumed that because I had the router downstream, it shouldn't "target" the ports. But, it still does. (As a test though, I removed the VOIP box completely and ran an ethernet cable from the airport to the computer and it STILL didn't work, which means it must be something in the Time Capsule (airport extreme) that I cant figure out.

I'm at a loss. I have tried opening up all the port to no avail....

Anyone else have any further progress?

• Why I Don't Worry About Voter Registration Fraud
• Gary Vaynerchuk: Online Marketing Optimism
• Top Blog Posts for September 2008
• DexKnows.com, Minneapolis Pizza, & Blog Payola
• Aggregate vs. Detailed Data - Zillow.com