When I run the remote connectivity analyzer configured with sip.domain.com and port 443 everything works and I get a succssful test. When I run it using autodiscover on port 5061 I get the following error:

Testing remote connectivity for user user@domain.com to the Microsoft Lync server. Testing remote connectivity for user user@somain.com to the Microsoft Lync server. Specified remote connectivity test(s) to Microsoft Lync server failed. See details below for specific failure reasons. Additional Details   Couldn't sign in. Error: Error Message: Unable to establish a connection.. Error Type: ConnectionFailureException. The port 5061 is open on the firewall.  Has anyone in the forum experienced this?  Any suggestions why the test fails on 5061 while the other works on 443?   All remote clients seem to function properly with autodiscovery (IOS, ANDROID, WINDOWS)? Thanks!

If you telnet on port 5061 from external, does it work?

It does.  I have redacted the results but according to the analyzer the port test and cert tests pass:

	Testing TCP port 5061 on host sip.domain.com to ensure it's listening and open.
	The port was opened successfully.

Testing the SSL certificate to make sure it's valid.

The certificate passed all validation requirements. It is only when the system attempts to log in with the creds I provided does it fail: Testing remote connectivity for user username@domain.com to the Microsoft Lync server.   Specified remote connectivity test(s) to Microsoft Lync server failed. See details below for specific failure reasons.    <label for="testSelectWizard_ctl12_ctl06_ctl03_tmmArrow">Tell me more about this issue and how to resolve it</label>   Additional Details   Couldn't sign in. Error: Error Message: Unable to establish a connection.. Error Type: ConnectionFailureException.. Thanks for the response.

Must be something else then.

Port 5061 is only used for Federation.

Make sure that your NAT rule from your Firewall and Edge are setup OK.

What does not work exactly:

Full Lync client trying to connect externally?

Desktop sharing, calls, and video fail with federated clients.  
IM presence and chat work fine with federated clients.

Oddly enough if that same federated user places the ?sl=1 at the end of the meeting URL to force the meeting to use the browser and plugins instead of the lync they can attend the meeting and desktop share just fine on the same system/network that failed using federation.  This is currently our work around but I need to resolve.

Thanks,

Ok lets go back to basic: :-)

Lets forget about federated issue, lets forget about the ?sl=1

• So Lync client can sign in externally.  Chat and Presence works.
• Audio, video and desktop sharing fails.

If Audio/Video/Desktop Sharing is failing, verify your firewall rules.

Make sure that your topology builder has the external A/V IP address.

you can  try the RUCT tool:

http://www.insideocs.com/Tools/RUCT/RUCT.htm

• Lync clients sign in externally.  Chat, presence and desktop sharing, audio and video work between them.
• Topology builder has the external A/V ip address.

Federation Solution:

I used my failed sessions from my federated client tests this morning to log denied packets between his edge server to my edge server.  Once I opened the ports to the proper address I was able to chat, video, call, and desktop share with him.  Your suggestion to verify firewall rules was spot on and the issue appears to be resolved at least with the primary contact with whom I need to collaborate.

I guess the Connectivity Test is kind of a non issue since:

A. It works to the sip.domain address on 443.

B. I now have complete federation capability with at least one of my clients.

I will continue to test and see if this improves our success rate with other clients federated or otherwise. 

Thanks again for your assistance.  If I find anything else I will post in this thread. 

Michael