Ralph Johns

iChat Information Pages

 


A Fuller Error Log with Comments

This page contains a long example Log and with comments. Variants are listed below the long example

It uses repeats of the wide panel at the top of other pages as I needed the width. The only edits are to add the comments and to remove the Names and some repeats that did not add anything at this stage.

This log was picked because of several things. 1) It lists the PING and Bandwidth Checks, 2) It has a general quirkiness about the issues it appears to throw up as to being the cause of the problems and 3) those multiple possible's point out that you have to check deeper than the plain plum comments suggest.

Most comments are in a sort of plum colour with one or two in Red to highlight their importance. It is broken into sections fof ease of reading.

Start of Log

Date/Time:      2008-01-18 22:12:01.638 +0000
OS Version:     10.5.2 (Build 9C16)      Make sure the iChat version you have goes with the OS version
Report Version: 4						  This is not the Error Log Number

iChat Connection Log:
2008-01-18 22:11:41 +0000: AVChat started with ID 4007168636.
2008-01-18 22:11:41 +0000: 0x9d4dc20: State change from AVChatNoState to AVChatStateWaiting.
2008-01-18 22:11:41 +0000: name edit: State change from AVChatNoState to AVChatStateInvited.
2008-01-18 22:11:45 +0000: 0x9d4dc20: State change from AVChatStateWaiting to AVChatStateConnecting.
2008-01-18 22:11:45 +0000: name edit: State change from AVChatStateInvited to AVChatStateConnecting.
2008-01-18 22:11:59 +0000: 0x9d4dc20: State change from AVChatStateConnecting to AVChatStateEnded.
2008-01-18 22:11:59 +0000: 0x9d4dc20: Error -8 (Did not receive a response from 0x9d4dc20.)
2008-01-18 22:11:59 +0000: name edit: State change from AVChatStateConnecting to AVChatStateEnded.
2008-01-18 22:11:59 +0000: name edit: Error -8 (Did not receive a response from 0x9d4dc20.)

The above is the Header paragraph

Variant seen in iChat 4

but in this LOG
Video Conference Error Report:			This one is iChat 4 specific for the next few lines
148.222939 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]  It is saying though that some ports surrounding this SIP part were not agreed fully
[]
150.224952 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]
[]
1283.176736 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]
[]
1285.180538 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]
[]
1287.188405 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]
[]
1289.190978 @SIP/SIP.c:2719 type=4 (900A0015/0)
[SIPConnectIPPort failed]
[]


Video Conference Support Report:
10.247337 @Video Conference/VCInitiateConference.m:1582 type=2 (00000000/0)
[Connection Data for call id: 1 returns 1
]
[]
10.615405 @Video Conference/VCInitiateConference.m:1597 type=2 (00000000/0)
[Prepare Connection With Remote Data - remote VCConnectionData: 1, local VCConnectionData: 1
]
[]
133.293480 @Video Conference/VCInitiateConference.m:1582 type=2 (00000000/0)
[Connection Data for call id: 2 returns 1
]
[]
140.177449 @Video Conference/VCInitiateConference.m:1597 type=2 (00000000/0)
[Prepare Connection With Remote Data - remote VCConnectionData: 1, local VCConnectionData: 1
]
[]
140.186070 @Video Conference/VCInitiateConference.m:1701 type=2 (00000000/0)
[Initiate Conference To User: u0 with Remote VCConnectionData: 1 with Local Connection Data:
 1 conferenceSettings: 1]
[]

The above is a bit iChat 4 specific and not seen in logs from iChat 3

The Effect Start

146.221606 @SIP/Transport.c:2362 type=1 (00000000/0) The real info starts here
[INVITE sip:user@rip:16402 SIP/2.0 Means Invite the Buddy on Port 16402 (rip is Remote IP)

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK2bd4b45f609db43d lip is Local IP (You)
Max-Forwards: 70	This is  the number of servers  Max that you can go through in case it Loops
To: "u0" 	At this first INVITE the Buddy is not identified
From: "0" ;tag=486167384 This a number given to you for this attempt at the SIP Server
Call-ID: b9ef4fb2-c60f-11dc-8444-fabe14394012@lip A mixture of your IP and Tag info
CSeq: 1 INVITE	The Part of the call/SIP process that iChat us up to. This and the "Via" line are linked
Contact: ;isfocus This line will tell you who started the Call

User-Agent: Viceroy 1.3	The type of AIM Client (Application) involved. Viceroy is iChat
Content-Type: application/sdp
Content-Length: 611
Should be a gap here

v=0 o=ralphjohns 0 0 IN IP4 lip Your Account on your Mac name s=0 c=IN IP4 lip b=AS:2147483647 t=0 0 a=hwi:34:2:999 a=iChatEncryption:NO a=bandwidthDetection:YES m=audio 16402 RTP/AVP 12 3 0 A listing of the Port your iChat will conduct the Audio a=rtcp:16402 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpID:1875531494 m=video 16402 RTP/AVP 123 126 34 Same for Video a=rtcp:16402 a=rtpmap:123 H264/90000 a=rtpmap:126 X-H264/90000 a=rtpmap:34 H263/90000 a=fmtp:34 imagesize 1 rules 15:352:288 a=framerate:15 My computer can only do 15 fsp a=RTCP:AUDIO 16402 VIDEO 16402 In iChat 2 and 3 these two and the two above will list 4 ports in total
They will be 16384-16387 inclusive
a=fmtp:126 imagesize 0 rules 15:160:120:160:120:15 a=fmtp:123 imagesize 0 rules 15:160:120:160:120:15 a=rtpID:2387539851

Edit: Several repeats of the INVITE stage removed to shorten

This point also marks and edit of taking out several repeats of the two parts to the INVITE part

Before the Responses from Buddy


]
[]  Two bits of iChat 4 feedback
615.936983 @Video Conference/VCInitiateConference.m:1582 type=2 (00000000/0)
[Connection Data for call id: 4 returns 1
]
[]
616.162160 @Video Conference/VCInitiateConference.m:1597 type=2 (00000000/0)
[Prepare Connection With Remote Data - remote VCConnectionData: 1, local VCConnectionData: 1
]
[]
765.769626 @SIP/Transport.c:2362 type=1 (00000000/0)  iChat 3 logs will detail this point on
[INVITE sip:user@rip SIP/2.0
Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK10da98fa5cfa274f
Max-Forwards: 70
To: "u0" 
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 1 INVITE
Contact: ;isfocus
User-Agent: Viceroy 1.3
Content-Type: application/sdp
Content-Length: 615 

v=0 o=ralphjohns 0 0 IN IP4 sip s=0 c=IN IP4 sip b=AS:2147483647 t=0 0 a=hwi:34:2:999 a=iChatEncryption:NO a=bandwidthDetection:YES m=audio 16402 RTP/AVP 12 3 0 a=rtcp:16402 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpID:1771949721 m=video 16402 RTP/AVP 123 126 34 a=rtcp:16402 a=rtpmap:123 H264/90000 a=rtpmap:126 X-H264/90000 a=rtpmap:34 H263/90000 a=fmtp:34 imagesize 1 rules 15:352:288 a=framerate:15 a=RTCP:AUDIO 16402 VIDEO 16402 a=fmtp:126 imagesize 0 rules 15:160:120:160:120:15 a=fmtp:123 imagesize 0 rules 15:160:120:160:120:15 a=rtpID:2713342512

AS you will see next this marks the end of the INVITE Part. This in turn is only part of the SIP Process

The SIP Text code Contact Progression: Responses from Buddy

The "Trying", "Ringing" and "ACK" parts

]
[]
765.911055 @SIP/Transport.c:347 type=2 (00000000/0)
[SIP/2.0 100 Trying  Change is SIP State to this text Code and number "100 Trying"
Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK10da98fa5cfa274f
To: "u0" 
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 1 INVITE  Trying is still part of the INVITE part
User-Agent: Viceroy 1.2
Content-Length: 0

] [] Notice it does not repeat the Port Offer 765.911512 @SIP/Transport.c:347 type=2 (00000000/0) [SIP/2.0 180 Ringing Straight in to "180 Ringing" Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK10da98fa5cfa274f To: "u0" ;tag=617747169 Buddy has a Number now From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 1 INVITE Contact: User-Agent: Viceroy 1.2 This Number has changed in this Log to a Lower version See below Content-Length: 0

] [] 766.367116 @SIP/Transport.c:347 type=2 (00000000/0) [SIP/2.0 200 OK If progress is still being maintained 200 OK should appear Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK10da98fa5cfa274f To: "u0" ;tag=617747169 From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 1 INVITE Contact: User-Agent: Viceroy 1.2 Content-Type: application/sdp Content-Length: 394

] [v=0 o=Edit name 0 0 IN IP4 rip Buddy's User name on their Mac and the rip bit appears s=0 c=IN IP4 rip Basically confirms that Buddy is using IPv4 rather than IPv6 b=AS:2147483647 t=0 0 a=hwi:133:1:800 a=bandwidthDetection:YES a=iChatEncryption:NO m=audio 16386 RTP/AVP 12 Notice Port Change as this user is using iChat 2 or 3 a=rtcp:16387 a=rtpID:160417885 m=video 16384 RTP/AVP 34 and Video a=rtcp:16387 a=RTCP:AUDIO 16387 VIDEO 16385 Now the two remaining ports of the 4 iChat 2 and 3 use a=rtpmap:34 H263/90000 Also notice that this person is on the H263 Quicktime Codec
so possibly very early iChat 3 or is iChat 2. Most likely is in Panther with Quicktime 6.x
a=fmtp:34 imagesize 0 rules 15:176:144 a=framerate:15 a=rtpID:564681666

] 766.367860 @SIP/Transport.c:2362 type=1 (00000000/0) [ACK sip:user@rip SIP/2.0 Now this has Changed to ACK(nowledge) Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK3bfe5f2b003366e4 Max-Forwards: 70 To: "u0" ;tag=617747169 From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 1 ACK This Call Sequence Line also changes User-Agent: Viceroy 1.3 Content-Length: 0

It tends to have all of these three above if one is shown. If it does not check the Port the Buddy's SIP appears to be On. In iChat 3 they will list port 5060, iChat 4 will be 16402 and AIM on a PC will be 5061

Specifically about this log so far is that the Buddy says they are using port 16402 suggesting they are on Leopard and iChat 4 - but then it notes Viceroy 1.2 and the Quicktime Codec H263 and the Ports from their end suggest pre iChat 4 ones (16384-16407). It is probably this mismatch that adds or creates the time delay which adds to the repeats of various stages in addition to the low speed that cause this chat to fail.

SIP Subscribe and Notify

Subscribe and Notify

If your Log gets to this stage then it is failing at the last stage. Check for quirks like this log has about mismatching of info about ports and Client type, along with how long the Chat took to fail. A long pause waiting to get a connection - or more commonly failure with a long wait - will be reflected by many repeats particularly in the MESSAGE section.

]
[]
766.496377 @SIP/Transport.c:347 type=2 (00000000/0)
[SUBSCRIBE sip:user@lip:16402 SIP/2.0  Another bit of SIP Text code.
Via: SIP/2.0/UDP rip;branch=z9hG4bK44240ed150c85dd3
Max-Forwards: 70
To: "0" ;tag=692210660
From: "u0" ;tag=617747169
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 1 SUBSCRIBE  Again this line matches it
Contact: 
Event: conference  This is what the Buddy is subscribing to 
Expires: 3600	 This is an anti-loop feature to get the SIP part to check it is still active
User-Agent: Viceroy 1.2
Content-Length: 0

] [] 766.497579 @SIP/Transport.c:2362 type=1 (00000000/0) [SIP/2.0 200 OK As this section shows SUBSCRIBE is still part of the "200 OK" part Via: SIP/2.0/UDP rip;branch=z9hG4bK44240ed150c85dd3 To: "0" ;tag=692210660 From: "u0" ;tag=617747169 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 1 SUBSCRIBE Contact: ;isfocus Expires: 3600 User-Agent: Viceroy 1.3 Content-Length: 0

] [] 766.499197 @SIP/Transport.c:2362 type=1 (00000000/0) [NOTIFY sip:user@rip SIP/2.0 NOTIFY is where the two ends confirm which ports to use for Audio an Video Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK44781790497886ab Max-Forwards: 70 To: "u0" ;tag=617747169 From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 2 NOTIFY Again this line matches the Status change Contact: ;isfocus Event: conference Subscription-State: active;expires=3600 Confirms the Check on loop time User-Agent: Viceroy 1.3 Content-Type: application/conference-info+xml Content-Length: 0

This algebra type looking bit is that port exchange

<c-i v="0" st="f" en="sip:user@lip:16402"> <u u="-" x="-1" n="0"><s>c</s><h>i</h><m t="a"/><m t="v"/></u> <u u="-" x="0" n="u0"><s>c</s><h>o</h><m t="a"/><m t="v"/></u> </c-i>

This HTML tagged like section is a seminal moment in a connection sequence. It takes all the "0" (you) and "u0" (your Buddy) and the relevant c IP address and o naming bits along with the variant m bits to say what ports which part of the chat is on.

Bandwidth and PING

This Log list the Bandwidth check here. It will come after the algebra bit above in iChat 4. You may not see it in iChat 3. However as noted in the plum comments the PING is most important. If it is missing it is likely it is being Blocked by your Modem or router - or if you know you have sorted this then the Buddy is not getting to the same point to send one

]
[]
766.641589 @SIP/Transport.c:347 type=2 (00000000/0)
[SIP/2.0 200 OK
Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK44781790497886ab
To: "u0" ;tag=617747169
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 2 NOTIFY
User-Agent: Viceroy 1.2
Content-Length: 0

Exactly what sort of info you get after this point can vary ] [] 766.695048 @:0 type=1 (00000000/0) This section deals with whether the connection is fast enough [Bandwidth Detection] [Received the first BWD packet from rip:16384] 766.939055 @:0 type=1 (00000000/0) [Bandwidth Detection] [Avg=5598088.50, NSDev=56.32%] 767.440573 @:0 type=1 (00000000/1) [Bandwidth Detection] [Avg=15194539.00, NSDev=75.39%] 767.910236 @:0 type=1 (00000000/2) [Bandwidth Detection] [Avg=2191025.40, NSDev=24.66%]

780.007007 @SIP/Transport.c:2362 type=1 (00000000/0) [MESSAGE sip:user@rip SIP/2.0 MESSAGING is the next SIP step Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK47e1dde47e6be535 Max-Forwards: 70 To: "u0" ;tag=617747169 From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 3 MESSAGE This line will detail how many times it does this bit User-Agent: Viceroy 1.3 Content-Type: text/plain Content-Length: 4

PING] This should be seen in any Log.
If it is not there it is likely the Ping is being blocked in your Modem or Router
Basically it a way that iChat checks that where it sent the Visible Invite is where
the SIP INvite is also going to
[] 780.226332 @SIP/Transport.c:347 type=2 (00000000/0) [SIP/2.0 200 OK Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK47e1dde47e6be535 To: "u0" ;tag=617747169 From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 3 MESSAGE User-Agent: Viceroy 1.2 Content-Length: 0

MESSAGE and BYE

The INVITE always says it is Call Sequence 1 (CSeq: 1). I cannot say I have seen repeats of other part of the SIP text counting themselves like MESSAGE does. It often starts at 1 and i would be curious about this one jumping to 3 above and then repeating the number

]
[]
810.007075 @SIP/Transport.c:2362 type=1 (00000000/0)
[MESSAGE sip:user@rip SIP/2.0
Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK66d08f5546f5a932
Max-Forwards: 70
To: "u0" ;tag=617747169
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 4 MESSAGE    It looks like It got stuck at this point
User-Agent: Viceroy 1.3
Content-Type: text/plain
Content-Length: 4


]
[]
961.565724 @SIP/Transport.c:2362 type=1 (00000000/0)
[BYE sip:user@rip SIP/2.0  This is an SIP End Message (same as you saying Goodbye on the Phone)
Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK11fbdc8335cb08bd
Max-Forwards: 70
To: "u0" ;tag=617747169
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 10 BYE  The Call Sequence confirms the BYE
User-Agent: Viceroy 1.3
Content-Length: 0

] [] 961.723256 @SIP/Transport.c:347 type=2 (00000000/0) [SIP/2.0 200 OK Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK11fbdc8335cb08bd To: "u0" ;tag=617747169 From: "0" ;tag=692210660 Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip CSeq: 10 BYE User-Agent: Viceroy 1.2 Content-Length: 0

.......... Repeats 5 through 9 removed .......

Seeing a BYE message in a LOG is not good. It means that one end has ended the call in such a way that iChat thinks it has been ended legitimately.- or at least that is what BYE is supposed to mean (i.e. only in successful chats so you would never see them). In this case the log continues with more attempts at the INVITE Stage again so something is amiss. However seeing it also tells you that essentially your Buddy was contacted and issue is less likely to be LAN layout at one end and mat even eliminate ports if the "correct" ones are shown in the Log.

NO Resource: Easy to miss small type

In this case the LOG tells us in this Notify that the issue as it sees it is about No Resource. Most commonly it is that fact that no data has been received on one port - you have Video and no Audio for Instance or more likely Audio with no Video. An absence of both with give you a "NO Data for 10 Secs" message and a different Log Error number.

Don't presume straight away that your Buddy has a problem with his camera. This log hints at several things that need checking and eliminating;-

  1. Is the other end really on Quicktime 6 ? Quicktime 7.x gives you the H264 codec which iChat should use in Preference
  2. Consider then they might be in Panther with only Quicktime 6 or have issues with a later install
  3. Check they have not tried to (re)install iChat 3 on a Leopard OS Install which might also be causing the Quicktime Issue and the delays. The Changing between Viceroy versions at their end and this but with the Leopard/iChat 4 port suggest this.
  4. As Speed of the Internet or Bandwidth they are accessing seems to be an issue get them to check that as well
]
[]
961.725283 @SIP/Transport.c:2362 type=1 (00000000/0)
[NOTIFY sip:user@rip SIP/2.0
Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK6f9c72fe75ab65e1
Max-Forwards: 70
To: "u0" ;tag=617747169
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 11 NOTIFY
Contact: ;isfocus
Event: conference
Subscription-State: terminated;reason=noresource  It has gone back to NOTIFY 
and has this Message about No Resource. Judging by the fact there are Many repeats and the Speed % in the Bandwidth check suggest it was a Speed issue.
User-Agent: Viceroy 1.3 Content-Length: 0

General Quirkiness

Consider all the things you can spot in a LOG. Apply broad strokes as well as looking into the nitty-gritty. There are lots of odd things in this LOG.

This LOG goes on in this section with jumping numbers. This suggests it has dropped or missed some information from the other. I know that my iChat works and that my set up is as clean to the Internet in terms of IP addressing as it can be. SO I KNOW it this one is at the other end and that for some reason it is not keeping up. The Bandwidth percentages above and the detail in the final section seem to point to a internet or bandwidth speed issue. That and the Quicktime issue at their end would need sorting first

This log also goes back to repeating the INVITE for several attempts. Seeing looping like this before the next Title Video Conference User Report: is not good. It is common to see the information repeated under the different Titles the clues then can be the differences.

]
[]
961.870217 @SIP/Transport.c:347 type=2 (00000000/0)
[SIP/2.0 200 OK
Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK6f9c72fe75ab65e1
To: "u0" ;tag=617747169
From: "0" ;tag=692210660
Call-ID: 2b33808e-c611-11dc-8444-b79e9d464012@lip
CSeq: 11 NOTIFY   Umm the 11th Notify ?  Definitely something wrong with the Feed back/interchange.
User-Agent: Viceroy 1.2
Content-Length: 0

] [] 1281.176106 @SIP/Transport.c:2362 type=1 (00000000/0) [INVITE sip:user@rip SIP/2.0 Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK192c63c5496c450d Max-Forwards: 70 To: "u0" From: "0" ;tag=1109445896 Call-ID: 5e65bc50-c612-11dc-8444-911fdbda4012@lip CSeq: 1 INVITE It is starting again Contact: ;isfocus User-Agent: Viceroy 1.3 Content-Type: application/sdp Content-Length: 615

.... a number (about 9) of Repeats of the new INVITE removed.....

The Final Part

This Titled section before the " Binary Images for "iChat"  " bit is a sort of summary of what happened. You can see that there is a serious Speed issue and that only about 3 secs worth of data actually got through.

Video Conference User Report:  This is one of the Titles listed on page 16a
The Section below is a sort of Summary about the Attempts it has made and what the responses were.
0.000000 @:0 type=5 (00000000/16402)
[Local SIP port]
[]
150.415022 @Video Conference/VideoConferenceMultiController.m:1474 type=5 (00000000/0)
[IP And Port Data With Caller IP And Port Data: Obtained 120 bytes of local IP and port data (3 entries).  
Remote data was 0 bytes (0 entries). This is a common number (0) to see in failed chats ] [] 754.970054 @Video Conference/VideoConferenceMultiController.m:1474 type=5 (00000000/0) [IP And Port Data With Caller IP And Port Data: Obtained 120 bytes of local IP and port data (3 entries).
Remote data was 0 bytes (0 entries). ] [] 765.687548 @Video Conference/VideoConferenceMultiController.m:1507 type=5 (00000000/0) [Initiate Conference To User Cert Version: u0 with 80 bytes of connection data. This means something got passed to you - but not enough ] [] 768.287533 @:0 type=5 (00000000/60) [Detected bandwidth (kbits/s): 390 up, 390 down. (00000000) This is in kilobits
(the min is 100kilobytes/sec This is about 48kilobytes Probably Dial-up or possibly
a Screen Share in iChat 4)
] [] 768.310437 @Video Conference/VideoConferenceMultiController.m:1958 type=5 (00000000/0) [Start Conference With UserID: u0] [] 1276.065811 @Video Conference/VideoConferenceMultiController.m:1474 type=5 (00000000/0) [IP And Port Data With Caller IP And Port Data: Obtained 120 bytes of local IP and port data (3 entries).
Remote data was 400 bytes (10 entries). ] [] 1281.077661 @Video Conference/VideoConferenceMultiController.m:1507 type=5 (00000000/0) [Initiate Conference To User Cert Version: u0 with 400 bytes of connection data. ] []

The "Binary Images" Line

Binary Images Description for "iChat":  .......

The log does continue as you will see in your own, but the usefulness of the bits below this point is Nil. Well...., if you have Add-Ons list in the first few lines (About 3 or 4 in iChat 2 and 3 and anything up to about 15 in iChat 4) it is worth Checking they are up to date.

Please do not post the info below this line on the Apple Discussion Forums unless asked. The same goes for Emailing me with logs

Variants.

IP details

Sometimes when the PIng is shown you get to see the IP (in this case A LAN IP but sometimes their Public IP) of your Buddy. This can provide checks on whether their LAN is sorted out.

 
[PING]
[]
38.061625 @SIP/Transport.c:347 type=2 (00000000/0)
[SIP/2.0 200 OK
Via: SIP/2.0/UDP sip:16402;branch=z9hG4bK4ae86f48420e8157
To: u0 <sip:user@192.168.11.2:16402>;tag=506858487
From: 0 <sip:user@lip:16402>;tag=1912370167
Call-ID: 18c8f0e4-c54b-11dc-a8eb-bbeee8514012@192-168-11-2
CSeq: 2 MESSAGE
User-Agent: Viceroy 1.3
Content-Length: 0
]

Incoming Chats

Here the "To" and "From" are the other way round. The Call ID may List the @(IP address) at the end and the isfocus line may be absent.

Video Conference Support Report:
0.000000 @SIP/Transport.c:2362 type=1 (00000000/0)
[SIP/2.0 200 OK

Via: SIP/2.0/UDP 66.26.xxx.xxx:16402;branch=z9hG4bK668cf68705ef5e9a

To: 0 <sip:user@lip:16402>;tag=1912370167 To is to lip

From: u0 <sip:user@192.168.11.2:16402>;tag=506858487

Call-ID: 18c8f0e4-c54b-11dc-a8eb-bbeee8514012@192-168-11-2

CSeq: 1 INVITE

Contact: 

User-Agent: Viceroy 1.3

Content-Type: application/sdp

Content-Length: 414

isfocus detail

It is more common for the Contact... ....isfocus line to contain more info than the long example

Contact: <sip:user@lip:16402>;isfocus is a more common look to it

Summary

On the whole the logs do tend to follow a pattern that you can get to see where the oddities are

They tend to be;-

  1. The Buddy's SIP port listed in the Invite section is not open iChat uses
  2. This can lead to the "m" items not listing iChat ports for Audio and Video ports once some contact has been made with them
  3. Check your ports listed before the Buddy Info shows up.
  4. It can then depend how much info is in the log which in turn may indicate how far the SIP process has progressed
  5. The amount of data at the end that it says has been passed may indicate partial success or not.
  6. The items such as the noresource example may only be listed once but give great clues as to what is going on
  7. Endless or at least many repeats of the same part of the SIP Process may give clues towards speed issues at one end as will missed numbers in those CSeq bits that count each one.
  8. the things that appear to be variants between logs can give clues. If the same Buddy is failing again and again compare the Logs side by side as it were line by line and see if anything changes.

Remember you do not get a Log if your Buddy refuses the Connection. He or She must have accepted to get a LOG. The references in Error -8 Logs that there was No Response is one at the SIP Level not the Visible one.

Information Block

This site is about iChat from Version 1 through to iChat 4.x.x

It has a mixture of basic info and problem solving help.

The setions below will change for Specifics about info on the page on view

If you find these pages helpful please Donate to help keep them up to date

Compatibility

Confirmed to work with Win/IE 5.5 and later (should work in 5.0, but not confirmed), Firefox 2, Safari 3, Opera 9, iCab 3.02 and later, Mac/IE 5, Netscape 6 and later

Old browsers (IE version 4 or earlier, Netscape 4 or earlier) should only see a text-based page which, while not the prettiest option, is still entirely usable.

About This Page