by 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:damien.margaritis@domain.com.au>;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="teamuc@domain.com.au";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.
Damien Margaritis
dmunified 
Don’t forget about Port 5088 either – http://flinchbot.com/2014/07/01/port-5088-missing-from-lync-2013-documentation/
Thanks for the heads up, I’ll get the client to test this scenario
Did you send a mail to the authors of the lync/sfb poster? Its a shame these missing ports can remain for years in the documents, makes people believe there is no Q&A for these documents.
Not sure who to email anymore… I tweeted @DrRez, see what the process is these days to request updates
Quote from the bottom right corner of the poster:
“To send feedback about this documentation, please write to us at SfBdoc2015@microsoft.com.”
Thanks Soder, eMail sent. I was looking at the 2013 poster, email address is missing from that one.