Three new Macs ... iChat video won't work over WAN

Question

Hi,
We just bought two iMacs and a MBP, all running Leopard. We can iChat when in the same house on the same wireless network, but when we go back to our homes, it doesn't work. Below is the error. We can use Skype video no problem. iChat text works works fine. We've reinstalled iChat, matched or unmatched the font, reduced the bandwidth in iChat, etc. We haven't altered the router settings. Hope someone has a suggestion. Thanks.
Date/Time: 2008-01-23 20:35:51.339 -0800
OS Version: 10.5.1 (Build 9B18)
Report Version: 4
iChat Connection Log:
2008-01-23 20:35:06 -0800: AVChat started with ID 4010006563.
2008-01-23 20:35:06 -0800: 0x1020e7f0: State change from AVChatNoState to AVChatStateWaiting.
2008-01-23 20:35:06 -0800: [email protected]: State change from AVChatNoState to AVChatStateInvited.
2008-01-23 20:35:38 -0800: 0x1020e7f0: State change from AVChatStateWaiting to AVChatStateConnecting.
2008-01-23 20:35:38 -0800: [email protected]: State change from AVChatStateInvited to AVChatStateConnecting.
2008-01-23 20:35:48 -0800: 0x1020e7f0: State change from AVChatStateConnecting to AVChatStateEnded.
2008-01-23 20:35:48 -0800: 0x1020e7f0: Error -8 (Did not receive a response from 0x1020e7f0.)
2008-01-23 20:35:48 -0800: [email protected]: State change from AVChatStateConnecting to AVChatStateEnded.
2008-01-23 20:35:48 -0800: [email protected]: Error -8 (Did not receive a response from 0x1020e7f0.)
Video Conference Error Report:
Video Conference Support Report:
0.000000 @SIP/Transport.c:2353 type=1 (00000000/0)
[SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK3b770bb024da23e4
To: 0 <sip:[email protected]:16402>;tag=396488263
From: u0 <sip:[email protected]>;tag=333292834
Call-ID: ea0f44a8-c7e1-11dc-92bd-db1e6e2c13c4@192-168-1-5
CSeq: 1 INVITE
Contact: <sip:[email protected]:16402>
User-Agent: Viceroy 1.3
Content-Type: application/sdp
Content-Length: 430
v=0
o=sanaebingham 0 0 IN IP4 192.168.1.7
[email protected]
c=IN IP4 192.168.1.7
b=AS:2147483647
t=0 0
a=hwi:1056:2:2000
a=bandwidthDetection:YES
a=iChatEncryption:NO
m=audio 16402 RTP/AVP 12
a=rtcp:16402
a=rtpID:466551867
m=video 16402 RTP/AVP 126
a=rtcp:16402
a=rtpmap:126 X-H264/90000
a=RTCP:AUDIO 16402 VIDEO 16402
a=fmtp:126 imagesize 0 rules 20:320:240:640:480
a=framerate:20
a=rtpID:3880118170
0.006753 @SIP/Transport.c:347 type=2 (00000000/0)
[ACK sip:[email protected]:16402 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK7244f8cd57b3278a
Max-Forwards: 70
To: 0 <sip:[email protected]:16402>;tag=396488263
From: u0 <sip:[email protected]>;tag=333292834
Call-ID: ea0f44a8-c7e1-11dc-92bd-db1e6e2c13c4@192-168-1-5
CSeq: 1 ACK
User-Agent: Viceroy 1.2
Content-Length: 0
0.007382 @SIP/Transport.c:2353 type=1 (00000000/0)
[SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.7:16402;branch=z9hG4bK25d964740defe840
Max-Forwards: 70
To: u0 <sip:[email protected]>;tag=333292834
From: 0 <sip:[email protected]:16402>;tag=396488263
Call-ID: ea0f44a8-c7e1-11dc-92bd-db1e6e2c13c4@192-168-1-5
CSeq: 1 SUBSCRIBE
Contact: <sip:[email protected]:16402>
Event: conference
Expires: 3600
User-Agent: Viceroy 1.3
Content-Length: 0

Answer 1

We do agree that there is a good possibility that the log that was posted is from a Bonjour (ie; local) iChat session.
The 192.168.1.x subnet is part of an address block assigned by the authorized addressing body as Private addresses. They should not be advertised on the public Internet and are NOT routeable across the public Internet. Also, when you mention other logs in these discussions, aren't most of the logs and/or discussions here of scenarios when something does not work ?? Can you refer to a known, good, working iChat video-chat log going across a WAN/Internet (not a local LAN or Bonjour) that shows both the To: and From: IP addresses as 192.168.x.x ? The bottom line is if the actual transmitted SIP:invite packet (not some possibly inaccurate Log message) has a 192.168.1.x address as the destination IP, I do not think it will work. Some of the Logs that iChat provides do some processing or filtering such that I am not sure that it is an actual packet capture/decode.
Again, I am certainly open to learning something, but my understanding is if the packet put onto the wire is destined to be routed across the Internet to another user behind a NAT router, a destination IP (or a To: address) of 192.168.1.x will not work.
The process when going across the Internet , as I understand, is very simple;
- login to OSCAR server on "typical" port 5190
- after OSCAR authentication, login to BOS server, get Buddy List, "self info" such as publicly visible IP address, etc...
- initiate Chat request to a Buddy (example userB)
- send Chat request message to BOS server requesting Chat with userB, still on port 5190. Chat request includes data indicating the userA public IP address and public SIP signaling port number. UserA may have obtained this info via communication with the SNATMAP server, where it sends a message fom a private (ie; 192.168.x.x.) source IP address and private source port number to the SNATMAP server, which then sends back a message telling the userA what IP and Port were actually received...in other words, the publicly visible IP and port that the NAT router translated the private ones to. Typically the private ones would be 5060, 16384-16403..but others are possible.
- BOS server relays Chat request to userB, including "rendez vous" data which has userA IP address and SIP signalling port number.
- UserB may send back a message via the BOS server to the userA indicating its public IP and public SIP signaling port number as well.
- One end can now initiate the SIP:invite message with the Destination IP and port# equal to the PUBLIC IP/port that was sent in the Chat request
- The public port# should be open since the userA/B would have sent messages to the SNATMAP server so as the "open" the port on the NAT router.
- The SIP:invite message will have an SDP section that will indicate which port numbers to use for Audio, Video, Audio Contol, ad Video Control. Again, these should be the "publicly" visible (ie; Internet side of the NAT router) ports as learned via SNATMAP (or other methods such as UPnP..). The internal values for these ports are typically 16384,16385,16386,16387 for Tiger and 16402 for Leopard. The publicly visible values depend on the specific NAT router and how it translates internal address/port numbers.
- Once each end receives the SIP:invite and SIP:ok with the SDP session parameters, they will negotiate audio, video, etc..parameters..and if they agree, it should work.
The key n all of this is to get the correct SIP signaling port number, and then the correct SDP session attributes which include the A/V and A/V control (ie; RTP, RTCP) port numbers. And, finally these must be public, Internet routeable addresses in order to work across the Internet.