Forum Discussion
MeAndMyBIGIP_60
Nimbostratus
NimbostratusOCS 2007 Federation traffic only goes 1-way thru LTM 6400 9.4.5 HF2
So I have 2 federated OCS orgs, one running OCS 2007, one running Lync. The users in the Lync org can see presence for OCS users, and can initiate IM conversations with the OCS folks. However, the OCS users cannot see presence of Lync users, and can not initiate a conversation with a Lync user, even if they provide the SIP address.
In this
situation A1 - lync with numerous federation (sip and xmpp) and B1 OCS 2007 (no
federations, yet)
·
From
A1 I can initiate a messaging session and B1 is able to respond.
·
A1
can see the status of B1
·
During
the IM session, B1 sees the status of A1 as "unknown"
·
B1
is neither able to see status of A1 or is able to initiate an IM session.
I originally followed the
guide “Deploying the BIG-IP LTM v9.x with Microsoft Office Communications
Server 2007”, but I’ve been reading that I might need 5065 and 5069 as
well. Is there any information available regarding this type of design,
with the directors behind the F5 as well? Or if anyone has done
this or is able to pass along some insight, any help would be appreciated.
Virtual Servers:
AV-edge-int-stun-vs
Common IP
ADDRESS
3478
Standard Edit...
Forwarding-VS
Common IP ADDRESS
0 (Any)
Forwarding (IP) Edit...
Web-edge-ext-ssl-vs
Common IP
ADDRESS
443 (HTTPS) Standard
Edit...
acc-edge-ext-ssl-vs
Common
IP ADDRESS
443 (HTTPS) Standard
Edit...
acc-edge-int-sip-vs
Common IP ADDRESS
5061
Standard Edit...
av-edge-ext-ssl-vs
Common IP ADDRESS
443 (HTTPS) Standard
Edit...
av-edge-int-sip-vs
Common IP ADDRESS
5062
Standard Edit...
av-edge-int-ssl-vs
Common IP ADDRESS
443 (HTTPS) Standard
Edit...
dir-sip-tls-vs
Common IP ADDRESS
5061
Standard Edit...
dir_sip_mtls_vs
Common IP ADDRESS
5060
Standard Edit...
fe-444-vs
Common IP ADDRESS
444
Standard Edit...
fe-http-vs
Common IP ADDRESS
80 (HTTP)
Standard Edit...
fe-rpc-vs
Common IP ADDRESS
135
Standard Edit...
fe-sip-tls-vs
Common IP ADDRESS
5061
Standard Edit...
fe-ssl-vs
Common IP ADDRESS
443 (HTTPS) Standard
Edit...
ocs-edge-sip-vs
Common IP ADDRESS
5061
Standard Edit...
Pools:
AV-edge-int-stun-pool
Common
Acc-edge-ext-ssl-pool
Common
Acc-edge-int-sip-pool
Common
Av-edge-ext-ssl-pool
Common
Av-edge-int-sip-pool
Common
Av-edge-int-ssl-pool
Common
Dir-sip-tls-pool
Common
Fe-444-pool
Common
Fe-http-pool
Common
Fe-rpc-pool
Common
Fe-sip-tls-pool
Common
Fe-ssl-pool
Common
Web-edge-ext-ssl-pool
Common
dir_sip_mtls
Common
fe_5060_pool
Common
ocs-edge-sip
Common
So if the OCS user initiates the conversation by providing the SIP address of a Lync user, the OCS side gets a 483 error in the conversation window, and OCS logging shows the following:
TL_ERROR(TF_CONNECTION)
[7]1D28.1AC8::05/05/2011-18:25:19.000.00adb10e
(SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record
LogType
: connection
Severity
: error
Text
: Receive operation on the connection failed
Local-IP
: :1158
Peer-IP
: :5061
Peer-FQDN
: sip.lyncorg.com
Peer-Name
: ocsedge.lyncorg.com
Connection-ID
: 0x272D402
Transport
: M-TLS
Result-Code
: 0x80072746 WSAECONNRESET
$$end_record
And...
TL_ERROR(TF_CONNECTION) [7]1108.10F8::05/05/2011-18:21:11.890.00f9ed54 (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record
LogType
: connection
Severity
: error
Text
: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?
Local-IP
: :5061
Peer-IP
: :50965
Connection-ID
: 0x275F400
Transport
: TLS
$$end_record
Anyone?
-Me
MeAndMyBIGIP_60Still having this problem... anyone??
David_Isaacks_2Did you ever find a solution to this issue? I am having the same issue between Lync and OCS users. When I use DNS Load Balancing both environments can see each other. When I move it to F5, only the Lync users can see the OCS users.
Steve_Hj_84479The issue that was in the starting post was a little known bug in OCS 2007. There is an issue with how the certificate needs to be created, the request needs to be created with the OCS certificate creation tool and the request needs to be either sent directly to the CA or input directly. There can't be a "middle-man" with the request. It has been fixed in all newer verisons of OCS and Lync.