Can't get video from camera

Hello Jim,

Thanks for pointing me in the direction of your blog. I will try everything I see on the site and let you know what the results are. However, since you seem to know your stuff about Apple, why should I have to do all of this to get a video chat to work? I bought a powerbook because I didn't want to have to mess with permissions, upgrade a certain way, etc. I believe you aren't an Apple employee, but I wanted to see what you thought.

Thanks.

Hello Jim,

Well, here's what I did so far and it still didn't work; at home at least. I took my powerbook and my paperweight (iSight) down to the Apple store. I was able to successfully use Bonjour and video worked great. Then we both went to the same Wireless Internet connection they have and video once again worked great. Then, I went to a different wireless Internet connection than the one the other PC was on and video still worked great. Both Macs were running 10.4.2. I had done anything on your blog. So, I figured it must have something to do with one of our networks.

I got on audio chat with my brother and had him connect directly to his cable modem while I was still behind my Linksys as the DMZ. It didn't work. I then bypassed my Linksys so that we were both directly connected and it still didn't work. So, we both began trying a few things on your site.

1. Both of us set our bandwidth limit to none.
2. Both of us repaired permissions, reinstalled QT7, rebooted, repaired permissions and it still didn't work.
3. Both of us repaired permissions, reinstalled the 10.4.2 combo (not from software update), rebooted, repaired permissions and it still didn't work.

Each time, we had started no other applications; just iChat. Also, I made sure that iChat wasn't one of our login items on startup.

Somehow I just knew it would work at the Apple store and I'm not sure where to go from here. Any words of additional advice would be greatly appreciated.

Thank you

As I read more and more about this, I feel as if iChat AV 3 brought a bundle of additional requirements into the picture that I don't know about. As you said, I am also beginning to suspect that my ISP may be the problem. At this time I am using a wireless radio shot. My ISP has provided me an external IP address because of previous problems I had in Panther, but that doesn't seem to work anymore. My setup is as follows: External IP -> NAT IP on my router and then it's NAT'd again for my home network. However, in this case, my first NAT'd IP is mapped directly to my own static external IP versus all the other customers who use the same external IP. I know that most providers don't do NAT and generally don't have these problems. I wonder if the additional requirements are going to put me out of business with iChat? Anyway, I agree with you, I don't think I needed to go through all that as it did work at the Apple store with one of their Macs. I have sent an email off to my ISP to see if my config has changed. I guess for now I'll keep digging to see if a dual NAT scenario may cause some problems. In reality it shouldn't, but who knows. Thanks again for all your help.

Hello Ralph,

iChat does not like it's data packets to be NATted twice.

I guess I'm having a really hard time understanding why this won't work. I literally have ftp, http, https, smtp, pop, and a number of other applications that use these protocols without error running on my network. Regardless if there are tons of NAT networks in front of the true external IP and the proper routing is in place, shouldn't this work? Do you know exactly what it is about this application that doesn't like a setup similar to this?

Thank you

Hello Ralph,

Well, what can I say. I'm not ready to give up on this, but I did run into a major stumbling block. I spoke to my ISP last night and we ended up making some changes. Here is what my old setup use to look like:

Cisco 2514 w/External IP Mapped To --> Motorola Canopy Radio IP of 172.X.X.X

The above was mapped in the cisco router using traditional inside outside NAT.

However, once it reaches my radio, it had a DMZ host setup on it which was basically my WAN port on my linksys. This was a 192.168.5.X address and then I NAT'd again to 192.168.1.X on my home network. All of the above was using a Class C subnet mask.

So, we made the following change:

Cisco 2514 w/External IP Mapped To 172 IP used on my powerbook --> Motorola Canopy Radio in Bridge Mode --> IP of 172.16.X.X on my powerbook. So, as you can see, I got rid of the dual NAT scenario.

I was fortunate enought to find EZ Jim online and we tested this out. Whether he started the video chat or I did, we both got "Can't get video from Camera". However, audio worked fine for us and it always works with whoever I try it with.

At this point, I am going to dig into how bridging works on the Motorola canopy to see if it helps, but I have a feeling that it is probably a traditional learning bridge and simply works off an ARP table. If you have any other ideas, please let me know. Also, If I do figure it out, I will be sure to post the answer.

Thank you

Hello Ralph,

Well, I tried all of the above and it still didn't work. However, I talked to my ISP yet again and had him drop all NAT. I got him to give me a public IP and tried the test again. It worked like a champ. I tested with EZ Jim and also my brother. Also, it worked behind my router as well. I had my firewall on, UPnP disabled, no port forwarding, no port triggering, etc. At this point, I am going through some tcpdumps that I collected when it failed and when it worked to see if I can pin point a particular failure. I want to personally thank you and EZ Jim for all of your assistance.

Hello Ralph,

I started looking at the tcpdumps and here's what I found so far:

Whether the connection is being NAT'd or not, it appears that the packet exchange between the host and snatmap are the same. In my case, it was always using ports 16384, 16385, 16386, and 16387 to try and put my video chat on. Unfortunately, I was unable to decode these packets to see what was going on in these exchanges and whether they were different. However, they were the same and at this point appear to be a non-factor. After all, based on what I am seeing here, I wouldn't respond on one of the ports if I was unable to see the inbound packet on a particular port and from what I can tell, I am responding on all four ports based on communications received on those ports.

After that, SIP appears to try and start traversing back and forth. In the case where it does work, SIP begins talking to the other peer on a randomly chosen port...somewhere in the 64000 range for me most of the time. In the case where it doesn't work, SIP refuses to be setup (NAT'd), a random port is not chosen and thus the conversation is not setup. If you can't find the SIP NAT failure in a tcpdump, the sure way to tell is if you look at the rest of the packets after the snatmap exchange and all packet exchange will reside on only one of the four AV ports...in my case, it always used the first one on 16384.

So, I did some more investigation on this and found that there is full cone, restricted cone, port restricted cone, and symmetrical NAT. I'm really not sure which one Apple supports, but it would appear that the developers at Apple only chose one or so of the types.

In my particular case, I am not sure which component on my network won't properly NAT SIP and I don't really feel like going back to my original network configuration to figure it out. All I can tell you is that a Cisco 2514, a Motorola Canopy SM, and a Linksys WRT54GS v1.1 is what my network consists of.

Thanks