It sounds like your OCS Edge Server configuration may be missing something as the two clients when behind NAT should be getting candidates from the Edge and connect across it's relay ports.
You say the NAT check box is checked on the AV Edge Configuration. The external AV Edge FQDN that is listed on that same page can you open a CMD prompt on the Edge and ping or resolve the AV FQDN to the external public IP? If not, then add a host file entry on the Edge that includes the IP and External AV FQDN.
Next does the certificate on that same interface has a subject alternate name (SAN) field with entries. If so is the Subject name (AV FQDN) listed last in the SAN. FYI best not of have SAN entries on the AV and internal interface certificates.
Check that on the internal tab on the edge properties that the Internal servers authorized to connect to the edge include all the internal OCS Front End servers and the OCS Pool FQDN.
Check that you can telnet to each of the FQDNs for the external edge roles on their respective ports based on your configuration from the internet.
On your OCS Front End go to forest global properties and check that on the Edge Server tab you have then internal fqdn of the access edge server specified for the Access edge and same for AV Edge with port of 5062.
Verifiy you can telnet from Front End to Edge on 5062, 443, and 5061.
From Edge verify you can telnet Pool FQDN and Front End FQDNs on 5061.
On the Front End Pool Properties verify that the AV Edge Server port 5062 is selected in the dropdown for AV Edge Server.
Maybe something above will help you uncover the configuration issue.





by: tbennett35Posted on 2009-10-16 at 03:26:50ID: 25588167
Just to expand on this a little more, I have just done a wireshark capture with a colleague who is in the office while I am at home. Wireshark shows that communicator is trying to setup comms between my private internal IP to his private internal IP, which will never work.
Is here any way around this?