Lately, I’ve been receiving feedback about my posts that the solution to the issues are not always correct. It’s partly my fault for not including an additional note that the problems I write about along with their solutions are only one of the many scenarios that may exists and if they don’t necessarily work for all situations. I would like to thank the people who have provided me with this feedback and I’ll make sure I make this note in my future posts.
As with many errors or warnings that you may experience with Microsoft Office Communications Server 2007 R2, note that following solution is one of the many that may cause such an error so it may or may not apply to other situations were this error is thrown.
Problem
You’ve deployed a new OCS 2007 R2 Edge server and have begun testing with Microsoft Office Communications Server Remote Connectivity Test tool at https://www.testocsconnectivity.com. Since the public DNS SRV records have not been created yet, you have opted to use the tool without the AutoDiscover option but once you’ve completed entering all the information, you get the following result:
| ||||||||||||||||||||||||||||||||||||||||||||||||
Test Details | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Analyzing the Problem
The first place I checked because the server I was working with Windows Server 2008 R2 was the local security settings:
Since this was set properly, I proceeded to move on to doing SIPStack traces on the Edge server to see if I was able to capture additional information to help with the troubleshooting:
While the SIPStack trace only provided 2 entries, it turned out to be more than enough to indicate what was causing the error:
TL_INFO(TF_CONNECTION) [0]0688.0960::12/02/2010-23:17:57.673.0000000d (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(161))$$begin_record
LogType: connection
Severity: information
Text: TLS negotiation started
Local-IP: 192.168.80.133:5061
Peer-IP: 66.247.89.72:13949
Connection-ID: 0x4100
Transport: TLS
Note: Sorry but I lost the screenshot for the snooper trace and only have the text
TL_ERROR(TF_CONNECTION) [0]0688.041C::12/02/2010-23:17:57.705.00000010 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(157))$$begin_record
LogType: connection
Severity: error
Text: The connection from a remote user client is refused because remote user access is not enabled on this port
Peer-IP: 66.257.89.51:13949
Transport: TLS
Result-Code: 0xc3e93d86 SIPPROXY_E_CONNECTION_REMOTE_CLIENT_NOT_THIS_PORT
Data: listening-port="5061"
$$end_record
-------------------------------------------------------------------------------------------------------------------------------------------------------
Solution
What immediately (and finally) caught my eye was that port 5061 was being used and our public SRV record is supposed to direct traffic to port 443 when users are connecting to the Edge with their MOC clients.
All that was required to be changed to receive an error free test was the OCS Access Edge Server Port which in this case should be 443 and not 5061.
2 comments:
This also fixed our problem. Now that we can test we will be continuing! Thank you
How do you change that on Lync? I'm receiving the same error.
Post a Comment