Recently, I came across an issue that was affecting Lync 2013 SBA homed users after the re-IP addressing of a Lync 2013 Enterprise Edition pool. After all IP addresses were updated, and pool homed users were fully functional once again, it was discovered that any users homed to an SBA were unable to answer Response Group calls. If this user was re-homed to the Front End pool, they were able to answer Response Group calls without issue. I knew the issue wasn’t related to media connectivity, as the media path was the same regardless of where the user was homed.
Client logs showed the following error:
05/04/2016|11:30:43.586 600:170 INFO :: SIP/2.0 403 Forbidden Authentication-Info: TLS-DSK qop="auth", opaque="3ABEF158", srand="31091ABF", snum="38", rspauth="790b91f7a5abbea876977ce72e86026df6ce58e3", targetname="CCSKYPE-SBA1.domain.com.au", realm="SIP Communications Service", version=4 From: <sip:email@example.com>;tag=5754c5e173;epid=88298561e1 To: <sip:ccskype-sba1.domain.com.au;gruu;opaque=srvr:MediationServer:e-3LXCPwP1ygJ_ZYnQPLDgAA;grid=867b2eb0972c470abf649f860fea0228>;tag=483B98359D534CAE3AF3C594C5A2E9FC Call-ID: fbe370b250e94f2291980707b607399c CSeq: 1 INVITE Via: SIP/2.0/TLS 10.240.67.13:54942;ms-received-port=54942;ms-received-cid=791C00 ms-diagnostics: 1020;reason="Identity of the referrer could not be verified with the ms-identity parameter";ErrorType="Failed to establish a connection to the signing server";Referrer="firstname.lastname@example.org";HRESULT="0xC3E93D66(SIPPROXY_E_CONNECTION_NOT_FOUND)";cause="Failed to establish a connection to the signing server";signer="DPSKYPE-FE2.domain.com.au";source="CCSKYPE-SBA1.domain.com.au" Server: RTC/5.0 Content-Length: 0
This somewhat stumped me. Having a quick look around the internet, I found a similar issue Csaba Vegso’s had run into when working on the development of UCMA workflows (a great read by the way). Whilst the error was the same, I wasn’t working with custom UCMA workflows, and it only affected users homed to the SBA. The only other variable that was different post IP re-addressing was that there was now a firewall between the SBA and the Front End Pool…
I reviewed the Lync 2013 Protocol Workloads poster, and confirmed with the firewall team that all ports shown were open:
Keeping in mind that, in the past, the Protocol Workloads poster hasn’t been infallible (A fellow MCM Randy Wintle ran into this issue quite some time ago when deploying an SBA), I requested the firewall team capture traces while I reproduce the issue. Lo and behold:
In the above capture, 10.211.208.250 is the SBA, and 10.2.5.12 is one of the Front End servers. for every failed call, there was a corresponding Deny of TCP 5071 from SBA to FE. This port is outlined on the Protocol Workloads poster, and in firewall port documentation, but not outlined as required to be open Between SBA and FE:
Opening port TCP 5071 from SBA to Lync pool resolved the issue.