Lync Server 2013 - LS Mediation Server Error 25051

[MKremer]

Hallo,

seit ein paar Tagen erscheint in der Ereignisanzeige des Lync-Server immer mal wieder die Fehlermeldung "LS Mediation Server - 25051".

"Der Trunk (ferraribox.ask.loc;trunk=ferraribox.ask.loc) reagiert nicht auf eine OPTIONS-Anforderung, die vom Vermittlungsserverdienst gesendet wurde.
DNS-Auflösungsfehler: False
Ausnahme: Microsoft.Rtc.Signaling.OperationTimeoutException: This operation has timed out."

Die gesamte ein- und ausgehende Telefonie funktioniert aber fehlerfrei.

Kann es etwas mit der Umstellung auf TLS zu tun haben und wenn ja, was habe ich evtl. falsch gemacht? Bei der Umstellung bzw. Einrichtung von TLS habe ich mich an die Anleitung im Handbuch des OMG gehalten und die Zertifikate sind auch korrekt erstellt.

Die Meldung "...This operation has timed out." deutet ja irgendwie auf eine Unterbrechung oder eine zu späte Rückmeldung des OMG hin. Ist hier vielleicht bei den Regeln noch etwas zu beachten?

Danke und Gruß
Matthias

[MKremer]

Diese Meldungen erscheinen übrigens zur gleichen Zeit auf dem Gateway, wie die Fehlermeldungen auf dem Lync FE Server.

OMG800008): mux_sip:0 (1) error parsing sip message!
OMG800008): mux_sip:0 (1) XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
OMG800008): #026#003#001

[Johann Deutinger]

Das ist mysteriös! Leider ist es nur ganz schwer möglich, verschlüsselten Verkehr aufzuzeichnen und zu dekodieren. Irgendwas ist da nicht ok in der Konfiguration. Ich würde mal über die Weboberfläche des Gateways (Benutzer admin,, Passwort wie für Konfiguration) ein pcap aufzeichnen und sehen, ob da im TLS-Handshake was zu erkennen ist. Ist der cn des Gateway Zertifikats identisch mit dem FQDN im DNS?

[MKremer]

Hallo Herr Deutinger,

danke für die Rückmeldung. Der CN ist dem FQDN identisch.

Soweit ich gesehen habe, lässt sich das Logging über die Weboberfläche nur für max. 25 Minuten aktivieren. Da der Fehler auf dem Lync Server nur sporadisch angezeigt wird, ist es schwierig den Zeitpunkt zu treffen. Kann ich auch bei normalem Betrieb schon Unreglmäßigkeiten erkennen? Ein aktuelles pcap sieht für mich soweit gut aus.

Heute hatten wir den Fehler, in der Mittagszeit, allerdings in größerem Ausmaß, so dass auch die Telefonie betroffen war. Lync markierte das Gateway nach 5 Versuchen innerhalb von 5 Minuten als nicht erreichbar und erst ein Neustart des Gateway sorgte für Abhilfe. Das Logging über die Weboberfläche war zu diesem Zeitpunkt leider nicht aktiv. Ich beobachte weiter.

[Johann Deutinger]

Es gibt noch einen anderen möglichen Grund, dass ein Gateway vorübergehend als "down" markiert wird: Immer wenn vom ISDN ein Fehlercode ("Cause") kommt, der zur SIP-Response "503 Service Unavailable" führt, nimmt Lync das Gateway eine Zeitlang aus dem Routing. Die Umsetzung der Causes nach SIP Response Codes ist so implementiert, wie von Microsoft verlangt. Wenn im Syslog "503 Service Unavailable" steht, dann ist dieser Fall aufgetreten. Abhilfe wäre, am Gateway das ISDN-->SIP Mapping so zu ändern, dass ein anderer Fehlercode statt 503 erzeugt wird (4XX).

[MKremer]

Die Änderungen am ISDN->SIP Mapping habe ich mal vorgenommen.

In diesem Fall ist es aber eigentlich der umgekehrte Weg. Der Lync Server sendet jede Minute seine OPTIONS Anfragen, um zu sehen, ob das Gateway noch erreichbar ist. Soweit ich jetzt im Log gesehen habe, werden diese Anfragen meistens auch richtig verarbeitet und der Lync Server ist zufrieden.

Im Log sieht das dann z.B. so aus:
OMG800008): options:cc4daccd9536436b9c52847158a9839c (1) use 172.16.5.252

In unregelmäßigen Abständen, erscheinen aber die oben genannten Fehler.

Nun habe ich noch einmal auf dem Lync Server ein Trace mitlaufen lassen. Dort sieht man dann, wenn der Fehler auftritt, Folgendes:
Expert Info (Warn/Sequence): Connection reset (RST)

Es scheint also zu einer Unterbrechung zu kommen, die dann vermutlich die OPTIONS Anfrage verstümmelt. Vielleicht doch ein Hardwareproblem (Kabel o.ä.). Manchmal gibt es ja komische Zufälle.

Ich bleibe dran.

[MKremer]

Jetzt habe ich auch von der Hardwareseite mal alles durchgetestet. Neue Kabel, anderer Switch für Server und Gateway. Leider ohne Erfolg. Der Fehler "LS Mediation Server - 25051" tritt immer noch auf. Momentan gehen mir die Ideen aus. Auch diverse Lync-Seiten im Internet habe keine Lösung parat. Als Windows Server ist übrigens der 2012 R2 im Einsatz.

Es ist jetzt auch immer mal wieder so, dass man nach der Fehlermeldung zunächst nicht raustelefonieren kann, erst der zweite oder dritter Versuch ist dann wieder erfolgreich.

Macht es Sinn den Ferrari-Support zu kontaktieren oder sollte ich das Problem eher bei Microsoft melden?

[Johann Deutinger]

Man kann im Logging beim Gateway einschalten, dass auch OPTIONS requests mit aufgezeichnet werden. Parallel dazu sollte ein Lync Logging laufen (mindestens S4 mit all flags). Dann kann man vergleichen, was beide Seiten zum Thema OPTIONS ping festgehalten haben.

[MKremer]

Okay ich habe die Logs vom Gateway und von Lync. Allerdings ist für mich, als Laie auf dem Gebiet, besonders das Lync-Log, quasi nicht zu durchschauen.

Die Logs sind beigefügt. Jeweils einmal ohne Fehler und mit Fehler. Ich hoffe, dass ich immer die richtigen Auszüge erwischt habe. Für die Log-Auszüge habe ich mich an der Uhrzeit orientiert und beim Lync-Log noch -1 Stunde berücksichtigt.

[Johann Deutinger]

Bitte mal im Logging "Multiplexer SIP" und "IP" auf Level 2 oder 3 stellen - aber am besten nur über Nacht wenn sonst wenig Traffic ist, sonst wird evtl. zuviel ins Log geschrieben. Und dann den Ausschnitt mit dem "error parsing..." und das was in den Minuten davor passiert ist, zur Verfügung stellen.

[MKremer]

Anbei der gewünschte Auszug aus dem Log. Es ging schon nach Feierabend recht gut.

Der Fehler tritt um 19:02 Uhr und um 19:04 Uhr auf und dazwischen bzw. danach gibt es jeweils auch fehlerfreie Verbindungen.

[MKremer]

19:02:10.44 2015-02-27 19:02:04.31 OMG800008 mux_sip:0 (1) +++++ rec 200 15 s (connection closed)
19:02:10.44 2015-02-27 19:02:04.31 OMG800008 mux_sip:0 (1) tlsControl: code=200, ipmode='15', address='s', port='172.16.5.65'
19:02:10.44 2015-02-27 19:02:04.31 OMG800008 mux_sip:0 (1) wait for message
19:02:10.44 2015-02-27 19:02:04.86 OMG800008 mux_sip:0 (1) +++++ rec OPTIONS sip:ferraribox.ask.loc SIP/2.0#015
19:02:10.44 2015-02-27 19:02:04.86 OMG800008 mux_sip:0 (1) rcvtls: nethandle='23', ipmode='s', address='172.16.5.65', port='55032'
19:02:10.44 2015-02-27 19:02:04.86 OMG800008 mux_sip:0 (1) wait for message
19:02:10.44 2015-02-27 19:02:04.86 OMG800008 mux_sip:0 (1) +++++ rec


19:03:09.20 2015-02-27 19:03:05.57 OMG800008 mux_sip:0 (1) +++++ rec 200 22 s (connection closed)
19:03:09.20 2015-02-27 19:03:05.57 OMG800008 mux_sip:0 (1) tlsControl: code=200, ipmode='22', address='s', port='172.16.5.65'
19:03:09.20 2015-02-27 19:03:05.57 OMG800008 mux_sip:0 (1) wait for message
19:03:09.20 2015-02-27 19:03:06.13 OMG800008 mux_sip:0 (1) +++++ rec OPTIONS sip:ferraribox.ask.loc SIP/2.0#015
19:03:09.20 2015-02-27 19:03:06.13 OMG800008 mux_sip:0 (1) rcvtls: nethandle='15', ipmode='s', address='172.16.5.65', port='55034'
19:03:09.20 2015-02-27 19:03:06.14 OMG800008 mux_sip:0 (1) wait for message
19:03:09.20 2015-02-27 19:03:06.14 OMG800008 mux_sip:0 (1) +++++ rec OPTIONS sip:ferraribox.ask.loc SIP/2.0#015


Den auffälligsten Unterschied zwischen fehlerhaft (19:02 Uhr) und (19:03 Uhr) sehe ich in der letzten Zeile des Log-Auszugs.

[MKremer]

Nachdem ich gelesen habe, dass es eine neue Firmware (4.0.200) gibt, habe ich diese natürlich gleich mal eingespielt. Man weiß ja nie, ob es vielleicht hilft. Leider tut es das in diesem Fall nicht.

[Johann Deutinger]

Dann muss das wohl doch über unseren Support laufen, damit das weiter recherchiert wird.

[MKremer]

Alles klar. Dann zunächst einmal danke bis hierhin.

Ich bin ja guter Dinge, dass das Problem gelöst wird und bin mal gespannt, was es letztendlich ist.