Video/Voice Conference -8 Error Explained for Cisco Routers

Question

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 IN THE SDP. 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 <public IP>: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 <public IP>: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-><public IP>
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.
Hopefully we can figure out why iChat's SNATMAP implementation doesn't work with a Cisco NAT next...

Answer 1

Hi
Ok for the Homehub's.
UPnP should be enabled.
Set the Quicktime streaming setting, goto sys prefs/quicktime/streaming/streaming speed, set to 1.5mbps(dont use automatic)
In ichats prefs click on video and change bandwidth limit to NONE.
Goto to sys prefs/sharing/firewall and turn on(dont add any ports for ichat, leave anything that is ticked ticked).
Restart ichat.
And try connecting to me defcom1 .mac account.
Tony