Oct 08 2022 09:29 AM
Oct 08 2022 09:29 AM
I successfully configured Skype for Business hybrid between my on-premises Skype for Business environment and Skype for Business Online/Microsoft Teams and I migrated my first user into Teams with "Move-CsUser" command. However we have sereval issues when a purely on-premise user wants to cooperate with a migrated Teams Only user:
Calling from on-premise to Teams is working fine but when a Teams user calls a Skype for Business user, the connection will be unstable. The audio call builds up without any problem, the problems are starting when some "action" is starting (for example when a party turns on his/her camera, the call will be disconnected within 30 seconds).
Presence is on-way only so Teams users see the presence of SfB users but SfB users see Teams users as Offline.
I captured a SIP error when a call was disconnected, let me show you:
TL_INFO(TF_PROTOCOL) 1808.1034::10/08/2022-14:24:58.702.00000286 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(264))[1aabcb79-c13b-5ab0-861a-bfff80e0d52c] $$begin_record Instance-Id: 337 Direction: incoming;source="external edge";destination="internal edge" Peer: sipfed.online.lync.com:5061;ip-address=22.214.171.124 Message-Type: response Start-Line: SIP/2.0 504 Server time-out From: "" <sip:email address removed for privacy reasons>;epid=8a491aa5aa;tag=1a882c7292 To: "on_prem_user"<sip:email address removed for privacy reasons>;epid=8A684AB9BC;tag=2650fd94b Call-ID: 413c925c-4b95-42c7-8e4a-3d191b3f6e92 CSeq: 1 BYE Via: SIP/2.0/TLS 10.11.19.10:49950;branch=z9hG4bKCD1C9668.444BB43E0A1595DA;branched=FALSE;ms-internal-info="caH1kdKhQQbHPP4FE5G3t11vljWVJOIhFm0rSK52Yx8CU-tEtEI7jUKQAA";received=XXX.XXX.XXX.XXX;ms-received-port=49950;ms-received-cid=5DCA1300 Via: SIP/2.0/TLS 10.11.11.40:61791;branch=z9hG4bK7D980A6C.576D89AA0A1B75DA;branched=FALSE;ms-received-port=61791;ms-received-cid=600 Via: SIP/2.0/TLS 10.11.11.41:49940;branch=z9hG4bK65240C76.EB7556FD0A1595DA;branched=FALSE;ms-received-port=49940;ms-received-cid=11DC00 Via: SIP/2.0/TLS 192.168.125.139:49803;received=XXX.XXX.XXX.XXX;ms-received-port=58708;ms-received-cid=900 Content-Length: 0 ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";expected-fqdn="sfbedge.mydomain.com";certName="a-lgw-uswe-02.lgw.skype.com";cause="Possible server configuration issue";info="The peer certificate does not contain a matching FQDN";source="sipfed.online.lync.com";source-server="RD38563D7FA25E" ms-split-domain-info: ms-traffic-type=SplitIntra ms-telemetry-id: 1AABCB79-C13B-5AB0-861A-BFFF80E0D52C Server: RTC/7.0
How could I resolve the issue? I checked as many thing as I can: firewall (all neccessary ports are open inbound and ourbound), certificates, etc.
Thank you in advance,
Oct 09 2022 03:07 AM
@mbalint987 hello, we are having the exact same issue as you described, I can’t work out what’s causing it, please tell me you managed to fix and and if you did could you tell me how?
Oct 09 2022 03:26 AM
@Alias17273Unfortunately I had to give up. :\ I didn't find any useful information about this issue and because this is only a lab environment, I don't have to resolve this issue. It would be fine but it seems I cannot resolve this on my own.
Oct 09 2022 03:31 AM
@mbalint987 ah fair enough, lucky for you :) we have this in a production environment :(
I'm going to raise a ticket with MS and if I fix it I’ll make sure I’ll reply here to let you know the fix
Oct 15 2022 12:13 PM
Nov 01 2022 11:13 AM - edited Nov 01 2022 11:15 AM
Have you found a solution yet? we have the same Problem in production since today. same error in the ocslog.
another symptom is we can call from onprem to teams by sip without issues - but if we do it by the number the reverselookup fails.
Nov 01 2022 11:37 AM
ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";expected-fqdn="sfbedge.mydomain.com";certName="a-lgw-uswe-02.lgw.skype.com";cause="Possible server configuration issue";info="The peer certificate does not contain a matching FQDN";source="sipfed.online.lync.com";source-server="RD38563D7FA25E"
This indicates an issue with your certificates and the 30 seconds dropped calls usually indicates an issue with A/V certificate. So check your A/V certificate, remember a new certificate should be assigned using -roll as the already issued tokens are valid for up to 8 hours.
Also check if your firewall does any deep inspection on the A/V connections, this could also be an issue with the same symptoms.
Nov 01 2022 12:14 PM
There were no such changes on our site. What also makes me curious:
ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";expected-fqdn="external.edgefqdn.com";certName="c-lgw-euno-02.lgw.skype.com";cause="Possible server configuration issue";info="The peer certificate does not contain a matching FQDN";source="sipfed.online.lync.com";source-server="RD38563D80164B"
expected-fqdn=is our external edge name but certName="c-lgw-euno-02.lgw.skype.com" is something on the MS side.
there we no changes on our site - except for 10/22 Windows Updates and the October SfB19 Update. The Updates were done on Wednesday last week - but the issue appeared today.
Nov 01 2022 01:58 PM
Nov 01 2022 02:48 PM
Nov 01 2022 02:56 PM
@Kenneth Meyer-Lassen In the meantime, I tried to continue the troubleshooting, and I found out the following:
It seems that the Skype for Business client disconnects the call because we don't get any answer for our OK mesage.
Let me show you these screenshots:
Do you have any ideas about why don't we get ACK for the 200 OK? I checked the network with no luck and I don't have any more ideas.
Nov 01 2022 03:18 PM
i can confirm the missing ACK:
whats your CU on SFB19? Could
Be the cause of the issue?
Nov 01 2022 03:52 PM
@EduNic1800 Let me paste the output of the relevant cmdlets:
Before I ran into this issue we used an around 1.5 years old version of SfB 2019 but after that I installed the lastest updates on the Standard Edition and Edge.
Nov 01 2022 11:57 PM
Nov 02 2022 03:39 AM
Nov 02 2022 03:50 AM - edited Nov 02 2022 03:53 AM
Ye maybe the media path changed without documentation?!
I have already tried with "ANY-Port/Protocol" for incoming and outgoing for the EDGE-Part - same issue.
Also i dont think its media (only) because we cannot see the peresence of the Teams users from onprem. But its working if i query an onprem user from Teams.
Nov 02 2022 04:02 AM
Nov 02 2022 04:22 AM
Nov 02 2022 04:32 AM - edited Nov 02 2022 04:33 AM
As far as I can see we're in Europe/EU but I don't see any option to get the exact region. I'm afraid that this is an issue on Teams side.
Nov 02 2022 04:39 AM