Direct Routing Hochverfügbar

Ein SIP-Trunk zu Teams zur Telefonie ist unterliegt einigen Besonderheiten, wenn es um "Hochverfügbarkeit" geht. Knifflig sind hier die ausgehenden Telefonate in das TK-Netzwerk, da Sie auf das Verhalten der SBCs bei Microsoft nur bedingt einen Einfluss haben.

Eingehende Anrufe

Zuerst betrachte ich aber einen eingehenden Anruf, der über den eigenen SBC oder den eines Providers zu Microsoft geroutet wird. Microsoft veröffentlicht dazu drei DNS-Namen, die sie in der vorgegebenen Reihenfolge nutzen sollten.

sip.pstnhub.microsoft.com
sip2.pstnhub.microsoft.com
sip3.pstnhub.microsoft.com

Wenn Sie sip.pstnhub.microsoft.com bekommen Sie immer nur eine IP-Adresse, die auch gleich bleibt. Ich bin aber sicher, dass Microsoft hier nicht nur einen Zugang bereitgestellt, sondern er Loadbalancing mehrere Systeme die Anfragen beantworten.

nslookup sip.pstnhub.microsoft.com

Name: sip-du-a-euwe.westeurope.cloudapp.azure.com
Address: 52.114.75.24
Aliases: sip.pstnhub.microsoft.com
sip.pstnhub.trafficmanager.net

Den Eintrag "sip1.pstnhub.microsoft.com" gibt es nicht aber auf die anderen drei Einträge liefert Microsoft dann über GeoDNS den naheliegenden Eingang aus. Für europäische Kunden sind dies Europa, USA, Asien. Das kann sich aber ändern. Zusätzlich gibt es noch den Eintrag "sip-all.pstnhub.microsoft.com", der aber nicht genutzt werden sollte.

Ihr SBC sollte daher immer erst "sip.pstnhub.microsoft.com" nutzen und wenn das System nicht erreichbar und erst dann auf "sip2.pstnhub.microsoft.com" umschalten, wenn der erste Server nicht erreichbar ist.

Damit Sie nicht erst beim "INVITE" bemerken, ob der Server auf der anderen Seite erreichbar ist, sollten Sie "OPTIONS"-Anfragen stellen und damit ein Fehler in der Verbindung auch erkennen, wenn keine Gespräche aufgebaut werden

Ausgehende Anrufe

In die Gegenrichtung kann Microsoft natürlich auch mehr als einen SBC ansprechen. Hier können Sie als Gegenstelle unterschiedliche Optionen nutzen. Nicht alle Optionen sind "sinnvoll" oder erlaubt, allerdings sind Aussagen dazu nicht zuverlässig. Microsoft schreibt nicht, was nicht erlaubt ist, sondern nur, wie sie es haben wollen.

Option Beschreibung Status

Mehrere SBCs mit Loadbalancer

Sie können natürlich ebenfalls einen Loadbalancer einsetzen, der Zugriff auf eine IP-Adresse animmt und an einen "erreichbaren" SBC weiterleitet. Die Microsoft Server kommen durchaus mit unterschiedlichen Source-IP-Adressen an, so dass eine Verteilung möglich ist. Für Microsoft sieht ihre Gegenstelle wie "ein Server" aus

Nicht dokumentiert

DNS-Loadbalancer

Eine zweite Option ist natürlich mehrere SBCs mit eigenen öffentlichen IP-Adressen zu veröffentlichen und per DNS bei Abfragen von Microsoft nur die Adressen zu liefern, die auch funktionieren. Das Verfahren nutzt Microsoft mit outlook.office365.com ja ebenfalls.

Nicht dokumentiert

DNS-RoundRobin

Bei einem einfachen DNS-RoundRobin liefern Sie natürlich mehrere IP-Adressen aus. Wenn dann ein System ausfällt, dann ist dies nicht sofort zu erkennen. Dies würde ich nicht als Lösung sehen.

Nicht dokumentiert

IP-Failover/Cluster

In der TK-Welt ist es durchaus üblich, mit Aktiv/Passiv-Systemen zu arbeiten, die damit nur zu 50% aktiv sind. Solche Cluster haben dann ein aktives System, welches alle Verbindungen bedient aber parallel seinen kompletten Status auf ein zweites System synchronisiert. Nach außen ist dann nur ein System "sichtbar" und wenn dies ausfällt, dann übernimmt das zweite System sogar die bestehenden RTP-Verbindungen und die IP-Adressen. Bestehenden Verbindungen werden sogar weiter geführt.

Nicht dokumentiert

Mehrere SBC-Einträge

Sie können natürlich in ihrer Teams-Konfiguration mehrere SBCs hinterlegen und über CSVoiceRoute und Kosten sogar deren Priorität steuern

Dokumentiert

Von allen Varianten ist aus meiner Sicht nur die letzte Option von Microsoft wirklich dokumentiert. Allerdings gibt es hier einige Einschränkungen, auf die ich im weiteren Text eingehe.

Daher könnte ich mir auch vorstellen, dass die vorletzte Option "IP-Failover/Cluster" durchaus nutzbar ist, denn Microsoft "sieht" davon ja nichts. Auch wenn Sie nicht explizit dokumentiert ist, sieht Teams immer nur genau einen SBC der beim Ausfall des primären Systems durch ein "Backup-System" ohne Unterbrechung oder mit minimaler Ausfallzeit übernommen wird.

Microsofts Logik

Die wichtige Seite beim Verständnis des Routings ausgehender Anrufe zu einem SBC beschreibt Microsoft auf der folgenden Seiten:

In Kürze:

  • PSTN Usages sind nur "Strings"
    Die definiert man halt und sind der Klebstoff, um sie Benutzern über eine CsOnlineVoiceRoutingPolicy zuzuweisen und auf Voicerouten zu verwenden
  • CsOnlineVoiceRoutingPolicy
    Jeder Benutzer hat genau eine Voice Routing Policy. Diese wird mit New-CsOnlineVoiceRoutingPolicy angelegt, mit Set-CsOnlineVoiceRoutingPolicy konfiguriert und mit Grant-CsOnlineVoiceRoutingPolicy zugewiesen. Über diesen Weg bekommt ein Benutzer seine "PSTNUsages" zugewiesen
  • CSOnlineVoiceRoute
    Dieser Eintrag verbindet ein SBC mit PSTN-Usages und Rufnummernfiltern

Wenn ein Benutzer eine Rufnummer anwählt, dann sind erst einmal alle CSOnlineVoiceRouten möglich. Nun streicht das Teams Backend die Routen, für die der Benutzer keine passenden PSTN-Usages vorweisen kann. Die verbleibenden Routen werden in der Priorität abgearbeitet und geprüft, ob die Rufnummer zum Filter passt. Wenn dann nur noch eine Route mit einem Gateway übrig bleibt, ist das Ziel klar. Sollte das Gateway dann nicht funktionieren, kommt der Anruf nicht zustande. Wenn wir aber über Hochverfügbarkeit reden, dann ist es der Regelfall, dass eine Route mit zwei oder mehr Gateways übrig bleibt oder sogar mehrere Routen mit Gateways zur Wahl stehen.

Hier mal ein Beispiel

In dem Beispiel kann der Benutzer mit der Policy anhand der PSTN-Policies nur die Route 1,3 und 4 nutzen. Er hat quasi nicht das Recht "DEBLN". Wenn er nun aber eine Rufnummer in Paderborn anruft, dann passt anhand der Priorität die erste Route aber auch die dritte und vierte Route.

Damit ist klar, dass zuerst SBC1/SBC2 angesprochen werden und dann die SBCs der dritten Route und wenn SBC1/2/3 und 4 niciht verfügbar sind, dann würde sogar SBC5 zum Einsatz kommen.

Die Frage ist hier aber nun, wie Microsoft Teams die Last verteilt und wann ein SBC als "Down" anzusehen ist.

Quellen

Ich habe dazu verschiedene Quellen angezapft und diverse Aussagen gefunden. Dies ist eine Momentaufnahme (Okt 2002) und eventuell ändert Microsoft auch immer mal was.

"If neither SBC is available, the route with lower priority will be tried"
Quelle https://docs.microsoft.com/en-s/microsoftteams/direct-routing-voice-routing

Leider ist hier aber nicht ausgeführt, was "Available" genau bedeutet.

Unter dem Parameter -FailoverTimeSeconds steht:
When set to 10 (default value), outbound calls that are not answered by the gateway within 10 seconds are routed to the next available trunk
https://docs.microsoft.com/en-us/powershell/module/skype/set-csonlinepstngateway?view=skype-ps

Die Aussage werte ich so, dass Teams 10 Sekunden auf eine Antwort des Gateways wartet. Aber ist mit "Next available Trunk" dann das nächste Gateway in der gleichen VoiceRoute gemeint oder schon eine neue Route.

If SBC's are defined in different routes with different priorities we will always try the highest priority route first since its has the highest priority. That is failback calling
Quelle: Aussage aus einer SupportAnfrage.

Die Aussage hilft nicht so viel weiter, denn ich habe nichts anderes erwartet dass zuerst die SBCs der Route mit der höchsten Priorität genutzt werden. Es ist aber keine Aussage zum Failover-Routing zwischen SBCs in der gleichen Route. Das kommt dann erst in einem weiteren Satz:

For high availability of multiple SBC's, they need to be in the same route. In this case we treat them the same if healthy and load balance as described in this linked article.

Auf einer weiteren Seite gibt es noch eine ausführlicher Beschreibung:

Demotion means that the SBC will not be tried first. For example, we have sbc1.contoso.com and sbc2.contoso.com with equal priority.
If sbc1.contoso.com does not send SIP options on a regular interval as previously described, it is demoted. Next, sbc2.contoso.com tries for the call. If sbc2.contoso.con cannot deliver the call, the sbc1.contoso.com (demoted) is tried again before a failure is generated.
If two (or more) SBCs in one route are considered healthy and equal, Fisher-Yates shuffle is applied to distribute the calls between the SBCs.
Quelle: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot

OPTIONS

Zur besseren Überwachung der Erreichbarkeit nutzt Microsoft entsprechende "OPTIONS"-Pakete. Diese können und sollten in beide Richtungen genutzt werden, d.h. sowohl der eigene SBC kann per OPTIONS die Erreichbarkeit der Teams-Systeme prüfen und damit auch Teams Bescheid sagen, dass der SBC aktiv ist. Umgekehrt kann aber auch Teams seinerseits den lokalen SBC per OPTIONS-Anfragen überwachen. Beide Einstellungen können auf dem Trunk aktiviert oder deaktiviert werden:

Set-CsOnlinePSTNGateway `
   --FailoverTimeSeconds 10 `
    -SendSipOptions $true

Die Bedeutung von SendSipOptions ist laut Doku:

-SendSipOptions
Defines if an SBC will or will not send the SIP options. 
If disabled, the SBC will be excluded from Monitoring and Alerting system. 
We highly recommend that you enable SIP options. Default value is True.

Die SIP-OPTIONS sind ein aktivier Teil in der Überwachung der SBCs

If one of the SBC's isn't responding to options from us it will be demoted and the other SBC(s) tried first. We will always attempt to try an SBCs in priority route even if all demoted before trying next available route by priority
Quelle: Aussage aus einer SupportAnfrage.

Die Aussage ist in mehrerer Hinsicht interessant:

  • Try Route auch wenn alle Down
    Wenn alle SBCs in einer Route nicht reagieren, wird dennoch ein SBC erst einmal angesprochen. Es wird aber nicht ein zweiter SBC angesprochen sondern dann die nächste Route genutzt. Das macht Sinn, wenn z.B. alle SBCs einer Route in einem Standort stehen und der Standort ausgefallen ist.
  • Bedeutung von Options-Request
    Zudem wird hier gesagt, dass der Status eines SBC an seiner Reaktion auf den OPTIONS-Request fest gemacht wird. Ein SBC, der nicht reagiert, wird nicht mehr als "Alive "angesehen. Da Teams aber nur alle 60 Sekunden einen OPTIONS-Request sendet, erkennt Teams einen Ausfall nicht sofort. Da kommt dann der Timeout (Default: 10 Sek) zum tragen, wann Teams den INVITE dann zu einem anderen SBC sendet.

Und dann gab es noch eine Aussage:

Direct Routing takes the regular interval options three times (the regular interval is one minute). If options were send during the last three minutes, the SBC is considered healthy. If the SBC in the example sent options at any period between 11:12 AM and 11:15 AM, it is considered healthy. If not, the SBC will be demoted from the route. Demotion means that the SBC will not be tried first. For example, we have sbc1.contoso.com and sbc2.contoso.com with equal priority.

Teams erwartet also nicht, dass jede Minute ein OPTIONS-Request ankommt. Es reicht, wenn ein OPTIONS eines SBC innerhalb von 3 Minuten ankommt. Erst wenn der eigene SBC länger als 3 MInuten kein OPTIONS mehr sendet, geht Teams davon aus, dass der SBC offline ist. Aber auch in die Gegenrichtung sendet Teams regelmäßig einen "OPTIONS" an den SBC.

Status im Monitoring

Die Ergebnisse der OPTIONS-Pakete meldet Teams auch im Health dashboard, welche neben den OPTIONS natürlich auch den TLS-Status und weitere Parameter meldet.

Im Bezug auf die OPTIONS-Anfragen kennt das Dashboard pro SBC drei Statusmeldungen, von denen aber nur zwei direkt sichtbar sind.

  • "Active – The SBC is active"
    Innerhalb der letzten drei Minuten gab es mindestens ein OPTIONS-Paket
  • "Warning, no SIP Options"
    Diese Meldung kommt, wenn Sie die "OPTIONS"-Prüfung aktiviert haben aber keine entsprechenden Meldungen ausgetauscht werden. Prüfen Sie auf dem SBC, ob dieser selbst OPTIONS sendet und vor allem auch auf eingehende OPTIONS von Teams antwortet. Ein Blick in das SYSLOG des eigenen SBCs sollte hier Klarheit bringen
  • "Warning, SIP Messages aren't configured"
    Diese Warnung weist Sie darauf hin, dass die Überwachung per "OPTIONS" nicht aktiviert ist. Eine Überwachung ist daher nicht möglich. Aus Sicht eines Betreibers kein wünschenswerter Zustand.

Ein "Status", ob ein SBC von Teams aber als "Online" oder "degraded" eingestuft wird, entspricht das nicht, Es ist aber anzunehmen, dass ein System, welche drei Minuten auf ""Warning, no SIP Options" steht, als "degraded" einzustufen ist. Durch die interne Logik bekommt aber immer noch ein Gateway einen INVITE und erst nach 10 Sekunden geht es dann zu einem anderen Gateway weiter.

Am SBC-Icon selbst gibt es aber noch einen weiteren Status, der in den Details dann sichtbar wird. In den Details gibt es aber einen "SBC Status", der als "overall status of the SBC, based on all monitored parameters." bezeichnet wird. Bislang habe ich nur die beiden folgenden Statusmeldungen gesehen:

Status Beispiel Beschreibung

Aktiv

Der Status "Aktiv" sagt nach meiner Einschätzung nur aus, dass in den letzten 24h Anrufe über den SBC gelaufen sind.

Inaktiv

Der Status "inakiv" ist leider nicht eindeutig. Er zeigt nach meiner Einschätzung nur an, dass in den letzten 24h keine Calls über diesen SBC gelaufen sind und daher dieser SBC anscheinend nicht genutzt wird. Der Status kann aber durchaus Inaktiv sein, obwohl "SIP Option = Aktiv" ist.

Error

Wenn in einen SBC angebe, der keine "OPTIONS" unterstützt und gar nicht erreichbar ist, dann ist der Status quasi auf "Unbekannt"

Ich vermisse hier deutlich einen Status "Down". Aktuell prüfe ich immer alle drei Informationen zu "Status", "SIP OPTIONS Status" und "TLS-Status".

Ich habe bislang keinen Weg gefunden, per Graph, SfB-Online-PowerShell o.ä. den Status der SBCs aus Sicht von Microsoft Teams zu erfragen. Hier bleibt nur die Selbstüberwachung der eingehenden OPTIONS-Anfragen.

Einen Status "Down" gibt es leider in der Anzeige nicht.

Sonderfall "Backup Route"

Diese Seite ist auch das Ergebnis einer Kundenkonstellation, bei ein SBCs als primäre Route über den TK-Provider konfiguriert werden sollten. Der zweite SBC sollte als "Backup" über einen anderen Provider laufen aber nur genutzt werden, wenn der erste SBC nicht erreichbar ist.

Insofern ist eine Konfiguration mit einer Route und beiden SBCs natürlich falsch, da hier ein Loadbalancing erfolgen würde. Stattdessen wurde eine zweite Route angelegt mit niedriger Prirität angelegt, damit immer der erste SBC genutzt wurde. Wenn Sie aber nun die obigen Aussagen zusammenfassen, dann bedeutet diese Konfiguration:

  • Es wird immer der SBC der ersten Route genutzt, selbst wenn dieser als "Down" bereits erkannt wird
  • Dieser erste Versuch wird erst nach 10 Sekunden abgebrochen
  • Jeder ausgehende Ruf wird damit um 10 Sekunden verzögert.
  • Auch nach 3 Minuten ohne OPTIONS des ersten SBC ist der SBC zwar "down", aber er wird dennoch immer zuerst versucht.

Für diesen Fall ist das Standard-Verhalten von Teams ungünstig aber aktuell nicht per Automatismus zu verhindern. Leider scheint Teams den Status des SBC nicht derart zu nutzen, um die Route selbst auf "offline" zu setzen, wenn alle SBCs, in dem Fall gibt es nur einen , nicht im Status "healthy" ist.

Wenn hier der primäre SBC für längere Zeit "down" ist, dann bleibt nach meiner Einschätzung nur eine Änderung der Konfiguration im Tenant, um diese Verzögerung zu verhindern. Sie deaktivieren einfach den ersten SBC oder ändern die Priorität der CSOnlineVoiceRoute.

Weitere Links

Direct Routing for Microsoft Teams
https://gallery.technet.microsoft.com/lync/Direct-Routing-fro-Review-1-a3f492e8