IChat Video works without any manual port configuration

Question

I'm posting this as a question and a true "discussion" with regards to iChat "video chat" operation with 2 users, both behind their own NAT router. I have seen several cases where iChat (ver3 and ver4) work just fine without any manual intervention. Of course, there are many other cases in these discussions where it seems a lot of complication and little positive result are part of the equation. Isn't iChat designed to work behind NAT routers ? Doesn't it use the SNATMAP server to get external (ie; public) IP and port number mappings ? If both users can login to the AIM server and initiate a Chat request, and contact the SNATMAP server, the next key requirement is to simply establish a point-to-point SIP session to the public IP/port of each endpoint.
It seems the first thing to check is that this is happening correctly. In other words, the iChat debug log for userA should show something similar to;
2008-01-29 18:59:21.739 iChat[2603] IPAndPortList: (
{ip = "x.y.z.w"; port = 63217; },
{ip = "a.b.c.d"; port = 16402; }
...where a.b.c.d represents the internal/private IP of a user (userB on Leopard iChat4 for example with 16402 representing all of the SIP, A/V, and A/V control ports) behind a NAT and x.y.z.w represents the external/public IP of userB. At least I think Leopard uses 16402 for the SIP. This shows that userA has the mapping for the SIP signaling port to send the SIP:invite to userB (ie; 63217).
There is also something like;
185912.819694 Sending SNATMAP heartbeat to 11FAF895:5678
185912.912199 SNATMAP heartbeat resulted in IP change (from: 0 to: mm.nn.kk.pp)
185912.912251 SNATMAP heartbeat resulted in port change (from: 0 to: 64999)
..where mm.nn.kk.pp represent the HEX values for the userA public IP address and the 64999 (in this example only) represents the SIP signaling port for userA
185921.738995 =========== OpenPorts!
185921.832238 Public mapping: m.n.k.p:64998
185921.923213 Public mapping: m.n.k.p:64991
185922.014215 Public mapping: m.n.k.p:65018
185922.104986 Public mapping: m.n.k.p:65098
...where m.n.k.p represents the public IP of userA (Tiger iChat3 in this case), and the 64xxx and 65xxx umbers represent the ports opened for A/V and A/V control. In other words, these are the mappings for the "typical" 16384, 16385, 16386, 16387 ports.
As long as both users have connectivity to the SNATMAP server, these "mappings" should proceed without problems, right ??
If both endpoints/users get these mappings, which appear to happen auto-magically between iChat and the SNATMAP server at "snatmap.mac.com:5678", iChat should move to the next phase which is to simply establish the point-to-point SIP call. Up to this point, I don't see why any port-mapping or for that matter, anything else needs to be done ?
Of course, AFTER this point, one does need to make sure no local computer "application" firewall is blocking 5190, 5060, 5678, 16384-16403 (Tiger) or 5190, 16384(or 16393?)-16402 (Leopard) .
If all is well to this point, and iChat actually sends a valid SIP:invite to the remote public SIP IP/port, with a valid SDP section, it's up to whether the endpoints can agree on the session parameters (ie; video codec, bitrate, frame-rate, etc..etc...)
Of course, there are many other things that could happen outside of iChat, like bad (or even good) installed software causing some weird problems, or running some application like virtualization or Internet Sharing that may have some "interop" issue...and maybe even a Service provider simply blocking the ports that the NAT has used (unlikely since they are probably different for every user and determined by each users NAT router)...but if you look at the iChat errorLogLevel7 debug output (preferably on both ends at the time of the call), you should be able to determine if iChat is sending a valid Invite...which is the prmary key in all of this.
Lastly, I have read about "symmetric" NAT routers which might actually pose a real problem even when using the SNATMAP server. This is because a symmetric NAT router will only allow traffic from the destination port that a source port was opened to...which in iChat's case is usualy the SNATMAP server. So it may not be possible to "open ports" via te SNATMAP server, but then get incoming SIP/video traffic from userB. In this case, then UPnP or NAT-PMP, or port-forwarding/triggering may help.
Just some thoughts for discussion.

Answer 1

Your totally right,
and from al the discussions here it seems that not every body knows that, and might be looking for the wrong answers. I wonder why Apple doesnot tell us how it is meant to work, and how to troubleshoot connections problems!
Ichat uses the SIP protocol and should work without any firewall/NAT configurations, for an explanation see http://en.wikipedia.org/wiki/SessionInitiationProtocol
I have seen it work out of the box for several installations (single iMac, OS X 10.5, behind one ADSL router). In one situation i had to switch of the SIP helper application in the router
My own home network has 2 macs however, and sometimes it works and sometimes not.
1) I found out that for local videochats i have to use the bonjour accounts, is that correct ? It should work with .MAC accounts too?
2) for external communications i found out it is best to to stick to one Mac. When I switch from one to the other, using the same account (after logging out first), it often doesnot work, although it should. Any idea how to troubleshoot this problem? (now I rember I have to check this SIP helper application first
3) when i setup a video chat to my mam who uses autoaccept, i am not able to take over the screen. Without autoaccept it works fine. So it looks like autoaccept won't allow you to share the screen.