Media Allocation, Desktop Sharing und MaxUserPort

Auf dieser Seite beschreibe ich ein paar Tipps, wie sie Verbindungsprobleme bei Audio/Video/Desktops-Sharing analysieren können. Auslöser war, dass ich auf meinem PC kein Desktop-Sharing mehr starten konnte. Am Ende habe ich dann herausgefunden, dass unter bestimmten Umständen mit Windows 1809 der Client keine TCP-Sockets öffnen kann.

Auslöser

Wie immer gibt es einen Auslöser für eine MSXFAQ-Seite und hier war es das Fehlverhalten, dass ich von heute auf morgen meinen Desktop nicht mehr freigeben konnte. Das zeigt sich wie folgt im Client.

An dem freigegebenen Fenster ist noch der Rahmen der Freigabe zu sehen aber der Status "Verbinden" bleibt quasi endlos stehen. Hier ist der Client natürlich irreführend, denn er hat ja schon aufgegeben.

Was liegt näher, als auf dem Client mit der Fehlersuche zu beginnen. Es könnte ja mal wieder eine Firewall oder ein lokaler Virenscanner sein. Auch veraltete Grafikkartentreiber werden gerne als Ursache genommen. hier war es aber so, dass der PC im LAN problemlos arbeiten konnte aber der Zugriff aus dem Internet nicht möglich war.

UCCAPILog

Aus der Seite Lync Keyhole Diagnose wissen Sie sich, wie man das UCAPILOG liest und auf SDP - Session Description Protocol die verschiedenen Media-Types verstanden. Wer also nach einem "Screensharing" sucht, muss einfach den folgenden Text suchen:

m=applicationsharing

Dumm nur, dass eben dieser Text im UCCAPILOG nicht zu finden war. Der INVITE mit der Bildschirmfreigabe hat also nie meinen PC verlassen. Da muss also vorher etwas schief gelaufen sein. Also habe ich rund um den Zeitpunkt nach weiteren Meldungen gesucht und wurde fündig:

12/11/2018|11:14:00.117 4564:204C WARN  :: Media allocation failure, 2AEA8048
12/11/2018|11:14:00.118 4564:204C WARN  :: ConnectivityDiagnosticMessage: BaseAddress="192.168.178.50:50043";
   MediaEpBlob="ICEWarn=0x200009,ICEWarnEx=0x1,LocalMR=80.66.20.21:443,PortRange=50040:50059,
   LocalLocation=1,RemoteLocation=0,FederationType=0,StunVer=0,
   CsntRqOut=0,CsntRqIn=0,CsntRspOut=0,CsntRspIn=0,Interfaces=0x2,BaseInterface=0x2,
   IceRole=1,RtpRtcpMux=0,AllocationTimeInMs=3856,EpAllocFailCode=0xc0044025,EpAllocFailSubCode=2,
   FirstHopRTTInMs=0,TransportBytesSent=0,TransportPktsSent=0,IceConnCheckStatus=0,
   PrelimConnChecksSucceeded=0,IceInitTS=3753512046008,ContactSrvMs=3855,AllocFinMs=3856,
   BlobGenTime=3753512049873,MediaDllVersion=6.0.8968.531,BlobVer=1";
   MediaMgrBlob="MrDnsE=av.uclabor.de,MrResE=1,MrErrE=0,MrBgnE=37535120459768960,
   MrEndE=37535120459796920,MrDnsI=sfbedge.uclabor.de,MrResI=0,MrErrI=11001,
   MrBgnI=37535120459752296,MrEndI=37535120460074728,MrDnsCacheReadAttempt=0,BlobVer=1"

Der "Media allocation failure, 2AEA8048" sagt schon, dass beim anfordern der STUN/TURN-Kandidaten etwas schief gelaufen sein muss. Der Client ist extern und muss daher von außen auf der AV-Edge zugreifen und sich entsprechende Kandidaten besorgen.

Einige Zeilen später ist auch zu sehen, dass der Client diese Meldung an als Error-Report an die Monitoring-Rolle sendet. Sie können den Fehler also auch in ihrem QoE-Service auswerten:

12/11/2018|11:14:00.119 4564:204C INFO  :: Sending Packet - 80.66.20.22:443 (From Local Address: 192.168.178.50:63229) 1994 bytes:
12/11/2018|11:14:00.119 4564:204C INFO  :: SERVICE sip:user2@uclabor.de SIP/2.0
Via: SIP/2.0/TLS 192.168.178.50:63229
Max-Forwards: 70
From: <sip:user2@uclabor.de>;tag=57a05d47d1;epid=768288fe52
To: <sip:user2@uclabor.de>
Call-ID: cd3da41e84cc4bd0853972e72aeb0cca
CSeq: 1 SERVICE
Contact: <sip:user2@uclabor.de;opaque=user:epid:b0UtSeBThV2qv3oLaPlWMAAA;gruu>
User-Agent: UCCAPI/16.0.11029.20045 OC/16.0.11029.20079 (Skype for Business)
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="D41129A5", 
   targetname="sfbfe1.uclabor.de", 
   crand="cd674f3a", cnum="1267", response="    "
Content-Type: application/msrtc-reporterror+xml
Content-Length: 1209
- <reportError  xmlns="http://schemas.microsoft.com/2006/09/sip/error-reporting">
    -  <error  toUri="sip:user1@uclabor.de"
            callId="0000"
            contentType="application/sdp"
            responseCode="0"
            requestType="INVITE">
           <diagHeader>52075;reason="Local endpoint allocation failed";UserType="Caller";
                    MediaType="applicationsharing";BaseAddress="192.168.178.50:50043";
                    MediaEpBlob="ICEWarn=0x200009,ICEWarnEx=0x1,LocalMR=80.66.20.21:443,
                    PortRange=50040:50059,LocalLocation=1,RemoteLocation=0,
                    FederationType=0,StunVer=0,CsntRqOut=0,CsntRqIn=0,CsntRspOut=0,
                    CsntRspIn=0,Interfaces=0x2,BaseInterface=0x2,IceRole=1,
                    RtpRtcpMux=0,AllocationTimeInMs=3856,EpAllocFailCode=0xc0044025,
                    EpAllocFailSubCode=2,FirstHopRTTInMs=0,TransportBytesSent=0,
                    TransportPktsSent=0,IceConnCheckStatus=0,PrelimConnChecksSucceeded=0,
                    IceInitTS=3753512046008,ContactSrvMs=3855,AllocFinMs=3856,
                    BlobGenTime=3753512049873,MediaDllVersion=6.0.8968.531,BlobVer=1";
                    MediaMgrBlob="MrDnsE=av.uclabor.de,MrResE=1,MrErrE=0,
                    MrBgnE=37535120459768960,MrEndE=37535120459796920,
                    MrDnsI=sfbedge.uclabor.de,MrResI=0,MrErrI=11001,
                    MrBgnI=37535120459752296,MrEndI=37535120460074728,
                    MrDnsCacheReadAttempt=0,BlobVer=1"
           </diagHeader>
        <progressReports/>
    - </error>
 </reportError>

Hier steht ja schon alles drin, wenn Sie wissen nach was sie suchen.

Analyse ICE-WARN

Die erste Anlaufstelle ist der Wert hinter "ICEWarn". Hier steht folgendes:

ICEWarn=0x200009

Diese Zahl kippe ich einfach auf meiner Seite ICEWarn Bedeutung ein und bekomme die Antwort, warum diese Verbindung nicht möglich war:

Die rot umrandete Meldung ist natürlich eine klare Aussage, dass der Client einfach keine TCP-Ports erhalten hat. Damit erklären sich dann auch die beiden anderen Fehler, die letztlich auch nur sagen, dass der Client den TURN-Server nicht erreichen kann. Die AVEdge-Adresse bekommt der Client bei der Anmeldung per Inband Provisioning und auch oben in der Fehlermeldung sehen Sie die IP-Adresse des MREdge. Hier ist es:

LocalMR=80.66.20.21:443

Viele Blog-Seiten und TechNet Artikel fokussieren sich aber auf die roten Fehler, die eine mangelnde Verbindung zum Edge-Server melden. Das ist durchaus oft der fall, wenn Firewalls und Proxy-Server etwas zu tief in die Paket schauen und diese blocken oder verändern. Hier ist ist aber die Warnung der eigentliche Fehler. Ohne Ports geht es eben nicht.

Netzwerk-Trace - negativ

Wenn Sie Netzwerk-Firewall und vielleicht im Virenscanner integrierte Schutzfunktionen ausschließen können und dann noch der Umweg über den HTTP-Proxy entfallen kann, dann ist ein Blick per Wireshark mein nächster Schritt. Ich wollte doch mal sehen, was zwischen meinen Client und dem Media Relay 80.66.20.21 über die Leitung geht. Ich habe dazu vorher natürlich die Audio-Verbindung beendet, so dass keine UDP-Pakete diesbezüglich meine Aufzeichnung erschweren. Allerdings habe dann nicht damit gerechnet, dass ich gar nichts sehe. Jeder Versuch einer Bildschirmfreigabe hat zu keinem sichtbaren Paket im Wireshark geführt. Das war aber auch nicht anders zu erwarten, da der Client ja gar keinen Port bekommen hat.

Hinweise auf Source Port

Ich habe dann etwas ausgiebiger im Internet gesucht und tatsächlich einige interessante Posts gefunden:

MaxUserPort

Dennoch scheint es ja etwas damit zu tun zu haben, dass der Skype for Business Client auf meinem Computer irgendwie nicht "raus" kommt. Meine aktuelle Konfiguration ist aber

C:\>netsh int ipv6 show dynamicport tcp

Protokoll tcp Dynamischer Portbereich
---------------------------------
Startport      : 49152
Anzahl von Ports : 16384


C:\>netsh int ipv4 show dynamicport tcp

Protokoll tcp Dynamischer Portbereich
---------------------------------
Startport      : 49152
Anzahl von Ports : 16384

Das sieht so erst mal nach Standard aus. Also habe ich erst einmal den RegKey gesetzt. Bei mir stand vorher nämlich nur folgendes

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"ForwardBroadcasts"=dword:00000000
"ICSDomain"="mshome.net"
"IPEnableRouter"=dword:00000000
"NameServer"=""
"SyncDomainWithMembership"=dword:00000001
"Domain"="netatwork.de"
"HostName"="FC-T480S"
"NV Domain"="netatwork.de"
"NV HostName"="FC-T480S"
"CITRIXBACKUPTCPWINDOWSIZE"=dword:00000000

Also habe ich schnell addiert

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
MaxUserPort: DWORD = 5000

Und nach einem Neustart des Computer konnte Skype for Business wieder den Desktop und Fenster freigeben. Da war natürlich die Gegenprobe angesagt: Raus mit dem Key und wieder neu gestartet. Skype for Business konnte nicht mehr den Desktop oder Fenster freigeben. Also hat es schon damit etwas zu tun. Ich habe dann mal auf anderen PCs geschaut, die schon länger Windows 10 nutzen. Hier habe ich dann den Key mit einem ganz anderen Weg gefunden

Wobei ich hier nicht mehr nachvollziehen kann, ob das nicht eine Altlast oder eine frühere Gruppenrichtlinie ist. Ich wollte mich aber nicht damit abfinden, warum bei mir der Skype for Business Client keine Ports allokieren konnte während es auf anderen Clients sehr wohl auch ohne den MaxUserPort-Schlüssel möglich war.

Netzwerk Reset

Dann habe ich mich dran erinnert, dass es schon früher oft die Tricks gab, einfach mal den Windows TCP/IP-Stack zurück zu setzen. Früher musste man dazu die Kommandozeile als Administrator nutzen

netsh winsock reset
netsh int ip reset

von dem einfachen WINSOCK-Reset habe ich mir nichts erwartet aber beim Interface schon. Daher habe ich gemacht:

netsh interface ipv4 reset
Depotweiterleitung wird zurückgesetzt... OK
Depot wird zurückgesetzt... OK
Steuerungsprotokoll wird zurückgesetzt... OK
Echosequenzanforderung wird zurückgesetzt... OK
Global wird zurückgesetzt... OK
Schnittstelle wird zurückgesetzt... OK
Anycastadresse wird zurückgesetzt... OK
Multicastadresse wird zurückgesetzt... OK
Unicastadresse wird zurückgesetzt... OK
Nachbar wird zurückgesetzt... OK
Pfad wird zurückgesetzt... OK
Potentiell wird zurückgesetzt... OK
Präfixrichtlinie wird zurückgesetzt... OK
Proxynachbar wird zurückgesetzt... OK
Route wird zurückgesetzt... OK
Standordpräfix wird zurückgesetzt... OK
Unterschnittstelle wird zurückgesetzt... OK
Reaktivierungsmuster wird zurückgesetzt... OK
Nachbar auflösen wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... Fehler
Zugriff verweigert

 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
 wird zurückgesetzt... OK
Starten Sie den Computer neu, um die Aktion abzuschließen.

Eine Einstellung konnte NETSH auch nicht als Administrator zurück setzen. Ein Neustart war erforderlich aber alle WLAN-und VPN-Einträge waren noch da.

Holzhammer Reset

Mit Windows 10 1809 finde ich einen Punkt im Status der Netzwerks.

Achtung
Damit werden auch WLAN-Kennworte und VPN-Einstellungen entfernt.

Damit werden wohl auch alle Einstellungen, die sich vererbt oder verstellt haben könnten, wieder auf einen Default zurück gestellt.

Was hat geholfen?

In meinem Fall hat das auch geholfen. So stellt sich mir das Problem wie folgt dar. Es hat bislang nur zwei Windows 1809 System betroffen, die neu installiert waren. Alle "Update-Systeme" hatten das Problem interessanterweise nicht. Ich konnte aber mit dem Setzen des "MaxUserPort"-Schlüsselt den Fehler beim "Skype for Business Screen Sharing" löschen und mit dem Löschen des Keys auch wieder herbeiführen. Der Reset des Interface hat die Probleme ebenfalls gelöst.

Windows Key + Reboot NETSH int ip reset Funktion

1809 Neuinstallation

Nein

Nein

bei mir Nein

1809 Neuinstallation

Ja

Nein

Ja

1809 Neuinstallation

Nein

Ja

Ja

1809 Neuinstallation

Ja

Ja

Ja

1809 Upgrade

egal

Egal

ja

Beide Lösungswege führen zum Ziel, wobei mir das Netzwerk-Reset sympathischer ist. Wer weiß, welche Unstimmigkeiten hier noch in Windows schlummern, die durch den "MaxUserPort"-Schlüssel nicht gelöst werden.

Irreführende Meldung des Skype Clients

Etwas unpassend ist natürlich das Verhalten des Skype for Business Client, welcher im  Hintergrund schon sofort erkannte hat, dass der den Edge-Server nicht erreichen kann aber manchmal weiterhin das Fenster auf "Verbinden..." stehen lässt.

Weitere Links