iChat AV 3

Hello everyone,

I am posting here because I believe there is a problem with using iChat AV 3 with the Canopy radio system. I am able to use the video chat in iChat AV 3 on every network that is attached to the Internet except for the one that my ISP uses. I spoke with my ISP last night and they had me running a dual NAT scenario with my WAN port on my router setup as the DMZ host in the Canopy. We ended up turning Bridge mode on in the canopy and it still doesn’t work. Please keep in mind that I know it’s not the operating system, the application or anything to do with the Mac. It’s just that it doesn’t work utilziing the canopy. Does anyone know how bridging works in the Canopy? Is it a traditional learning bridge? Any words of advice would help me out a great deal. I know that Motorola made some changes so that VPN would work with version 4.2 of the Canopy software and are beginning to wonder if additional changes need to be made.

Thank you

Yes, the Canopy units are self-learning Ethernet bridges. If you previously had NAT enabled on your SM, you could try setting the SM to its factory defaults and re-apply the needed changes.

Is a Canopy SM used to reach your ISP? Is this the only piece of Canopy gear in your network? Have you tried testing your app to your ISP’s network, or only to the world outside your ISP?

For those wishing to see the whole dialogue, please refer to the following URL: http://discussions.info.apple.com/webx? … @.68b5dada

I finally got it to work, but I had to bypass all NAT’ng on everything except my CPE (Linksys WRT54GS v1.1).

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.