SfB Anonymous Join langsam

Manchmal lernt man erst durch ein Problem beim Kunden, wie Skype for Business sich manchmal schwer tut und es im Hintergrund funktioniert. Diese Seite beschreibt den Vorgang des Beitritts zu einem Meeting, wenn es keine aktive Federation gibt. In dem Fall hat der Beitritt fast 3 Minuten gedauert.

Ich hoffe, dass das hier beschriebe ineffektive Verhalten mit einem neueren Client optimiert wird und diese Seite damit obsolet wird.

Umgebung

Es handelte sich wie schon geschrieben um eine Problemstellung bei einem Kunden. Ich habe aber auf dieser Seite natürlich "fast" alle Referenzen auf den Konferenzleiter als "Host" als auch den Teilnehmer unkenntlich gemacht. Die meisten Daten und IP-Adressen sind also nicht real.

Allerdings habe ich nicht verändert, dass SAP.COM diese Konferenz für einen Kunden einberufen hat. Es ist kein Geheimnis, dass SAP auch Skype for Business nutzt und deren Edge-Setup hat einen großen Einfluss auf die Performance. Ich vermute, dass viele Teilnehmer von Meeting bei SAP auf das Problem stoßen könnten und so vielleicht diese Seite besser gefunden wird.
Nur zur Sicherheit: Das Problem ist nicht bei Skype for Business Setup seitens SAP zu suchen sondern aus meiner Sicht beim Teilnehmer bzw. Skype for Business Client.

Damit sie die späteren Analyse der UCCAP.LOG-Datei verstehen, sollten Sie folgende Umgebungsparameter kennen:

  • Konferenzhoster ist Skype for Business On-Prem von SAP.COM mit mehreren Edge Server
    Wie Sie später sehen werden, hat die Veröffentlichung von 4 Edge-Servern bei der Konstellation einen großen Einfluss.
  • Teilnehmer nutzt Skype for Business
    Der eingeladene Mitarbeiter hat selbst den Skype for Business Client für die Teilnahme am Meeting
  • Keine Federation
    Die Firma des Teilnehmers erlaubt Federation nur mit ausgewählten Firmen. Die Firma des Konferenzleiters ist nicht erlaubt.
  • Die Firewall des Teilnehmers verwirft Pakete (DROP)
    Wenn als eine Verbindung von Intern nach Extern nicht erlaubt ist, dann wird kein TCP-RESET gesendet sondern der Client bekommt einfach keine Antwort

In den folgenden Abschnitten erkläre ich, warum in diesem Fall der Beitritt in ein Meeting fast geschlagene 3 Minuten dauert.

Ich hoffe, dass Microsoft das ineffektive Verhalten des Client irgendwann einmal "optimiert". Wobei auch ein Firmen-Administrator durch eine geschickte Konfiguration auch dazu beitragen kann, dass die Probleme gar nicht offensichtlich werden.

Schaue wir uns die Abschnitte im UCCAPILOG des Clients an. Beachten Sie dabei auch die Zeitstempel am Anfang. Die Einladung zum Meeting selbst ist natürlich lange vorher per Mail erfolgt.

Nachstellen mit Office 365

Wenn Sie diese Verhalten nachstellen wollen, können Sie auch gerne einen Office 365 Tenant dazu missbrauchen. Sie müssen dort nur einstellen, dass die Federation nur mit "allowed Domains" erlaubt ist und die Gegenstelle nicht aufnehmen oder auf Blocked Domains stellen und die Gegenstelle blocken.

Sie können dan mit dem Office 365 User als Telinehmer gegen eine andere Organisation das Verhalten relativ einfach durchspielen.

Stellen Sie hier bitte nicht auf "Off completely", da dann nicht nur externer Zugriff ihrer Anwender sonder auch anonymer Meeting-Teilnehmer unterbunden ist.

Die weiteren Analysen haben aber nichts mit Office 365 zu tun.

Einladung und Start

Der Teilnehmer startet das Meeting, in dem er auf den "Meeting-Link" in der Einladung klickt, worauf sich ein Browser öffnet, der dann den Skype for Business Client für das Meeting startet. Aber hier startet dann auch das UCCAPUOG.

Wir sehen den ausgehenden INVITE zum lokalen Skype for Business Server, der diese Paket über den Edge zur Topologie des Konferenzleiters senden will:

07/20/2017|15:26:35.124 3100:2658 INFO :: Sending Packet - 192.168.1.213:5061 (From Local Address: 192.168.1.10:61758) 2066 bytes:
07/20/2017|15:26:35.124 3100:2658 INFO :: INVITE sip:konferenzleiter@sap.com;gruu;opaque=app:conf:focus:id:MEETINGID SIP/2.0 User-Agent: UCCAPI/16.0.7766.5352 OC/16.0.7766.2092 (Skype for Business)

Der Teilnehmer verwendet also auch einen halbwegs aktuellen Client. Es dauert aber nicht lange, bis auch die Antwort der lokalen Umgebung kommt.

07/20/2017|15:26:35.442 3100:2658 INFO :: Data Received -192.168.1.213:5061 (To Local Address: 192.168.1.10:61758) 964 bytes:
07/20/2017|15:26:35.442 3100:2658 INFO :: SIP/2.0 504 Server time-out
ms-diagnostics: 1017;
   reason="Cannot route From and To domains in this combination";
   summary="Cannot route between the source and destination domains because partner discovery is not enabled";
   external-domain="sap.com";
   external-type="domain-type-remote";
   internal-domain="uclabor.de";
   internal-type="domain-type-local";source="sip.uclabor.de"
This is expected and a fast response

Diese Antwort ist so auch erwartet, da es ja keine Federation zu SAP.COM gibt. Es gibt auch andere Fehler, die auf der folgenden Seite beschrieben sind

SfB Client und DNS

Die Folge ist, dass der Client seit einiger Zeit nun weiß, dass er nicht über den eigenen lokalen Weg gehen kann und nun ohne die lokalen Services eine Verbindung versucht. Auch das ist im UCCAPILOG zu sehen. Der Client versucht per DNS die Edge-Server des Konferenzanbieters zu finden:

07/20/2017|15:26:36.229 3100:31AC ERROR :: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.sap.com failed 8007232b 
07/20/2017|15:26:36.291 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.211:443 
07/20/2017|15:26:36.291 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.214:443 
07/20/2017|15:26:36.291 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.217:443 
07/20/2017|15:26:36.291 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.220:443

Die erste Anfrage geht interessanterweise auf "_sipinternaltls" aber am Ende findet er auch auch die SIP-Server. Hier können Sie sehen, das SAP ein DNS Round Robin auf vier IP-Adressen nutzt. Ob die Adressen 1:1 auf Edge Server zugeordnet sind oder per Loadbalancer weiter verteilt werden, ist nicht ersichtlich.

SfB Client und TCP-Connections

Auch wenn ein HTTP-Proxy auf dem Client konfiguriert ist, versucht er dennoch erst einmal direkt per Port 443 diese öffentliche IP-Adressen zu erreichen. Schließlich konnte er diese per DNS ja auflösen und da liegt der Verdacht nahe, dass diese Gegenstellen vielleicht ohne HTTP-Proxy zu erreichen sind. Entsprechend sehen die vier Verbindungsversuche aus:

07/20/2017|15:26:36.315 3100:2658 INFO  :: CAsyncSocketWin32::Connect 1EE2E2D0 connecting(async) window 006B0D04 socket:2bc8 DestAddr:155.56.38.211:443
07/20/2017|15:26:57.311 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.211:443
07/20/2017|15:26:57.356 3100:2658 INFO  :: CAsyncSocketWin32::Connect 1EE34300 connecting(async) window 00750CF8 socket:28b8 DestAddr:155.56.38.214:443
07/20/2017|15:27:18.353 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.214:443
07/20/2017|15:27:18.394 3100:2658 INFO  :: CAsyncSocketWin32::Connect 1EE2B390 connecting(async) window 006C0D04 socket:2b24 DestAddr:155.56.38.217:443
07/20/2017|15:27:39.394 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.217:443
07/20/2017|15:27:39.441 3100:2658 INFO  :: CAsyncSocketWin32::Connect 1EE387A0 connecting(async) window 005F0734 socket:eb4 DestAddr:155.56.38.220:443
07/20/2017|15:28:00.438 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.220:443

Die direkte Verbindung funktioniert aufgrund von Firewall-Einstellungen bei den meisten Firmen  natürlich nicht. Sonst wäre der Zugang per HTTPS ja komplett anonym zu allen Zielen möglich. Interessant ist hier aber, dass diese Version des Skype for Business Client die vier Adressen sequentiell durcharbeitet und es pro IP-Adresse ca. 20 Sekunden dauert, bis der Client die nächste Adresse versucht. Es würde sicher helfen, wenn die Firewall ein "REJECT" senden würde und das Paket des Client nicht einfach mit einem DROP unterdrückt.

Ich bin aber schon etwas irritiert, dass der Skype for Business Client die Adressen sequentiell abläuft und sich 20 Sekunden Zeit lässt. Ein paralleler Verbindungsaufbau über Threads wäre sicher möglich und vor allem müsste der Client kaum mehr als wenige Sekunden warten.

Hier kann Microsoft sicher mit wenig Aufwand eine "zügigere" Meeting-Teilnahme erreichen.

SfB Clients Fallback zum HTTP-Proxy

Dann versucht der Client aber doch eine Verbindung über den HTTP-Proxy. Aber auch hier gibt es eine Überraschung:

07/20/2017|15:28:00.439 3100:2658 ERROR :: SIP_MSG_PROCESSOR::OnConnectComplete connect failed 80ee0067 retry connecting via HTTP tunnel
07/20/2017|15:28:00.678 3100:2658 INFO  :: CSIPHTTPProxyTunnel::OnHttpProxyAuthComplete sending to HTTP Proxy
CONNECT ucemeasip01.sap.com:443 HTTP/1.1 Host: ucemeasip01.sap.com Proxy-Connection: Keep-Alive

Die Anfrage an den Proxy ist noch in Ordnung aber was ein guter Proxy ist, der erlaubt erst mal keinen "Anonymen Zugriff". Insofern ist es natürlich klar, dass zuerst einmal zwar ein "CONNECT" zustande kommt aber dann eine Authentifizierung erforderlich ist. In diesem Fall ist aber ein "Cloud Proxy"  (Blackspider) im Einsatz, der einen 200 OK liefert.

07/20/2017|15:28:00.717 3100:2658 INFO :: CSIPHTTPProxyTunnel::StartHttpProxyAuthWorkitem recv from HTTP Proxy
HTTP/1.0 200 Connection established
X-Bst-Request-Id: 2D794h:dcl:27939
X-Bst-Info: t=1502278080,h=02b,p=37159_11003:2_11819,u=270995298,c=2339,v=7.9.58904.78
X-WS-PAC: http://webdefence.global.blackspider.com:8082/proxy.pac?p=xxxxx

Allerdings scheint auch dieses Paket den Skype for Business Client zu verwirren. So ganz geht das aus den Logs nicht hervor aber anscheinend fehlt was.

07/20/2017|15:28:00.845 3100:2658 TRACE :: SIP_MSG_PROCESSOR::ResolveSipUrlAndSetRequestDestination no open connection for pszDest ucemeasip01.sap.com:443
07/20/2017|15:28:00.845 3100:2658 INFO  :: Function: StringToSockAddress
07/20/2017|15:28:00.845 3100:2658 ERROR :: HRESULT failed: 80072726 = HRESULT_FROM_WIN32(::ShimWSAGetLastError()) . Failed to convert string IP to SOCKADDR

Ich bin davon ausgegangen, dass er nun eine Authentifizierung gegen den Proxy startet.

SfB Client Retry einer direkten Verbindung

Aber stattdessen  versucht der Client wieder eine direkte Verbindung. Sie ist "etwas" anders, da die Logeinträge etwas anders aussehen. Zuerst startet er wieder eine Namensauflösung. Vielleicht hofft er, dass ca. 1,5 Minuten später andere Werte zu erfahren sind?

07/20/2017|15:28:01.105 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete[1F0FD9F0] Entered host ucemeasip01.sap.com
07/20/2017|15:28:01.105 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.211:443 
07/20/2017|15:28:01.105 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.214:443 
07/20/2017|15:28:01.105 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.217:443
07/20/2017|15:28:01.105 3100:2658 TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: ucemeasip01.sap.com IP: 155.56.38.220:443

Und dann versucht er wieder nacheinander eine direkte Verbindung zu den vier Adressen. Diesmal bricht er aber schon nach 20 statt 30 Sekunden ab

07/20/2017|15:28:01.111 3100:2658 INFO :: SockMgr: Create New Connection:DestName:(ucemeasip01.sap.com)DestPort:(443)Transport:(2)httpTunnel:(0)TLS RemotePrincipalName:(ucemeasip01.sap.com)
07/20/2017|15:28:01.111 3100:2658 TRACE :: DestAddr :155.56.38.211:443
07/20/2017|15:28:22.131 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.211:443

07/20/2017|15:28:22.131 3100:2658 INFO :: SockMgr: Create New Connection:DestName:(ucemeasip01.sap.com)DestPort:(443)Transport:(2)httpTunnel:(0)TLS RemotePrincipalName:(ucemeasip01.sap.com)
07/20/2017|15:28:22.131 3100:2658 TRACE :: DestAddr :155.56.38.214:443
07/20/2017|15:28:43.168 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.214:443

07/20/2017|15:28:43.169 3100:2658 INFO :: SockMgr: Create New Connection:DestName:(ucemeasip01.sap.com)DestPort:(443)Transport:(2)httpTunnel:(0)TLS RemotePrincipalName:(ucemeasip01.sap.com)
07/20/2017|15:28:43.169 3100:2658 TRACE :: DestAddr :155.56.38.217:443
07/20/2017|15:28:43.216 3100:2658 INFO :: CAsyncSocketWin32::Connect 1EE34990 connecting(async) window 001F1036 socket:28ac DestAddr:155.56.38.217:443
07/20/2017|15:29:04.219 3100:2658 ERROR :: CSIPAsyncSocket::OnConnectReady - Error: 10060 dest: 155.56.38.217:443

07/20/2017|15:29:04.219 3100:2658 INFO :: SockMgr: Create New Connection:DestName:(ucemeasip01.sap.com)DestPort:(443)Transport:(2)httpTunnel:(0)TLS RemotePrincipalName:(ucemeasip01.sap.com)
07/20/2017|15:29:04.219 3100:2658 TRACE :: DestAddr :155.56.38.220:443
07/20/2017|15:29:04.263 3100:2658 INFO :: CAsyncSocketWin32::Connect 1EE30670 connecting(async) window 00330A14 socket:2b00 DestAddr:155.56.38.220:443

Der Client verliert hier also noch einmal 4x20Sek, also schon wieder fast 1,5 Minuten

Erfolgreiche Verbindung über HTTP Proxy

Erst dann besinnt sich der Client wieder dem Weg über den Proxy. Der erste "CONNECT" und die Antwort kenne wir schon

07/20/2017|15:29:25.264 3100:2658 ERROR :: SIP_MSG_PROCESSOR::OnConnectComplete connect failed 80ee0067 retry connecting via HTTP tunnel
07/20/2017|15:29:25.451 3100:10F4 TRACE :: HTTPRPOXYCB:Proxy Address is 85.115.56.180:8081

07/20/2017|15:29:25.451 3100:2658 INFO :: SockMgr: Create New Connection:DestName:(ucemeasip01.sap.com)DestPort:(443)Transport:(2)httpTunnel:(1)TLS RemotePrincipalName:(ucemeasip01.sap.com)
07/20/2017|15:29:25.451 3100:2658 TRACE :: DestAddr :155.56.38.220:443
07/20/2017|15:29:25.451 3100:2658 TRACE :: ProxyAddr:85.115.56.180:8081
07/20/2017|15:29:25.484 3100:2658 INFO :: CAsyncSocketWin32::Connect 1EE30670 connecting(async) window 00340A14 socket:2a60 DestAddr:85.115.56.180:8081
07/20/2017|15:29:25.493 3100:2658 INFO :: CSIPHTTPProxyTunnel::OnHttpProxyAuthComplete sending to HTTP Proxy
CONNECT ucemeasip01.sap.com:443 HTTP/1.1
Host: ucemeasip01.sap.com
Proxy-Connection: Keep-Alive

07/20/2017|15:29:25.525 3100:2658 INFO :: CSIPHTTPProxyTunnel::StartHttpProxyAuthWorkitem recv from HTTP Proxy
HTTP/1.0 200 Connection established
X-Bst-Request-Id: 2p894h:GWq:7097
X-Bst-Info: t=1502278165,h=07b,p=37159_11003:2_11819,u=270995298,c=2339,v=7.9.58904.78
X-WS-PAC: http://webdefence.global.blackspider.com:8082/proxy.pac?p=xxxxxx

Diesmal springt der Client aber nicht mehr auf eine direkte Verbindung zurück, sondern sendet auch den INVITE durch den Proxy samt Authentifierung

07/20/2017|15:29:25.597 3100:2658 INFO :: Sending Packet - 85.115.56.180:8081 (From Local Address: 192.168.1.10:61894) 2046 bytes:
07/20/2017|15:29:25.597 3100:2658 INFO :: INVITE sip:konferenzleiter@sap.de;gruu;opaque=app:conf:focus:id:MEETINGID SIP/2.0
07/20/2017|15:29:25.694 3100:2658 INFO :: SIP/2.0 401 Unauthorized
07/20/2017|15:29:25.711 3100:2658 INFO :: INVITE sip:konferenzleiter@sap.de;gruu;opaque=app:conf:focus:id:MEETINGID SIP/2.0
Authorization:
   Digest Username="guid",
   realm="konferenzleiter@sap.de",
   qop=auth,
   algorithm=sha256-sess,
   uri="sip:konferenzleiter@sap.de;gruu;opaque=app:conf:focus:id:MEETINGID SIP",
   nonce="xxxxxxxxxxxxxxxxxxxx",
   nc=1,
   cnonce="",
   opaque="xxxxxx",
   response="xxxxxxxxxxx"

Und in der Folge kommen dann auch die Antworten durch den HTTP-Tunnel zurück

07/20/2017|15:29:25.771 3100:2658 INFO :: SIP/2.0 100 Trying 07/20/2017|15:29:25.781 3100:2658 INFO :: SIP/2.0 101 Progress Report
07/20/2017|15:29:25.994 3100:2658 INFO :: SIP/2.0 183 Session Progress
07/20/2017|15:29:25.995 3100:2658 INFO :: SIP/2.0 200 Invite dialog created
07/20/2017|15:29:26.002 3100:2658 INFO :: SUBSCRIBE sip:konferenzleiter@sap.de;gruu;opaque=app:conf:focus:id:MEETINGID SIP/2.0
07/20/2017|15:29:26.243 3100:2658 INFO :: SIP/2.0 200 OK

Am Ende steht der Anwender dann in der Lobby. Eine Audio/Video-Verbindung wurde hier noch nicht aufgebaut. Aber weitere Pakete, die ich hier nicht wiedergebe, zeigen die Details zum Meeting. (Rooster) etc.

RTP-Kandidaten

Die Ursache der langen Verzögerung war damit also gefunden. Mich hat aber noch interessiert, welchen TURN/STUN-Service so ein Teilnehmer nutzt. Er hat ja die Wahl den eigenen Edge-Server zu nutzen oder vielleicht nutzt er ja den Edge-Server des Konferenz-Anbieters. Das muss ja zumindest für die WebApp-Teilnehmer möglich sein. Also habe ich mal weiter geschaut, bis ein "m=audio" im UCCAPI-Trace zu sehen ist. Hier der Auszug aus dem Trace:

m=audio 56568 RTP/AVP 117 104 114 9 112 111 0 103 8 116 115 97 13 118 101
a=x-ssrc-range:3577358849-3577358849
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp-rsize
a=label:main-audio
a=x-source:main-audio

## hier kommen dann erst einmal die "direkten IP-Adressen eines Clients
a=candidate:1 1 UDP 2130706431 192.168.56.1 26356 typ host
a=candidate:1 2 UDP 2130705918 192.168.56.1 26357 typ host
a=candidate:2 1 UDP 2130705919 192.168.178.77 21586 typ host
a=candidate:2 2 UDP 2130705406 192.168.178.77 21587 typ host
a=candidate:3 1 UDP 2130705407 192.168.182.1 18734 typ host
a=candidate:3 2 UDP 2130704894 192.168.182.1 18735 typ host
a=candidate:4 1 UDP 2130704895 192.168.23.1 19834 typ host
a=candidate:4 2 UDP 2130704382 192.168.23.1 19835 typ host
a=x-candidate-ipv6:5 1 UDP 2130704383 fd00::752d:1263:5613:e7b 12132 typ host
a=x-candidate-ipv6:5 2 UDP 2130703870 fd00::752d:1263:5613:e7b 12133 typ host
a=candidate:6 1 UDP 2130703871 192.168.178.38 5568 typ host
a=candidate:6 2 UDP 2130703358 192.168.178.38 5569 typ host
a=x-candidate-ipv6:7 1 UDP 2130703359 fd00::548b:9544:dded:aa46 32884 typ host
a=x-candidate-ipv6:7 2 UDP 2130702846 fd00::548b:9544:dded:aa46 32885 typ host


## Danach kommen die Relay-Adressen des TURN-Servers. 	
a=candidate:8 1 UDP 184545791 80.66.20.21 56568 typ relay raddr 79.196.133.48 rport 19958
a=candidate:8 2 UDP 184545278 80.66.20.21 51995 typ relay raddr 79.196.133.48 rport 19959
a=candidate:9 1 TCP-PASS 174452735 80.66.20.21 57110 typ relay raddr 79.196.133.48 rport 15534
a=candidate:9 2 TCP-PASS 174452222 80.66.20.21 57110 typ relay raddr 79.196.133.48 rport 15534

## dazwischen dann ein paar STUN-Adressen
a=candidate:10 1 UDP 1694232063 79.196.133.48 19958 typ srflx raddr 192.168.178.77 rport 19958
a=candidate:10 2 UDP 1694231550 79.196.133.48 19959 typ srflx raddr 192.168.178.77 rport 19959

## Zum schluss noch die TCP Kandidaten (TURN und STUN)
a=candidate:11 1 TCP-ACT 174844927 80.66.20.21 57110 typ relay raddr 79.196.133.48 rport 15534
a=candidate:11 2 TCP-ACT 174844414 80.66.20.21 57110 typ relay raddr 79.196.133.48 rport 15534
a=candidate:12 1 TCP-ACT 1684793855 79.196.133.48 15534 typ srflx raddr 192.168.178.77 rport 15534
a=candidate:12 2 TCP-ACT 1684793342 79.196.133.48 15534 typ srflx raddr 192.168.178.77 rport 15534

Interessant ist für mich, dass der Client den Edge-Server der eigenen Topologie für Medien nutzt. Damit umgeht der Client natürlich das Problem einer Erreichbarkeit der Edge-Server auf der Gegenseite (Firewall auf Seiten des Teilnehmers). Allerdings bedeutet dies auch, dass der Weg eventuell "ungünstig" ist. Es könnte ja durchaus sein, dass der Client zuhause per NAT zum Konferenzanbieter eine bessere Verbindung hat als über den eigenen Edge zu gehen.

Aber halt: Erinnern Sie sich noch mal an die Funktion von STUN und TURN. Ein Client versucht immer den direkten schnellen Weg zu gehen und ein Home Office User wird per NAT in der Regel schon direkt den Edge des Konferenzbetreibers als Gegenstelle nutzen. Wenn NAT aber nicht geht, dann wird vermutlich auch 3478/443 auf den Edge des Konferenzanbieters nicht gehen. Der Client ist dann meist im LAN oder per VPN in der Firma und dann ist der Weg über den eigenen Edge der richtige Pfad. Hier verhält sich der Client beim "Anonymous Join" richtig.

Die Nutzung des eigenen Media Relay ist also nicht an die Nutzung der eigenen SIP-Pfade über Frontend und Edge gebunden, sondern unabhängig.

Zwischenstand

Die Analyse des Logs zeigt im Prinzip erst mal, dass der Client auf den Fehler bei einer Verbindung per Federation richtig reagiert und eine direkte Verbindung zum Edge-Server versucht. Wenn diese nicht klappt, versucht er den Weg über einen HTTP-Proxy, was letztlich auch zum Erfolg führt.

Die Traces zeigen aber auch gut, welchen negativen Effekt mehrere IP-Adressen beim Anbieter haben, zumindest solange der Skype for Business Client diese sequentiell durchprobiert. Auch das wäre noch zu tolerieren, wenn die Firewall diese Versuche aktiv unterbinden würde. Wenn die eigene Firewall aber die Pakete einfach mittels "DROP" verschwinden lässt, kommt der sehr lange TCP-Timeout beim Skype for Business Client negativ zum Tragen. Die Zeit bis zum Eintritt in das Meeting wird aus Sicht des Anwenders sehr lange. Dazu kommt. dass der Skype for Business Client auch den Weg über den Proxy nicht gleich korrekt bedient, sondern sich hier auch noch mal auf eine Strafrunde begibt.

Ich bin gespannt, ab wann sich das Verhalten bessert und ein schnellerer Beitritt in ein Meeting möglich wird.

Weitere Links