Lync Timeouts

SIP ist "Realtime" und die "Messages" müssen möglichst schnell zum Ziel gebracht werden. Exchange ist hier viel entspannter da Mails auch gerne mal ein paar Minuten oder sogar Stunden in einer Queue liegen können. Bei SIP sprechen wir aber maximal von Sekunden. Lync hat daher Funktionen eingebaut, die zum einen die Übertragung einer Meldung überwachen und beim Ausbleibender darauf reagieren.

Zudem gibt es untereinander "Heartbeats", mit denen Lync die Verfügbarkeit von Diensten prüft um z.B. Konferenzen nur an AVMCU-Systeme zu senden, die "online" sind.

Timeouts kommen sehr gerne vor, wenn der Edge-Server nicht erreichbar ist und der Client oder der Konferenz-CAA schonbi szu 5 Sek auf den MRAS/TURN-Request wartet. Prüfen Sie immer die Funktion des Edge-Servers, wenn es zu deutlichen Verzögerungen kommen.

Default Timeouts

Folgende Timeouts zwischen den Komponenten habe ich mittlerweile aus verschiedenen Quellen ermitteln können:

Timeout Quelle Ziel Einsatz

1,5 Sek

MED

GW

Auf einen INVITE des Mediation Servers zum Gateway muss diese innerhalb von 1,5 Sekunden mit einem "100 Trying" antworten. Microsoft hat dies mit Lync 2010 CU4 eingeführt, damit Lync erkennen kann, dass das Gateway den INVITE angenommen und verstanden hat. Die kurze Zeit legt nahe, dass das Gateway die Meldung sendet, ehe es auf der anderen Seite einen Verbindungaufbau startet.

4 Sek

MED

GW
PROXY

Socket Timeout
Lync nutzt SIP over TCP mit TLS Verschlüsselung. Der Verbindungsaufbau per TCP wird von 30Sek auf 4 Sek reduziert. Kommt in der Zeit keine TCP-Verbindung zustande, dann wird ein alternativer Weg gesucht.
Im LAN sollte das nie passieren, aber über WAN-Verbindungen mit Überfüllung kann das schon mal ein Problem werden

10 Sek

MED

GW

Timeout auf einen INVITE, wenn das Gateway zwischenzeitlich kein kein RINGING sendet. Wenn ein Rufaufbau in ein PSTN-Netz z.B. sehr lange braucht (Mobilfunk), kann dies schon passieren.
Lösung: Anpassen des "FailOverTimeout " in OutboundRouting.exe.config von 10000 -> 20000.

10 Sek

FE

MED

Der Mediation Server sollte auf einen INVITE vom Frontend sofort mit einem 183 antworten. Bleibt der 183 länger als 10 Sek aus, bricht der FE den INVITE durch einen CANCEL zum Mediation ab und sendet den INVITE zu einem anderen Mediation Server.

10 Sek

FE

ExUM

Sendet der Lync Frontend einen "INVITE" an Exchange UM, dann hat der Server maximal 10Sek Zeit, den Ruf anzunehmen. Der Exchange muss natürlich auch Nach 10 Sekunden versucht Lync den nächsten ExUM Server zu erreichen.
Wenn der Exchange Server nicht "Online" ist, dann erkennt das Lync natürlich schon nach 4 Sek TCP Timeout

20 Sek

FE

ExUM

Nach maximal 20 Sekunden bricht Lync den Versuch ab, einen Exchange UM Server zu erreichen. Per Default werden also nur zwei Server versucht, wenn beide die TCP-Verbindung annehmen (4 Sek Timeout) und dann nicht reagieren.

20 Sek

 

FE

Klingelt es bei einem EV-Client, dann bricht das Lync Routing den Call dieser nach 20 Sekunden mit einem "480 Temporarily unavailable" ab.

30 Sek

MED

GW

Wenn ein Anruf nicht sofort angenommen wird, dann steht nach dem ICE-Handshake noch keine Audio-Verbindung. Damit kann die Firewall keine UDP-Pakete mehr erkennen und viele Firewalls vergessen die Verbindnung. Der Call kommt nicht zustande.

5x1Min

MED

GW

Mediationserver sendet jede Minute ein "SIP Options" zum Gateway. Wenn das Gateway 5 mal hintereinander nicht reagiert wird es als "Down" angesehen. Sind alle Gateways eines Pools "down", dann sendet der Mediation einen 503 zum Frontend, damit er den nächsten Mediation Pool im Routing nutzt

???

FE

FE

Die Lync Frontend Server nutzen den Port 444 per HTTPS um einen Heartbeat durchzuführen und z.B. die verfügbaren Konferenzressourcen zu überwachen.

60 Sek

 

Client

Klingelt es bei einem PC2PC-Client, dann bricht dieser nach 60 Sekunden mit einem "480 Temporarily unavailable" ab

250ms

 

RTCP

RTCP-Feedback im "FastMode"
RTCP Details: 3.2.2 Timers
http://msdn.microsoft.com/en-us/library/cc669345.aspx

2 Sek

 

RTCP

RTCP Bye timer: This timer MUST be set to 2 seconds
RTCP Details: 3.2.2 Timers
http://msdn.microsoft.com/en-us/library/cc669345.aspx

30 Sek

 

RTCP

Ein RTP Sender erwartet regelmäßige Rückmeldungen per RTCP. Bleiben diese länger aus, dann geht der Sender davon aus, dass der Empänger nicht mehr da ist und beendet den Anruf. Siehe auch RTCP und Sessiontimeout

15 Min

RTP

RTP

Häufiger Timeout bei der Telekom und anderen SIP-Anbieter. Wenn der Client kein Refresh macht, kann ein NAT-Router den Eintrag löschen und Rückpakete kommen nicht mehr mehr an -> Einseitiges Audio. Siehe auch RTCP und Sessiontimeout

90 Min

 

Konferenz

Eine Konferenz wird von Lync nach 90 Minuten beendet, wenn keine Firmenbenutzer mehr daran teilnehmen

24 h

 

Konferenz

Wenn ein Firmenbenutzer in einer Konferenz ist, aber keine weiteren Personen hinzukommen, dann wird diese Konferenz nach 24h beendet. So sollen "Endloskonferenzen" verhindert werden, wenn ein Anwender das Fenster nach dem Ende nicht schließt.

15 Tage

 

Konferenz

15 Tage nach dem Ende einer Konferenz wird der Inhalt gelöscht. Dies ist über die Einstellung "Set-Conferencingconfiguration" geändert werden.

8h

 

Konferenz

MeetNow-URLs laufen maximal 8 h. On-Premises kann das angepasst werden

Set-CsUserServicesConfiguration -DeactivationGracePeriod 90.00:00:00 
Set-CsUserServicesConfiguration -MaxScheduledMeetingsPerOrganizer 100

So kann ein Teilnehmer maximal 100 MeetNow-URL mit einer Dauer von 90 Tagen verwenden.

1,5 Sek

 

Aries

Timeout zwischen der Wahl von zwei Ziffern, nach denen die Nummer gewählt wird, wenn eine Regel passt

10 Sek

 

Aries

Nach dieser Zeit wird gewählt, auch wenn die Nummer nicht normalisiert werden kann.

8h

FE

RGS

Der Responsegroup Service holt sich per Default alle 8h die Verteilerlisten, um die Mitglieder neu zu lesen. Das kann natürlich durch einen Neustart des RGS-Service beschleunigt werden aber sie können auch die Einstellung mit Bedacht anpassen, indem sie folgenden Eintrag in der Datei: "\Skype for Business Server 2015\Application Host\OcsAppServerHost.exe.config" einbinden:

<configuration>
  <appSettings>
    <add key="AdUpdateInterval" value="15"/>
  </appSettings>
</configuration>

Die Änderungen werden erst nach einem Neustart des Service aktiv

stop-cswindowsservice RTCRGS -Graceful 
start-cswindowsservice RTCRGS

Diese Liste ist nicht vollständig und es kann durchaus sein, dass Microsoft mit Updates diese Werte anpasst oder neue Timeouts addiert.

Timeouts ändern

Einige Timeouts sind in den verschiedenen XML-Dateien einsehbar und sogar änderbar. Allerdings verlassen Sie dann den Pfad der "supporteten Umgebung". Niemand erwartet solche Änderungen . Sie sollten diese als "DOKUMENTIEREN". Ich werde auf die einzelnen Werte hier nicht weiter eingehen.
Ein Lync Update kann die Dateien überschreiben und damit die Änderungen wieder rückgängig machen.

Wenn Sie die Werte anpassen, dann sollten Sie das in kleinen Schritten tun und mit Werkzeugen wie NETMON nachverfolgen, dass dies dann ihr Problem auch tatsächlich löst.

Eine hier interessante Datei ist "OutboundRouting.exe.config", die im Pfad "C:\Program Files\Microsoft Lync Server 2010\Server\Core\" liegt.

<configuration>
    <appSettings>
      <add key="FailOverTimeout" value="10000"/>
      <add key="MinGwWaitingTime" value="1"/>
      <add key="MaxGwWaitingTime" value="20"/>
      <add key="FailuresForGatewayDown" value="10"/>
      <add key="FailuresForGatewayLessPreferred" value="25"/>
      <!-- Valid values are between 5 and 600 -->
      <add key="HealthMonitoringInterval" value="300"/>
      <!-- Valid values are between 60 and 3600 -->
      <add key="GatewayStateReportingInterval" value="1800" />
  </appSettings>
</configuration>

Eine weitere Datei betrifft Exchange Unified Messaging "ExumRouting.exe.config"

<configuration>
    <runtime>
        <gcServer enabled="true" />
    </runtime>
  <appSettings>
    <!-- Time to wait für ExUM server to respond before giving up. Default is 10000 milliseconds-->
    <add key="ExumAttemptTimeLimit" value="10000"/>

    <!-- Time to wait für the finalExUM server to respond before giving up. Default is 20000 milliseconds-->
    <add key="ExumFinalAttemptTimeLimit" value="20000"/>

    <!-- Number of ExUM servers to try before giving up. -->
    <add key="ExumNumberOfServersToTry" value="2"/>

    <!-- Port that all Exchange UM servers listen on. -->
    <!-- A value of 0 indicates the port is selected based on the transport (tcp=5060, tls=5061)-->
    <add key="ExumListenPort" value="5061"/>

    <!-- Transport Exchange UM is configured to use (tcp or tls).-->
    <add key="ExumTransport" value="tls"/>
  </appSettings>
</configuration>

Sie sehen auch hier, dass ein Versuch maximal 10 Sekunden offen sein kann, ehe ein anderer Server gefragt wird. Mehr als zwei Server werden aber nicht gefragt.

Bei Lync 2013 gibt es die Konfiguration auf dem Trunk:

EnableFastFailoverTimer
Bei Festlegung auf "True" werden ausgehende Anrufe, die nicht innerhalb von 10 Sekunden vom Gateway beantwortet werden, an den nächsten verfügbaren Trunk weitergeleitet. Sind keine zusätzlichen Trunks vorhanden, wird der Anruf automatisch abgebrochen. In einer Organisation mit langsamen Netzwerken und Gatewayreaktionen kann dies dazu führen, dass Anrufe unnötigerweise abgebrochen werden. Der Standardwert ist "True".
Quelle: Set-CsTrunkConfiguration  http://technet.microsoft.com/de-de/library/gg398238.aspx

Einstellungen auf dem Client

Einige Einstellungen kann der Anwender selbst in der GUI konfigurieren wie z.B. hier bei der Rufweiterleitung:

Diese Einstellungen werden per SIP über einen "SERVICE"-Request zum Server übertragen.

SEFAUtil

Einige Einstellungen bezüglich des Anwender können per SEFAUTIL gesetzt werden.

SEFAUtil.exe /server:lync01.msxfaq.de User@domain.com /callanswerwaittime:40

Allerdings sind diese Werte nicht von Dauer. Wenn der Anwender die Weiterleitung wieder ändert, werden die Defaults gesetzt.

Routing State

Ein Mediation Server sendet nur dann einen 200 OK, wenn mindestens ein Gateway "online" ist. Ansonsten sendet der Mediation einen 50x, damit der Frontend sofort einen alternativen Mediation Server Pool nutzen kann. Lync hat noch einige weitere pfiffige Komponenten, die die Verfügbarkeit eines Pfades erkennen und entsprechend alternativen suchen.

Weitere Links