iChat video/screensharing works locally but not over the WAN.

Question

Level 1

12 points

iChat video/screensharing works locally but not over the WAN.

Hello All, First i want to explain how my company is setup. We have multiple office across 3 different states. I have a local jabber server installed on a MAC Pro Server in the main office. I have a SonicWall NSA 3500 with the proper ports opened (according to this TCP and UDP ports used by Apple software products - Apple Support). All the other offices use a variety of models of Airport Extreme's with NAT mapping protocol enabled. The MAC OS X varies on the client iMacs from 10.7.5 to 10.10.4 depending on the office.

Starting about 4 months ago my company began experiencing iChat video and screensharing connection problems. It started as just being intermittent with 1 or 2 users throughout the day. At this time a simple NVRAM and PRAM reset would resolve the connection issues between users. Then the entire company was experiencing an entire day where no-one could video chat except locally within the office, then the following day it would be functioning properly. This happened for about a month. Then about 2 weeks ago iChat Video and Screensharing stopped working altogether company wide.

During this time i have completely rebuilt the Server, upgrading from Lion Server to Yosemite. I have had Apple Tier 2 tech support connect and build the Messages server from scratch. Apple Tier 2 tech support mentioned that the local Messages server intended use is for local office and that it is working as intended, (even though this was in use with our current business model for 3 years). He recommended a 3rd party jabber server. I currently have installed Openfire Jabber Server and configured properly and am still experiencing the same exact problems. I have also contacted my SonicWall Vendor tech support 3 different occasions and they have verified the settings on the firewall are configured correctly and noted nothing wrong with the NSA 3500. I have contacted my ISP Fiber provider and they have verified they are not blocking ports and have verified their equipment is fully operational.

Here are things i know.

iChat video and screen sharing works locally at each office but not across subnets.
The Packet Capture that my SonicWall noticed the SIP packet going from my Client Machine to the distant end on port UDP 16402 but when the distant end clicks accept there is no return packet to the firewall on port 16402.
iChat video will work if connected through VPN but crashes after 30 minutes and is unable to connect again. Same SIP error noted in the logs below.

Below is the error log we receive when we try video chat or screen sharing.

Date/Time: 2015-07-16 10:32:06 -0700

OS Version: 10.10.4 (Build 14E46)

Report Version: 4

Messages Connection Log:

2015-07-16 10:31:23 -0700: 0x608000190740: State change from No State to Invited.

2015-07-16 10:31:45 -0700: 0x608000190740: State change from Invited to Connecting.

2015-07-16 10:31:53 -0700: 0x608000190740: State change from Connecting to Ended.

2015-07-16 10:31:53 -0700: 0x608000190740: Error 1008 (Did not receive a response from 0x608000190740.)

Video Conference Error Report:

86754.568112 @/SourceCache/VideoConference/VideoConference-473/SIP/SIP.c:2255 type=4 (900A0015/0)

[SIPConnectIPPort failed]

[]

Video Conference Support Report:

0.000000 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:2144 type=1 (00000000/0)

[SIP/2.0 200 OK

Via: SIP/2.0/UDP 172.16.100.100:16402;branch=z9hG4bK6e49cf83135c0092

To: 0 <sip:user@lip:16402>;tag=610441441

From: u0 <sip:user@172.16.100.100:16402>;tag=928253306

Call-ID: 1e52b168dfe353e-2b16-11e5-b5cf-e2bf9f2b4012@172-16-100-100

CSeq: 1 INVITE

Contact: <sip:user@lip:16402>

User-Agent: Viceroy 1.4

Content-Type: application/sdp

Content-Length: 395

v=0

o=mmobley 0 0 IN IP4 lip

s=1001

c=IN IP4 lip

b=AS:2147483647

t=0 0

a=hwi:1056:4:3200

a=bandwidthDetection:YES

m=audio 16402 RTP/AVP 110

a=rtcp:16402

a=rtpmap:110 X-AAC_LD/22050

a=rtpID:2153114169

m=video 16402 RTP/AVP 123

a=rtcp:16402

a=rtpmap:123 H264/90000

a=RTCP:AUDIO 16402 VIDEO 16402

a=fmtp:123 imagesize 0 rules 20:640:480:640:480

a=rtpID:1866507574

]

[]

0.053686 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:343 type=2 (00000000/0)

[ACK sip:user@lip:16402 SIP/2.0

Via: SIP/2.0/UDP 172.16.100.100:16402;branch=z9hG4bK3adb2dda291546d8

Max-Forwards: 70

To: 0 <sip:user@lip:16402>;tag=610441441

From: u0 <sip:user@172.16.100.100:16402>;tag=928253306

Call-ID: 1e52b168dfe353e-2b16-11e5-b5cf-e2bf9f2b4012@172-16-100-100

CSeq: 1 ACK

User-Agent: Viceroy 1.4

Content-Length: 0

]

[]

0.155914 @:0 type=1 (00000000/0)

[Bandwidth Detection]

[Received the first BWD packet from 172.16.100.100:16402]

0.522277 @:0 type=1 (00000000/0)

[Bandwidth Detection]

[Avg=100649.30, NSDev=55.57%]

0.658062 @:0 type=1 (00000000/1)

[Bandwidth Detection]

[Avg=853679.30, NSDev=48.42%]

0.772362 @:0 type=1 (00000000/2)

[Bandwidth Detection]

[Avg=2873909.00, NSDev=9.63%]

72.738519 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:2144 type=1 (00000000/0)

[BYE sip:user@172.16.100.100:16402 SIP/2.0

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK10f7cac74a7a8b3e

Max-Forwards: 70

To: u0 <sip:user@172.16.100.100:16402>;tag=928253306

From: 0 <sip:user@lip:16402>;tag=610441441

Call-ID: 1e52b168dfe353e-2b16-11e5-b5cf-e2bf9f2b4012@172-16-100-100

CSeq: 1 BYE

User-Agent: Viceroy 1.4

Content-Length: 0

]

[]

72.826088 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:343 type=2 (00000000/0)

[SIP/2.0 200 OK

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK10f7cac74a7a8b3e

To: u0 <sip:user@172.16.100.100:16402>;tag=928253306

From: 0 <sip:user@lip:16402>;tag=610441441

Call-ID: 1e52b168dfe353e-2b16-11e5-b5cf-e2bf9f2b4012@172-16-100-100

CSeq: 1 BYE

User-Agent: Viceroy 1.4

Content-Length: 0

]

[]

86730.661188 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VCInitiateConference.m:1973 type=2 (00000000/0)

[Connection Data for call id: 5 returns 1

]

[]

86746.567680 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VCInitiateConference.m:1988 type=2 (00000000/0)

[Prepare Connection With Remote Data - remote VCConnectionData: 1, local VCConnectionData: 1

]

[]

86746.588500 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VCInitiateConference.m:2180 type=2 (00000000/0)

[Initiate Conference To User: u0 with Remote VCConnectionData: 1 with Local Connection Data: 1 conferenceSettings: 1]

[]

86752.568495 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:2144 type=1 (00000000/0)

[INVITE sip:user@rip:16402 SIP/2.0

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK456e05ec32f7d26f

Max-Forwards: 70

To: "u0" <sip:user@rip:16402>

From: "0" <sip:user@lip:16402>;tag=1602980090

Call-ID: 1e52be08b3266c0-2be0-11e5-8272-8b7231a74012@lip

CSeq: 1 INVITE

Contact: <sip:user@lip:16402>;isfocus

User-Agent: Viceroy 1.4

Content-Type: application/sdp

Content-Length: 684

v=0

o=mmobley 0 0 IN IP4 lip

s=0

c=IN IP4 lip

b=AS:2147483647

t=0 0

a=hwi:1056:4:3200

a=iChatEncryption:NO

a=bandwidthDetection:YES

m=audio 16402 RTP/AVP 110 12 124 3 0

a=rtcp:16402

a=rtpmap:110 X-AAC_LD/22050

a=rtpmap:3 GSM/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:124 iLBC/8000

a=fmtp:124 mode=30

a=rtpID:2137538099

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 30:352:288

a=framerate:30

a=RTCP:AUDIO 16402 VIDEO 16402

a=fmtp:126 imagesize 0 rules 30:640:480:640:480:30

a=fmtp:123 imagesize 0 rules 30:640:480:640:480:30

a=rtpID:3017826849

]

[]

86753.071798 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:2144 type=1 (00000000/0)

[INVITE sip:user@rip:16402 SIP/2.0

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK456e05ec32f7d26f

Max-Forwards: 70

To: "u0" <sip:user@rip:16402>

From: "0" <sip:user@lip:16402>;tag=1602980090

Call-ID: 1e52be08b3266c0-2be0-11e5-8272-8b7231a74012@lip

CSeq: 1 INVITE

Contact: <sip:user@lip:16402>;isfocus

User-Agent: Viceroy 1.4

Content-Type: application/sdp

Content-Length: 684

v=0

o=mmobley 0 0 IN IP4 lip

s=0

c=IN IP4 lip

b=AS:2147483647

t=0 0

a=hwi:1056:4:3200

a=iChatEncryption:NO

a=bandwidthDetection:YES

m=audio 16402 RTP/AVP 110 12 124 3 0

a=rtcp:16402

a=rtpmap:110 X-AAC_LD/22050

a=rtpmap:3 GSM/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:124 iLBC/8000

a=fmtp:124 mode=30

a=rtpID:2137538099

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 30:352:288

a=framerate:30

a=RTCP:AUDIO 16402 VIDEO 16402

a=fmtp:126 imagesize 0 rules 30:640:480:640:480:30

a=fmtp:123 imagesize 0 rules 30:640:480:640:480:30

a=rtpID:3017826849

]

[]

86754.075857 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:2144 type=1 (00000000/0)

[INVITE sip:user@rip:16402 SIP/2.0

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK456e05ec32f7d26f

Max-Forwards: 70

To: "u0" <sip:user@rip:16402>

From: "0" <sip:user@lip:16402>;tag=1602980090

Call-ID: 1e52be08b3266c0-2be0-11e5-8272-8b7231a74012@lip

CSeq: 1 INVITE

Contact: <sip:user@lip:16402>;isfocus

User-Agent: Viceroy 1.4

Content-Type: application/sdp

Content-Length: 684

v=0

o=mmobley 0 0 IN IP4 lip

s=0

c=IN IP4 lip

b=AS:2147483647

t=0 0

a=hwi:1056:4:3200

a=iChatEncryption:NO

a=bandwidthDetection:YES

m=audio 16402 RTP/AVP 110 12 124 3 0

a=rtcp:16402

a=rtpmap:110 X-AAC_LD/22050

a=rtpmap:3 GSM/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:124 iLBC/8000

a=fmtp:124 mode=30

a=rtpID:2137538099

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 30:352:288

a=framerate:30

a=RTCP:AUDIO 16402 VIDEO 16402

a=fmtp:126 imagesize 0 rules 30:640:480:640:480:30

a=fmtp:123 imagesize 0 rules 30:640:480:640:480:30

a=rtpID:3017826849

]

[]

Video Conference User Report:

0.829876 @:0 type=5 (00000000/60)

[Detected bandwidth (kbits/s): 2302 up, 2302 down. (00000000)

]

[]

0.854043 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VideoConferenceMultiController.m:2447 type=5 (00000000/0)

[Start Conference With UserID: 1001]

[]

86746.567796 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VCInitiateConference.m:2085 type=5 (00000000/0)

[Remote Router]

[FULLCONE]

86746.567802 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VCInitiateConference.m:2087 type=5 (00000000/0)

[Remote CommNAT Result: 0x00000102

]

[]

86746.588503 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VideoConferenceGlobalObjects.m:1679 type=5 (00000000/0)

[Router]

[SYMMETRIC]

86746.588508 @/SourceCache/VideoConference/VideoConference-473/Video Conference/VideoConferenceGlobalObjects.m:1681 type=5 (00000000/0)

[CommNAT Result: 0x000000c4

]

[]

Here are the connection doctor settings

I apologize for the giant wall of text but after 200 + hours of troubleshooting with multiple vendors i am at my wits end. I appreciate any feedback and welcome the help!

Thanks in advance,

Matt Mobley

IT Program Manager

Posted on Jul 16, 2015 11:06 AM

Reply

Answer 1

Jul 16, 2015 1:41 PM in response to ccsmatt

Hi,

We are seeing and increase in these types of posts at the moment.

Mostly they seems to be AIM related but not in all cases.

One Post I have read today said and Apple Level 2 support had "tested" and said it was with AIM.

However I can use AIM to AIM on two computers at my house, one running Yosemite and one using iChat 5.0.3 in Snow Leopard.

I guess you have set the Bandwidth Limit at 2Mbps across all devices and not just yours ?

The Messages/iChat server in the Server OS X is the perfectly good eJabbered version which is used by several of the larger Jabber servers.

It is perfectly capable of doing Internet chats including video (This will depend much more of the spare capacity to your Internet connection.)

http://www.jabberes.org/servers/ The icons with the head on the left are eJabbered.

I would test with IPv6 turned Off on the computers and the server (and possibly the router to make sure).

If the ISP has recently turned this On and you have asked them it may well appear to be "OK".

However iChat and Messages can see it as a second connection sometimes and this can be an issue similar to connecting via both WiFi and Ethernet.

If you are calling another user at your same branch it is still using the Internet.

However like my test this will only be through one router and may eliminate some issues.

The only thing I can see from the log is:-

72.826088 @/SourceCache/VideoConference/VideoConference-473/SIP/Transport.c:343 type=2 (00000000/0)

[SIP/2.0 200 OK

Via: SIP/2.0/UDP lip:16402;branch=z9hG4bK10f7cac74a7a8b3e

To: u0 <sip:user@172.16.100.100:16402>;tag=928253306

From: 0 <sip:user@lip:16402>;tag=610441441

Call-ID: 1e52b168dfe353e-2b16-11e5-b5cf-e2bf9f2b4012@172-16-100-100

CSeq: 1 BYE

User-Agent: Viceroy 1.4

Content-Length: 0

The 200 OK is one of the last text bits of the connection process.

It's done the Calling, Ringing, Acknowledging, Invite bits.

lip = Local IP = you

rip = Remote IP = Buddy

I am presuming that is your LAN IP showing up (your computer shortname also appears in the Log which is good)

The Odd thing is the Call Sequence bit (CSeq) which says BYE when it should not be.

The Error 1008 is a bit of a catch all related to the SIP bit of the call.

This is the bit behind the scenes after you send the "Visible" invite. (it changes port and repeats it and both ends have to signal back and forth to prevent Man-in-the-Middle attacks.

Whilst most of the log looks fine it obviously thinks there is an SIP issue.

However this in turn can be about dual IPs at one or both ends which is why I think it might be IPv6.

The Video ports are-

5678 UDP for the visible Invite

Port 16393 - 16402 which messages uses top down before trying random ports.

Jabber Logins are either port 5222 (non SSL) and 5223 for SSL on the TCP protocol.

AIM is currently using port 443 but has used 5190 in the past.

(Yahoo does not do Video but mostly uses port 80)

Bonjour uses 5353 (it uses this even to show the Shares in the Finder's Side bar)

Then port 5297 and 5298 both on UDP with 5298 also using TCP.

Older iChat versions use a group of 20 (16384-16403) and the port 5060 which is where SIP is supposed to be.

SIP got blocked by lots of ISPs who then wanted extra for opening the ports (there are in fact 4 - 5060 -5063). Apple and Skype then moved away from the Standard ports.

9:41 pm Thursday; July 16, 2015

 iMac 2.5Ghz i5 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

Reply

Answer 2

ccsmatt Author

Level 1

12 points

Jul 17, 2015 9:52 AM in response to Ralph-Johns-UK

Ralph, thanks for the response. I have disabled IPV6 on my SonicWall device for both LAN and WAN connections. I have verified that my iMac and the client offsite only had 1 IPV4 address. We are still experiencing the same problems with video chat across different subnets.

Yesterday we discovered that the local community college had a Video Conferencing device that was configured with our public IP information. We thought this would be the cause of our problems but in the end after disabling and reconfiguring their device we are still in limbo.

I am perusing these iChat forums and notice that it appears many users are experiencing similar problems across multiple clients, OS's, and IM services used with very similar SIP errors. I am beginning to this may be a global client problem.

What i cant figure out is why Facetime, which uses almost identical ports as iChat, works flawlessly across our business.

Reply

Answer 3

Jul 17, 2015 1:09 PM in response to ccsmatt

Hi,

You are right in that there does seem to be a global issue suddenly develop over this.

I can't say whether it is truly global in the sense it is Europe and the United States as well as other continents.

I have seen one post that places the person in the United States (AT&T and Verizon tested).

I am sure I have seen Comcast mentioned somewhere as well.

What it does not seem tied to is a specific OS update.

It also seems to effect both Google (Jabber) and AIM Video Chats, (Presumably Audio Only although no-one has mentioned it) and Screen Sharing.

In almost all people have come from using iChat fro many years before moving to Messages and understand the way the "iChat A/V" chats work and are started.

All those that have posted Logs mention Error 1008 (ports and/or SIP)

I have not got any other suggestions at the moment.

9:09 pm Friday; July 17, 2015

 iMac 2.5Ghz i5 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

Reply

Answer 4

ccsmatt Author

Level 1

12 points

Jul 17, 2015 2:59 PM in response to Ralph-Johns-UK

Ralph, i just wanted to thank you for trying. I have been following your posts for quite some time and because of your insight have solved many of those quirky ichat problems that has arose throughout the years.

My last thought is i wonder if some ISP are now blocking SIP packets on other ports now. Could certainly explain the recent problems several users are reporting with iChat working within their network but not externally.

Reply

Answer 5

Kkanuck

Level 1

4 points

Jul 17, 2015 3:55 PM in response to ccsmatt

I too have been having this problem, but only over the internet, not over my private home network which is Comcast ISP, and Apple Airport Extreme.

I have regularly iterated and screen shared with folks in Europe, and the West coast of the USA from Atlanta, GA.

As of a week or two now, I am unable to communicate with either party via ichat, in both screen sharing and video or audio chat. FaceTime works, but ichat via an Aim account is nonfunctional.

I hope to figure this out as I need to be able to screen share again in the future, and this is one of the main reasons I went with the Apple eco system originally, as it is a very nice functional tool.

I will keep watching these postings in the hopes a solution is found.

Reply

Answer 6

Jul 18, 2015 2:05 PM in response to ccsmatt

Hi,

Blocking SIP on the standard port for it (5060- 5063) never gave the error 1008 (or rather it's iChat equivalent, -8) when that happened.

This looks more like the Backbone Server issue with iChat 3.

At the OS X 10.4 release Apple had changed the Video and Audio Protocol and something to do with the ports.

It turned out that those in charge of the Internet backbone east of the Mississippi had not updated the Servers and claimed they did not know which one were causing the issue (it involved the use of some protocols/ports that had been internationally agreed some 7 years earlier but no-one seemed to ever had made use of them).

The Apple seed and Developers testers don't seem to check ichat (or the numbers are that small and the area effect has few testers that were effected during testing).

The upshot was Apple released a standalone update to iChat to revert the the Video stuff.

Obviously this time Apple have not done an Update that has seen it change in Yosemite, Mavericks and possibly even iChat versions (It is not always clear in the iChat Forum whether people are still using it or talking feature-wise).

AS I said earlier it is effecting Google/Jabber and AIM conversations (A/V chat the "iChat way').

People's locations no longer show up on these discussions so that sort of detail is not always forthcoming and asking about it could be construed by Apple as a Poll and that is against the Terms of Use.

10:05 pm Saturday; July 18, 2015

 iMac 2.5Ghz i5 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

Reply

Answer 7

ccsmatt Author

Level 1

12 points

Jul 23, 2015 8:01 AM in response to Ralph-Johns-UK

Ralph, sorry for the late response as i have been on a business trip.

Most of my business offices are on the state of Oregon. We use a variety of ISP's, the main office is Charter Fiber. Most other offices have Comcast but a few scattered are Charter Cable, Frontier, or Century Link.

The only work around i have found is to configure the distant machine to first connect to our VPN server then initiate the iChat video chat. What i find interesting is that users can iChat video within their prospective offices but not across a different subnet. This to me tells me that the iChat client is functioning properly.

Like others Facetime and Skype work great, however, it is impractical to use for our business needs.

Thanks for your assistance I do appreciate it.

Matt

Reply

Answer 8

ccsmatt Author

Level 1

12 points

Jul 23, 2015 9:06 AM in response to ccsmatt

I have an update. I contacted my ISP, Charter Fiber, and verified that IPV6 isn't enabled on their end. So back to the drawing board. At this point i am all out of ideas as well. Since this appears to be a larger scaled problem that is affecting not only AIM, Google, and independent Jabber services for multiple users at different locations across the country its hard to pinpoint the problem.

Thanks for your efforts, much appreciated.

Reply

Answer 9

Jul 23, 2015 1:00 PM in response to ccsmatt

Hi,

It is the conclusion I am coming to as well.

I am finding no hint as to what has changed, other than it seems to be internet related as AIM and Jabber accounts are effected across various iChat and Messages versions.

Like you report using AIM Accounts I can get it to work between iChat 5.0.3 and Messages 8 in Yosemite but this is through one router.

9:00 p.m. Thursday; July 23, 2015

 iMac 2.5Ghz i5 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

Reply

Answer 10

singerdf

Level 1

42 points

Jul 25, 2015 11:47 AM in response to Ralph-Johns-UK

I too am going to chime in. First, I too would like to Thank Ralph for years of help.

Right after I upgraded to 10.10.4 I started having this issue on our VPN. I assumed it was because I had upgraded. So I upgraded everyone. That did not help. Then I blamed it on the VPN, so I tried to video chat and screen share with my daughter using jabber to jabber accounts. No luck there either. We can screen share with AIM and using the screen share program. So after hours of looking and trying, I tend to think this is Jabber somewhere.

I will keep reading and learning here in the hopes that there is a fix soon. We depend on screen sharing from one site to another.

Debbie

Reply

Answer 11

Jul 25, 2015 12:18 PM in response to singerdf

Hi,

A poster calling themselves Captain 3D has posted in several iChat threads about it effecting iChat 5.0.3 at both ends (America to the UK) Re: Ichat fails to connect to other user

Others have posted they find it is both AIM and Jabber (the two Accounts types from iChat that Video in Messages).

AS of yet we have no idea what has changed on the internet that is causing this.

8:18 p.m. Saturday; July 25, 2015

 iMac 2.5Ghz i5 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

Reply

Answer 12

Dtinen

Level 1

93 points

Jul 28, 2015 10:46 AM in response to Ralph-Johns-UK

For the record, we're using Jabber/Google in Massachusetts USA, from Comcast to a municipal utility, both with a minimum 5 Mbps upload speed, one with OS X 10.6.8 and iChat 5.0.3, the other with 10.8, also trying an alternate Mac with 10.8 and Messages. Problems increased over the last few months...text chats connect fine, but video or screen sharing do something similar to the log above. Today we can't screen share no matter what we try.

Reply

Answer 13

Jul 28, 2015 12:10 PM in response to Dtinen

Understood.

People should report things here http://www.apple.com/feedback/ichat.html (it is the "right" page it just never been updated to reflect Messages).

The lower drop downs also don't get updated so put all info in the free text area.

I have also raised it the Lounge (where Level 6 poster and above can can bring things to the attention of the Hosts).

Hopefully we will hear something sooner or later.

8:10 p.m. Tuesday; July 28, 2015

 iMac 2.5Ghz i5 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

Reply

Answer 14

Aug 6, 2015 5:53 AM in response to Ralph-Johns-UK

Any news from escalating this? Not being able to get into my parents computers via screen sharing is a pain for troubleshooting. And using FaceTime is not as convenient as just clicking on the camera in the buddy list in Messages. I filed feedback on the ichat page as you instructed as well. Love to know what was changed to cause this longstanding feature to break.

Reply

Answer 15

Oct 4, 2015 5:44 AM in response to Jack Rosenzweig

sorry, posted in wrong thread

Reply